PHP Extension Maker is a desktop application made for the express purpose of building PHP extensions.

As anyone who’s done so can attest to, while not the most complicated process extension creation would benefit hugely from a decent UI.

I’m posting this today to say what’ done so far, what’s planned, and if you have any ideas or suggestions to let me know : )

Core

The basic functionality already done is selecting an extension folder and loading that extensions c, h w32, and m4 files into a visual editor. We create a list of all PHP_FUNCTION entries defined in that extension and provide one-click access to that item in the editor.

When done writing code we have a simple (read, zero config) click to compile feature that takes your current PHP dev environment and completely automates the build process. Output from this process is of course shown in a debug window. Right now Windows nmake is done, with full support for Linux planned in the same executable.

Moving forward then I have to implement:

• The creation of new extensions using a Wizard
• Populate ini entries, ARG_INFO, and other PHP structures and provide one-click access to that item in the editor.
• Create helper logic for easy PHP_FUNCTION creation.
• More features for the code editor (line numbers, auto-complete, etc)
• Live command line for testing out our compiled extension functions right within the editor.
• etc : )

It’s a load of work but I’m excited about the finished product. PHP is my language of choice and having a tool for extension creation can only make it better by opening it up to a wider audience.

As noted above if you have any suggestions or comments please let me know!

Finally, this will be a free, fully open source project when done : )

$a = 1;
$b = 2;

// calls fast_add_function() from Zend/zend_operators.h
$c = $a + $b;

As the comment states this code will trigger the Zend Engine to call a “fast” add operation (fast_add_function()) defined in Zend/zend_operators.h.

The code includes the following bit of inline assembly, which if nothing else shows how to code defensively while using inline assembly (the overflow condition), as well as how to use jump operations to skip to the end of a function block:

#elif defined(__GNUC__) && defined(__x86_64__)
		__asm__(
			"movq	(%1), %%rax\n\t"
			"addq   (%2), %%rax\n\t"
			"jo     0f\n\t"
			"movq   %%rax, (%0)\n\t"
			"movb   $0x1,0x14(%0)\n\t"
			"jmp    1f\n"
			"0:\n\t"
			"fildq	(%1)\n\t"
			"fildq	(%2)\n\t"
			"faddp	%%st, %%st(1)\n\t"
			"movb   $0x2,0x14(%0)\n\t"
			"fstpl	(%0)\n"
			"1:"
			:
			: "r"(result),
			  "r"(op1),
			  "r"(op2)
			: "rax");
#else

The function block that contains this code takes three zvals* as parameters, structs whose first member is a pointer to the zvalue_value’s used as op1, opt2, and result.

We attempt an addq and if we overflow, issue a Jump Overflow (jo) to the 0 label which calls two floating point load quad (fildq) for our parameters followed by an faddp.

The movb call modifies the result zval structure’s type property to be 1, which (I assume) means a data type of long.

The point is sure PHP is a managed language, but its C roots means we can jump into assembly when possible for maximum performance. Their are several other “fast” methods defined in Zend/zend_operators.h, most for optimizing simple a and b type operations. A possible takeaway may be to try and code for these “free” optimizations by grouping add operations into blocks of two.

What’s more interesting to me though is an idea I’ve had for a while now, which is to create an extension that allows us to create assembly code by hand and use it inline in our PHP code. Seeing how we populate and work with zvals here seems pretty strait forward so long as the Zend Engine handles the memory bits, perhaps the extension would work much like GNU assembly in that we would link PHP vars as parameters to the assembly block.

Just a few more steps…

Hooray! I did it. That’s 1,000,000 steps according to my iPod Nano.

What an accomplishment! Over 165 hours of walking burning over 61000 calories in the process…

Hmmm. So why don’t I feel anything? Where’s the elation and festivity?

Ah yes I know, it’s because I started tracking this at the end of October 2011. Yup, in only 5 months I’ve somehow managed to walk one million steps, outdoors, in winter, in Wisconsin. How is this even possible?

As a wee-pup I used to think one million was unfathomably large. An unobtainable amount of anything, be it money, toys, or whatever. And yet a few weeks ago while waiting in line for something or another I glanced down at my iPod to see 800,000 of something. I had not seen that stat before, and was dumbfounded when I saw what it was. 800,000 steps? Really? Doing the math I realized I’ll hit 1 million in less than 3 weeks.

If this had taken me a decade sure, that’s fine. But at 11,000 steps a day (a 2 hour walk) I’d hit that magical number in no time. The child in me resisted: 1 million is not supposed to happen that quickly, and yet here it was just a few weeks away — from walking no less. Not the fastest way to rack up a million of anything.

We live in a magical world where the intensely large and unfathomably small are commonplace — Our CPU’s tick over billions of times a second and we can image individual atoms. Yet one million steps in such a short time has always been with us. From 50,000 years ago to just now. Turns out one million isn’t that much, I simply made it so as a child.

What other false barriers and preconceptions do I have yet to break down?

Two million steps, here I come : )

But there are two changes I simply must have for me to even consider abandoning Windows 7:

1) Smart Window Focus – For years now in OSX you can drag objects (files, folders, etc) from one window and when you hit a second window, that window will pop to the foreground after a set time. This is a smart and beautiful way to maximize space and make file move operations much faster and more intuitive. No version of Windows has ever had this, and its MIA status in Windows 8 thus far is a real shame.

2) Control over task bar preview size – Mouse over an item in the task bar and a preview appears. It’s a good idea spoiled by the preview item being more of a postage stamp than a usable object. Sure you can change this size in the Registry, but why so much work? Moreover this should be a “smart” feature anyway, with the size of the thumbnails changing intelligently to make the best use of the space they have.

Bonus Feature: Okay here’s one more, also from OSX – If you hold the Control key down and click on a folder in Windows nothing happens. Double click the folder and sometimes — but not always — that folder will open in a new window. I love that kind of stuff but it’s still inconsistent and buggy in Win 8.

What I’m saying is what a treat it would be if the changes made in Win 8 would not just stop at  Explorer ribbons and better file copy features, but real, usable shortcuts and time-savers for us working folk.

What would you like to see in Windows 8?

That’s…odd I thought.

In Firebug it gets stranger:

And in Qt Creator in text mode, stranger still:

So what is it? In Word or Notepad the vertical extension seems to be limited to one line regardless of text size:

Which means content in the middle of this stream would be obfuscated from normal view.

My first thought is Unicode, though the nature of how the characters stack atop each other makes it very difficult to select them.

Thus, the best way too see which characters we’re dealing with is in a binary or hex editor, in my case that means Qt Creator via:

Followed by selecting Core.BinaryEditor:

When opened then we see this:

So a good place to start would be to Google Unicode 0e47. The only problem is we don’t get a match. Lets try Unicode 2a0e. Nada.

Ah, but that’s right, Windows is Little Endian, which means we should actually be looking for 470e and 0e2a.

Now we’re getting somewhere. Using little endian Unicode encoding I can recreate the first two characters, but no more than that.

That is, in Notepad we add 0e2a for:

and then 470e for:

Which as we can see places the second character above the first. Though subsequent paste operations fail to add more 470e characters, as we can see in Binary Mode:

However, in Firebug we can add as many 470e’s as we want using the code editor:

Which means to apply this ‘hack’ we simply need a copy/pasted character and Firebug.

The issue then seems to be that, from my testing anyway, any Thai character proceeded by an oe2a will get placed above the 0e2a. Conversely, 0e47 followed by 0e2a doesn’t place the 0e2a above the 470e. Of course their could be other vulnerable characters as well, and programs such as Word and Notepad restrict the display to one line only. InDesign doesn’t seem to recognize the Unicode characters at all.

The issue however, is that as the Web does respect this scheme I’d expect to see many annoying comments in the near future as others learn this new trick.

The Overall Project

So the overall project I’m working on is to create a coin flipping simulation to see how many flips it would take to reach n consecutive results of the same coin face. The math is a bit beyond me in terms of prediction, so I’m focusing on the simulation aspect.

One of the tricks of this process is in C++, creating a random number is a bit of a hack. The good news is with the forthcoming Intel Ive Bridge processors we’ll get the RdRAND instruction for generating truly random numbers.

For now though we’re stuck with seeding rand() with srand() via a time() call, something along the lines of:

#include

time_t seconds;
time(&seconds);
srand((unsigned int) seconds);

This works but again, it’s not truly random in the purest sense of the word.

No matter, to create my simulation I wrote a simple program that spawns a few threads and iterates over a large number of ‘flips’ to see how long a streak we can create. For the curious, over 1 billion flips we usually average about 22 consecutive heads or tails.

The program spawns ‘self contained’ threads in that the result of each flip stores its result in that threads buffer. Thus, with 4 threads we get 4 sets of 1 billion flips, not 4 billion consecutive flips. I thus set out to create a producer/consumer application using semaphores for using more than one core where are larger number of consecutive flips could be simulated. To be clear this is for educational purposes — being a web guy means you usually don’t get to create such logic, and so even though we could just let the existing program run for longer, it’s not so much about actual implementation but education.

The C++ extern keyword

One of the first issues encountered was how do we create a global variable my producer and consumer thread classes can both talk to?

In other words, because we’re using a shared data structures two separate classes need to communicate with (the semaphores and buffer), it makes sense to make them global. The alternative is to create a slightly more complex class structure but I’m not interested in doing so.

With that being the case the trick with this, as I found out, is that unlike using a single file say, main.cpp, and just declaring the globals at the top of the file, when using multiple class files the compiler quickly becomes confused regarding where and when variables are declared and used.

To see the basic problem consider the basic project layout:

As this is a Qt application main.cpp is only used for setting up the UI, and can be ignored. mainwindow.cpp however, is where we react to a button press that starts our two threads:

This calls a slot in mainwindow.cpp as follows:

void MainWindow::slot_startThreads()
{

    Producer *producer = new Producer;
    Consumer *consumer = new Consumer;

    producer->start();
    consumer->start();

    producer->wait();
    consumer->wait();

}

Thus, we create instances of producer and consumer, these two classes inherit QThread. Both classes need access to a char buffer called buffer, which means we somehow need to make this buffer visible to both classes.
At first it would appear that we simply define buffer above main.cpp’s main() function. No go. Doing so makes buffer available to any function within main.cpp, but not any other file.

Next I tried to define buffer in mainwindow.cpp and mainwindow.h — again, no go.

To be honest I was somewhat baffled by this. If it works in a single file instance why not multiple? Well that’s when I learned about extern.

So lets say in different, brand new project we have mainwindow.cpp with the following code:

#include "mainwindow.h"
#include "ui_mainwindow.h"

#include "test.h"

int age = 1;

MainWindow::MainWindow(QWidget *parent) :
    QMainWindow(parent),
    ui(new Ui::MainWindow)
{
    ui->setupUi(this);

    test *t = new test;

}

MainWindow::~MainWindow()
{
    delete ui;
}

In a class called test we have a call to qDebug() << age:

#include "test.h"

test::test()
{
    qDebug() << age;
}

When we compile this code as is we get an error:

C:\QtSDK\Projects\extern\test.cpp:5: error: 'age' was not declared in this scope

But if we make one simple change in test.cpp by declaring age to be extern:

#include "test.h"

test::test()
{
    extern int age;
    qDebug() << age;
}

Everything works, and in the running program we spit out 1 to the console.

I needn’t go too deep into this here, for that we have this great link, but the main take-away is extern tells the compiler this value is defined elsewhere, and so long as it is, no problem.

One final point though: in our coin flipping simulation we have a few globals, and as you may have noticed from the project files screen shot, we have global.h and global.cpp.

See, in larger projects we don’t want to sprinkle too many externs around because as some will attest, globals are in fact a bad thing. I’m not quite sold on that concept (that globals are bad if used wisely), but I will say that if we need globals we should at least keep then unified in one location. Thus, in my code we have global.h and global.cpp:

#ifndef GLOBALS_H
#define GLOBALS_H

#include <QSemaphore>

// consts don't need labels in the compiler
const int DataSize = 10;
const int BufferSize = 4;

// but variables do, which means they must be extern and defined in cpp file(s)
extern char buffer[BufferSize];
extern int consecutive; // used in the full flipper application

extern QSemaphore freeSpace;
extern QSemaphore usedSpace;

#endif // GLOBALS_H
1

1
#include "global.h"

char buffer[BufferSize];

QSemaphore freeSpace(BufferSize);
QSemaphore usedSpace(0);

However, as soon as we go the global.h include file route a series of potential pitfall awaits us.

As you may notice by the comments, some variables we declare will be const, and these guys are handled differently than non-const vars with respect to global use and the extern keyword.

Also, in my code I need to include the global.h file in several places, but this means we’re now susceptible to multiple inclusion issues. Of course a decent IDE will add the boilerplate:

#ifndef GLOBALS_H
#define GLOBALS_H
[...]
#endif // GLOBALS_H

…but this won’t prevent a subtle compiler error from rearing its ugly head.

Basically, if we have a const variable we do not need the extern keyword so long as any instance of a global variable is preceded by including our global.h file. However, any non-const variable must be declared extern, and then assigned a value in a cpp file, as we’ve done above.

If we don’t do this all sorts of strange compiler errors will be generated, most having to do with the variable being declared multiple times.

A great place to learn more is this link.

QSemaphore

Moving along then, at this point I have my global data structures for storing my coin flip data. Now we need to implement the QSemaphore logic for our circular buffer.

The basic idea of a semaphore is to make a shared data item have parts that can be operated on by two or more different threads via locking. A great example of this is a circular buffer.

We start the buffer out by having a producer thread write data to it. The semaphore then marks, at a specific point, that some data has been processed, at which point a consumer thread reads and processes that data.

My thought process for this project is that the producer thread will flip the coin (generate a random number), the consumer will compare that flip to the previous and if the same, store it in a buffer which resets a consecutive flip count if a non-consecutive flip occurs.

This is by no means supposed to be the proper way to do this in terms of speed or efficiency, I just figure it’s a good way to learn about QSemaphors.

The Implementation

My application uses a single widget with a start button that when clicked, calls the slot_startThreads method defined as follows:

void MainWindow::slot_startThreads()
{
    this->ui->pushButton_startThreads->setText("Working...");
    this->ui->pushButton_startThreads->setDisabled(true);

    QDateTime start, end;
    start = start.currentDateTime();

    Producer *producer = new Producer;
    Consumer *consumer = new Consumer;

    producer->start();
    consumer->start();

    producer->wait();
    consumer->wait();

    // output total
    qDebug() << "Consecutive: " << consecutive + 1;

    // reset consecutive
    consecutive = 1;

    // benchmark
    end = end.currentDateTime();

    int elapsed = end.toMSecsSinceEpoch() - start.toMSecsSinceEpoch();

    qDebug() << "Elapsed time: " << elapsed << " (seconds)";

    this->ui->pushButton_startThreads->setDisabled(false);
    this->ui->pushButton_startThreads->setText("Start Threads");

}

I’ve included benchmark code to compare this method against a non-buffered version, please see below for results on that bit.

The producer and consumer classes are defined as follows:

#ifndef CONSUMER_H
#define CONSUMER_H

#include <QThread>
#include <QSemaphore>
#include <QDebug>

#include "global.h"

class Consumer : public QThread
{
public:
    Consumer(); // for producer the only thing that changes is the constructor name

    void run(); // both classes simply implement run()
};

#endif // CONSUMER_H

And implemented as follows:

#include "producer.h"

Producer::Producer() {}

void Producer::run()
{
    int first_die, streak, max_streak;

    streak = 0; max_streak = 0;

    time_t seconds;

    time(&seconds);

    srand((unsigned int) seconds);

    // flip logic
    const int LOW = 1;
    const int HIGH = 10;

    for(int i = 0; i < DataSize / BufferSize; i++){

        freeSpace.acquire(BufferSize);

        for(int j = 0; j < BufferSize; j++){

            first_die = rand() % (HIGH - LOW + 1) + LOW;

            if(first_die > 5){
                buffer[j] = 'T';
            } else {
                buffer[j] = 'H';
            }

        }

        usedSpace.release(BufferSize);
    }
}

#include "consumer.h"

Consumer::Consumer() {}

void Consumer::run()
{

    char last = 'A';
    int streak = 0;

    for(int i = 0; i < DataSize / BufferSize; i++){

        usedSpace.acquire(BufferSize);

        for(int j = 0; j < BufferSize; j++){

            if(last == buffer[j]){
                streak++;
            } else {
                streak = 0;
            }

            if(streak > consecutive){
                consecutive++;
            }

            last = buffer[j];

        }

        freeSpace.release(BufferSize);

    }
}

The key drivers are the global.h and global.cpp files, defined as shown above — this is where we define the number of flips and the buffer size.

The end result of this code is 1,000,000 flips is achieved in an average of 43 milliseconds. Also of interest is in our global.h file we can define the size of the buffer used by the semaphore (aka the resource size). Smaller values like 512 for one million flips returns the same average performance as 1 megabyte. However, when we up the flips to one-hundred million a buffer size of 512 bytes averages around 4 seconds, a two-megabyte buffer in 3.5. Going to a four megabyte buffer further reduces this to 3.1 milliseconds, at which point going higher has a negligible effect on performance.

The key here is the buffer size has a direct impact on the number of context switches our threads perform, which in other words means the larger of a resource the semaphore controls the less overhead we have.

For example, a 128 byte buffer increases our benchmark time to 7 seconds simply because of the number of times we need to switch threads.

Of course it also must be said that our code is unbalanced in that the consumer thread must wait for the longer random number generation operations of the producer thread. If we spent more time on this we would make an effort to make sure our producer and consumer operate at a matching frequency.

Finally, I would point out that a single threaded version of the same flipping logic is almost twice as fast. This should not be that much of a surprise, in that the type of processing we’re trying to achieve here is largely dependent on the overhead assumed with using a generalized semaphore.

Files Used For This Project

producer-consumer

As other have pointed out, a rather large burden is placed on site owners, especially those who run aggregate sites like Reddit and YouTube. My understanding is content/copyright owners can request that sites be removed from the US Internet if they’re found to harbor, support, or link to unlicensed content.

On the face of it that seems like it makes sense — if you’re “linking” to stolen goods via a sign in the front yard that says “car stereos in garage” it’s only natural that, even if it’s not your house, the operation gets shut down.

Right now the Internet is as free as it gets. Virtual goods and ideas exchange “hands” with impunity. Be it a movie or your thoughts on the movie, the Internet and our government doesn’t make a distinction. It’s all just bits floating in space.

As a society then we have a simple decision to make: do we embrace the current system or do we throw it away?

If the answer is “embrace” content providers and producers will simply have to live with the Internet as it stands right now, pirates and all.

Me: I like to pay for things:

By my rough count I own 144 episodes at $2.99 each making for $432 in TV shows. I also own about 860 songs, which at .99 cents means I’ve spent close to a thousand dollars on music — in the past 4 years.

This isn’t counting the Blurays and DVD I’ve bought over the years, the movie tickets, and of course rentals.

In short I’ve still spent what I consider a pretty exorbitant amount of money on entertainment, an amount that in some countries would be the equivalent of a years salary or more.

I pay because feel anything else would be wrong. In fact, my beloved South Park episodes: I can watch those for free anytime I want at South Park Studios and yet I don’t. Why? I like to own stuff I’ve paid for I guess.

And yet as sure as you have me and my way of buying, you have others who feel entitled to whatever they want, when they want, and always for free.

Thus, the other option is we do not embrace openness and instead move to lock the Internet down. In this world the Internet will become what I’ve been predicting all along: the cable TV model but on the Net. Instead of an open model we’ll buy “Internet Content Packages” (channels) that contain blocks of content (that still contain ads, just like cable TV does today!).

So we’ll get the tech package that contains access to Ars and Vox properties, the sport package that contains ESPN, and so on. I fear smaller sites like mine will be relegated to what in cable TV today is the public access channel. A slower, less reliable data-stream that at best means fewer visitors and less traffic. And make no mistake, we’ll do this willingly. An effort will be made to make the Internet as dangerous (legally speaking) as can be for aggregates (fan sites, the aft-mentioned YouTube etc), which means the “good” content will be the curated stuff we “conveniently” pay for in the content packages.

And so as I said above the bill is supposed to help software guys like me (content producers), but in the long term I believe its potential to hurt my business is a real threat.

Put another way I feel the greatest failing of SOPA is its inability to stop piracy in general while fundamentally changing how the Internet works for us working folk. Same as I have my content channel (iTunes) pirates have theirs, disabling websites because of links won’t stop this at all. Thus, SOPA passes and I, a law-abiding consumer, pays, while the pirates quite literally never do. They’re already comfortable using illicit channels, what’s to stop that in the future?

The future of the Internet is not in question – it’s what it will look like that is. I personally side with those that argue so long as content is easy to access and comes with reasonable rights people will pay.

I believe their are more than enough of us that fit into this mold, why should we be punished for those that do not?

So let’s talk why: When building something like FormBoss you often run into a situation where you need to do cross-browser compatibility coding. With Google Chrome now in the #2 spot and IE variants still holding around 50% of the market, this means at minimum 3 browser windows open at once.

This also means the developer tools for each browser being open and ready for some heavy lifting as code checks are run and bug squashed. Problem is, somehow the IE developer tools are not pinned to the main window like Chrome and Firefox, which means I’ve got an extra window clogging an already tight workspace.

I need to pin them to the IE window, but do not know how. As I’m already in IE I Bing:

ping ie developer tools to main window

I know, I know : ) My spelling’s terrible, but that’s the whole point.

I miss my error at first, and my search results comes back with this:

Not to be a mean guy, but that’s utterly worthless as a search result. It’s not even close that what I need or want.

So I copy/paste my #erroneous# query into Google and get this:

Eureka. Three completely relevant links right up top.

And that’s the thing. I gave Google what to some humans would be an nonsensical question and yet Google still comes through.

Now to be fair when we change our query to:

pin ie developer tools to main window

Bing comes through in fine fashion, even providing a Microsoft link at top:

So it’s not all bad, but I’ve come to expect that my search engine is smarter than me.

Google is, Bing is not.

A quick note as we get started: I’ve never coded in jQuery before, so my apologies ahead of time if I miss something obvious!

A Button Clicking Example

In this first example let’s see what a typical event handler for a button click looks like when following the design pattern of separating design from implementation:

Prototype:

<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<script src="prototype.js" type="text/javascript"></script>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>Prototype</title>

<script type="text/javascript">

// bind each button
document.observe('dom:loaded', function(){

	syntax = 'quick';

	if(syntax == 'quick'){
		// quick syntax
		$$('.dynamic-element-wrapper > INPUT').invoke('observe', 'click', buttonClicked);
	}

	if(syntax == 'verbose'){
		// verbose
		$$('.dynamic-element-wrapper > INPUT').map(function(t){
			t.observe('click', buttonClicked);
		});
	}

});

function buttonClicked(e){
	$('console').update(e.element().id + ' Clicked');
};

</script>

</head>

<body>

<div class="dynamic-element-wrapper">
	<input type="button" id="button-1" name="button-1" value="Button 1 - Click Me" />
    <input type="button" id="button-2" name="button-2" value="Button 2 - Click Me" />
</div>

<div style="clear:both;" id="console"></div>

</body>
</html>

jQuery

$(document).ready(function() {

	syntax = 'verbose';

	if(syntax == 'quick'){
		$('.dynamic-element-wrapper > INPUT').click(buttonClicked);
	}

	if(syntax == 'verbose'){
		$('.dynamic-element-wrapper > INPUT').bind('click', buttonClicked);
	}

});

function buttonClicked(e){
	$('#console').html(e.target.id + ' Clicked');
};

Please note that as the HTML doesn’t change the jQuery code sample is limited to just the SCRIPT block.

So a couple items of note:

As a long-time Prototype guy jQuery’s automatic array return when using $() sits in stark contrast to Prototype’s use of $$(). I have to admit I’m torn on this one, as in a way the jQuery way makes more sense. The selector and knowledge of the document, combined with the function our event listeners call should be all that’s needed from a selector. In practical terms then differentiating between $() and $$() is admittedly more work without a huge gain in readability.

That aside, in Prototype we also get a bit more syntax heavy having to resort to .invoke() or .map(), whereas jQuery’s .click() makes short work of the job — providing a quick and concise way to perform such a common task is a huge win.

On the event processing side our buttonClicked() call is very similar. Once again jQuery’s love of shortcuts impresses me. .html() for getting and setting text is quite nice, and from what I can see, is duplicated via .val() of the form field side.

The this Reference Binding Issue

So here comes the main event. The example above in terms of design pattern is going to be just fine for most projects. Our design code is free from implementation code and when we click the element we get the info we need — everything just works.

But what happens when we follow a slightly more complex design pattern? Many times allowing UI implementation code to hover in the global script scope is perfectly acceptable. But their are times, either by virtue of space or code cleanliness, that wrapping our event code into objects is desirable or required.

An example of doing so in Prototype looks like this:

var buttonFactory = {

	_limit: 10,
	_secure: true,

	bindObjects: function(){
		$$('.dynamic-element-wrapper > INPUT').invoke('observe', 'click', this.buttonClicked);
	},

	buttonClicked: function(e){
		$('console').update(e.element().id + ' was clicked. ' + 'The limit value = ' + this._limit);
	}

};

// bind each button
document.observe('dom:loaded', function(){
	buttonFactory.bindObjects();

});

As you can see instead of binding our event listeners in the global scope we issue a simple call to buttonFactory.bindObjects(). If this was a much larger project it’s not hard to see why this would be a great way to work. Our document.observe code would simply be a series of calls to code that initialize other parts of the UI. The initialization code would then perform all sorts of long-winded tasks while leaving our document.observe call far from the down and dirty details.

But all’s not well. When coding this way — if not just to save space but to also create more complex event handling logic — we would expect that our buttonClicked() code would handle the reference to this._limit but it doesn’t. We’ll get this when we click a button:

button-2 Was Clicked. The limit value = undefined

That’s not at all what we want. You’d think this._limt should return with a value of 10 but it doesn’t. Why?

The problem is when we bound our event listener the this reference wasn’t part of the process. This means when we trigger a click event the this refers to the event object, not the buttons original parent object (buttonFactory).

Prototype has a solution for this via a call to bindAsEventListener(). bindAsEventListener() takes the object we wish to use as the this reference when invoked. To implement this fix in our example code we’d change our bindObjects() call to:

//
//
$$('.dynamic-element-wrapper > INPUT').invoke('observe', 'click', this.buttonClicked.bindAsEventListener(this));
//
//

Now when we run our code it returns the following when a button’s clicked:

button-1 was clicked. The limit value = 10

That’s more like it. Sure this is a synthetic example, but it’s absolutely essential to creating portable code.

Portable is the key word here, as yes, we could just do this to our buttonClicked() call:

//
//
$('console').update(e.element().id + ' was clicked. ' + 'The limit value = ' + buttonFactory._limit);
//
//

But this would be in bad form in my opinion, as now we’re making all sorts of assumptions of how this object will be consumed.

So the point is Prototype gives us a sleek, consistent way of holding objects together in event-driven code.

How does jQuery solve this issue?

jQuery

var buttonFactory = {

	_limit: 10,
	_secure: true,

	bindObjects: function(){
		$('.dynamic-element-wrapper > INPUT').bind('click', this, this.buttonClicked);
	},

	buttonClicked: function(e){
		$('#console').html(e.target.id + ' Clicked' + 'The limit value = ' + e.data._limit);
	}

};

$(document).ready(function() {
	buttonFactory.bindObjects();
});

The method signature of .bind() as we’re using it is:

.bind( eventType [, eventData], handler(eventObject) )

Thus, my solution is to simply pass our object reference as the eventData argument. We then pick up on the value via the event.data object in buttonClicked() and away we go.

Seems simple enough but again I do not have…well…any jQuery experience, so I would not be surprised is this is wrong in terms of implementation. What I can say though is it works just fine, and once again the syntax is pretty slick. For Prototype adding bindAsEventListener() is every bit as cumbersome as document.getElementById() if you catch my drift…

I say it works fine as for my part I did issue a test call of:

e.data._limit = 20;

under the #console update call and sure enough, the buttonFactory object was updated accordingly. From this we can tell this is passed as a reference, which means for my money this is an acceptable, working solution.

For the sake of completeness it appears we can also use .proxy().

When used our code changes to:

var buttonFactory = {

	_limit: 10,
	_secure: true,

	bindObjects: function(){
		var bProxy = $.proxy(this.buttonClicked, this);
		$('.dynamic-element-wrapper > INPUT').bind('click', bProxy);

	},

	buttonClicked: function(e){
		$('#console').html(e.target.id + ' Clicked' + 'The limit value = ' + this._limit);
		e.data._limit = 20;
	}

};

$(document).ready(function() {
	buttonFactory.bindObjects();
});

I’m not entirely sold on this method as now we’re once again in the mode of hand-wrangling specific behavior from our objects. It’s nice to know it can be done, however.

Conclusion

The title of this post has a vs. in it so who wins this round? Somewhat unsurprisingly I think it’s a draw, though if I had to pick I’d say jQuery. jQuery’s ability to pass this as an event parameter and it still works is fine by me and easier to code, and considering we can just as easily wrap this into a larger structure is better still.

Of course I’m ready and willing to have any and all ignorance corrected, so if you’ve seen something that’s not right with my solution(s) please let me know!

The bottom line is jQuery has some real time savers in its bucket of tricks; the fact that $() returns arrays is worth the price of admission alone.

Color me continually intrigued.

Prototype JS is…well…it’s another JavaScript library. But it’s the library I know and love. It’s what drives FormBoss and while not as exciting or popular as jQuery, I swear its day will come (again). Their are many reasons for this belief, but the first is due to what I believe is a fundamental misconception about jQuery vs. other libraries — its payload size.

In this first of a multi-part series we’ll take a look at the physical delivery size of each library. In the next post well dive into practical programming. First though, a bit of background.

Background

As a professional Web Developer I had a decision to make in mid-2008 as to what JavaScript library I would use for FormBoss. At that time I was looking for a library that fixed JavaScript’s core issues and had good AJAX support. (Little did I know that while AJAX support was important, far more relevant would be DOM handling and event binding, but more on that latter).

I checked a few libraries starting with Yahoo’s YUI and Dojo. Forget it. Far more complex than I needed, they seemed to make even simple tasks difficult (disclaimer: I haven’t looked into these libraries for some time now, they may be better, or perhaps my initial impressions were wrong!).

What I really wanted was a library like PHP. Provide a solid foundation that was not unto itself a framework. All I wanted was something that extends and smooths over vanilla JavaScript but also provides glue functions for doing more advanced stuff.

It wasn’t long before I narrowed my decision down to Prototype and jQuery (at versions 1.6.0.3 and at 1.2.6., respectively). Both seemed strong – jQuery on the count of its small size and simplicity, Prototype because of its more robust feature-set and AJAX support (again though DOM traversal and event binding played no part in this process, but would become crucial later on).

In the end I went with Prototype for a simple reason — it seemed more “complete” in terms of a programming construct. jQuery, always bragging about how small it was seemed almost too small, too limiting. I wasn’t looking for flash but utility, and Prototype fit the mold. For the most part I haven’t regretted this decision one bit–in the intervening years Prototype has been wonderful to me and always delights. In places where it needed improvement like upgrading to the Selectors API it’s done so in a reasonable time-frame, and for just about everything else, such as animation and event binding, it’s never let me down.

But always in the back of my mind has been jQuery, a nagging sense that I’m missing something. Why has it gotten so popular and does this mean I should be using it too?

Modern jQuery – The Popular Place To be

The base answer to our question of why so popular can be found right at the top of the jQuery home page:

Compare that with Prototype:

Ugh. It’s no wonder jQuery has more hype — seriously — by download link alone jQuery simply looks cooler and more advanced.

But it’s not just that…well not entirely : )

When you look at the jQuery download options you see that magic value: 31KB.

How brilliant can they be? Think about all of those large newspaper, e-commerce, and other highly trafficked sites. Bandwidth is money, and when it comes time to tell your boss you need to add more weight to a site it had better be as little as possible and worth it. More importantly, even as recently as 2009 broadband adoption in America was still only 67%. Sure that number continuies to rise but now consider our rising mobile Internet use. Truly two steps forward and one step back.

The point is size still matters, and Prototype’s stubborn lack of a minified version and frankly boring site and download page mean of course jQuery’s flashy site will draw more users in, both from a aesthetic and practical standpoint.

In Reality…

But of course we’re developers so we go deeper than that, and in preparation for this post I was–admittedly–floored by a simple test:

Had you asked me just five minutes ago I would have said “Of course jQuery is smaller, everyone knows that!”.

As of 1.6.4 jQuery has actually grown larger than Prototype in terms of raw source , 6084 lines vs. 9048 (and almost twice as large in terms of raw source code size in KB). More importantly though is while the minified version of Prototype is still larger, the minified + gzipped versions are identical. More importantly still: the minified jQuery is not 32KB but ~90KB. This is important because the jQuery website makes you feel like you’ll be getting all of that functionality for 32kb, but only if your server is gzipping content. The simple fact is almost all shared hosting plans won’t be doing do, which means your 32KB is actually closer to 90KB. And no, it’s not just the smaller plans, it happens with the big boys as well:

http://shop.nordstrom.com/

Run a Firebug NET session on that site and you’ll see what we’re about to cover below. They use a minified but not gzipped version of jQuery (version 1.5.1), which means payload size is 51KB.

In that light it’s instructive to see what happens with no server size gzipping with the latest versions of each library:

Prototype.js

jQuery

Here we can can very little server time spent on the requests, but with jQuery’s minified version definitely being smaller. Again though, the 32KB shown on the jQuery website, while true as it clearly states “Gzipped”, is not what we get without the server actually gzipping, as we would expect.

However, as soon as we enabling server size gzipping [via Apache’s mod_deflate using:

LoadModule deflate_module modules/mod_deflate.so

we get:

Prototype

jQuery

The minified version of Prototype is made via this minifier, and as we can see is essentially the same size as jQuery.

However, note that the non-minified version of Prototype is only ~5KB larger, and just as importantly, only take ~3 ms of extra server processing time (remember that gzipping in Apache is not free!). In other words we’re about even in that we do not need to create a minified version of Prototype and we’ll still deliver, in terms of processor load and payload size, the same thing.

In Conclusion

In this first post we’ve found that when properly delivered both libraries are essentially the same size. I would actually give Prototype the win however, as its smaller uncompressed size means we can simply plop the uncompressed version in to our delivery or ‘live’ section, and then in testing, instead of nonsensical minified error messages get actual line numbers we can refer back to. True this shouldn’t happen often, (it should be our code with the error, not Prototype or jQuery), but still handy in the larger scheme.

In non-gzipped environments however it’s clear that jQuery gets the win. This will be important for shared hosting plans of anywhere else we do not have access to server-side gzipping.

It’s also noteworthy that in order for Prototype to gain some of the more advanced animation framework goodness that (I assume) jQuery already has in the base library, we’d need to add Script.aculo.us, which would of course make the total payload larger.

Those considerations aside, what’s fascinating to me is that the perception of jQuery being “the” light-weight library. In the past 3 years I firmly believe this has been the primary driving force behind its mass adoption and popularity. I don’t know about you but I’ve been specifically told by bosses to not include Prototype because of its size — but at the same time given the go-ahead for jQuery. I’ve also made similar decisions for FormBoss based on the same reasoning (though not to instead use jQuery, just vanilla JavaScript).

Now that this is no longer true for the right environments (and truth be told, this has always been the case in the right environments), I think the time’s right for Prototype to take back some of the users it rightly deserves.

The irony of course is back in 2008 jQuery 1.4.2 was in fact smaller: 3549 lines of code vs. Prototype 1.6.0.1′s 4321. But success comes with a price, and jQuery’s potential bloat can only be a good thing for users looking to ‘trim’. How wonderful : )

Please understand though: I have nothing against jQuery, I simply feel that Prototype deserves more recognition and is in many ways the superior library for some specific types of work.

This will only happen though, and I cannot be more serious, if the Prototype folks get off their collective butts and do the same thing as jQuery –  advertise, as prominently as you can, the fact that when minified and gzipped your library is the same size.

Links

http://thinkrelevance.com/blog/2009/01/12/why-i-still-prefer-prototype-to-jquery.html