Get To Business.

While taking a break from Octabox work, I came across John Resig’s blog. For those unfamiliar with that name, John Resig is the creator and head developer for the jQuery javascript framework (check the links if you’re unfamiliar with any of those terms either). I have read his book “Pro Javascript Techniques” a while back, and it was nice read though I skimmed through much of it since I was already familiar with most of the material. I wish it had more “Pro” and less common sense materials - which are still good but aimed more at beginners or non-programmers. I’ve read the table of contents for his next books which sounds very promising.
I did ‘read’ his more serious work, namely the source files for the jQuery library, which are a testament to his and his developer group vast mastery of the javascript programming language.

As I was navigating the posts, I came across this small flame war between a mootools dev and John regarding some comments made at a mootools introduction presentation. This matter was consequentially resolved, with both sides and other parties releasing apologies (of sorts).

Before I’ll iterate my thoughts on the matter, I’ll go ahead and say that at Octabox we use jQuery exclusively as a tool for javascript development. This is not a knock on mootools, from the little I tried it and from feedbacks I heard it’s a very good javascript library (and their site is absolutely gorgeous by the way). Choosing a software library is a matter of personal and design preferences, and is influenced to a large degree from what you hope to get out of that particular library.

A short recap of the story: Omlo Maldonado, a mootools developer at the time, was giving a presentation on mootools as a javascript framework. During the presentation, he made several references to other javascript frameworks, jQuery included, in a non flattering manner to say the least. John Resig, being the creator of jQuery, took offense and responded on his blog, adding further fuel to this rivalry. A small comment flame war ensued and the matter was later resolved with all parties (and mootools lead developer) issuing apologies.

Being a software developer myself, I sympathized with John’s feelings in response to the allegations that were made. He and the jQuery team were accused of ’stealing’ code, and their entire approach and design were being looked down upon. While I can’t condone his inflammatory response, I can certainly understand it (I probably would’ve written something much worse if I was accused in this manner. I’m a pretty cynical and sarcastic person). The allegations were serious indeed and detrimental to the whole approach of open source development and coexistence of multiple design approaches.
And while all sides eventually apologized, I got the feeling that the air hasn’t been completely cleared between the two teams. It’s too bad, since it’s exactly the diversity of such frameworks and the inter learning between them that continues to drive javascript development forward.

I’ll end with some insights I hold on jQuery, having used it professionally for over 9 months:

• jQuery lean packaging (15kb minified and gzipped) is a major plus. Previously we have been using Prototype at Octabox, and the switch to jQuery reduced our average page weight by over 50% (Here’s the original post I wrote back then. Seems like eons ago). The improvement to user experience with shorter page load times, the savings on bandwidth - those are all major benefits.
• jQuery has one the best user communities I have seen. Their approach to user contributions via plug-ins is a great idea, and it has proven an invaluable resource for adding functionality not provided in the core (for those knocking on jQuery feature reduction for size benefits - have you seen their plugin library?). The plug-ins being separate from the core also allows developers to hand pick their features, and not having those force fed in the official release.
• The use off CSS selectors as the driving scheme for selecting DOM elements is brilliant. Combining that with the chainable interface is the main reason I chose jQuery - It’s super convenient to use. All scripts I converted to using that interface have had size reductions of ~40% on average As a matter of fact, using the chainable interface has made me fall in love with fluent interfaces and has definitely influenced my design methodology.
• Their documentation is very good overall. I have used many open source projects that didn’t have the documentation to match the level of their code.
• Their UI component still needs work, and some libraries have more mature solutions (script.aculo.us, mootools and DOJO spring to mind). However they seem to be aware of that and have recently launched their UI specific project. By looking at their track record I don’t think this will remain an issue for much longer.

This guy and this organization share my sentiments. Also here and here

Can you tell I’m somewhat biased? I consider myself pretty hard to impress, but jQuery has earned my vote and I’m sticking by it (at least, until something better comes along )

The standards and requirements of web-based user interfaces have steadily risen in recent years, and heavy use of Javascript and sometimes AJAX is almost unavoidable in modern day web applications. However, developing with Javascript could be similar to pulling teeth - There’s a lot of bleeding and the pain won’t go away for several days (Incidentally, I had a tooth pulled out recently).

Javascript, unlike server-side languages such as PHP, are parsed by the browser, and is browser-dependent in its functionality and debugging process. As fate would have it, all browsers differ from each other in their implementations of Javascript parsing, often times even diverging on different versions of the same browser. And of course, there is also Internet Explorer, whose vile and unspeakable acts of Javascript terror are only surpassed by its level of adherence to Css standards.

For basic usage, plain old Javascript can still make do and create simple user-interface interactions. But when the user-interface requirements are high, and Javascript deployment is massive, other alternatives might be considered.
(more…)

Two weeks into the Octabox Alpha testing, we’ve released our first major update, Octabox v0.15.
Latest release didn’t include any new features, but rather was focused on improving performance across the board.

Up until this version we have been using the Prototype Javascript framework to handle client side scripting tasks, and the Script.aculo.us Javascript toolbox to handle User Interface widget implementation (draggable windows, animations and so forth).
These two are most potent and very mature code libraries - however, combined they weigh on the upper side of 200kb (full featured with no compression), which is a lot to download when latency is high for an http connection. After running those libraries through basic compression techniques (removing whitespaces and shortening variable names) we got it down to around 141kb. Major improvement, but still a lot. Unfortunately, the Prototype library is incompatible with more advanced regular-expression compression techniques, like the one used by Dean Edwards’ Packer (It is possible to use Packer on Prototype, but it requires tedious modification to the Prototype script file, and lots of debugging ensues). So, we’ve decided to migrate to the jQuery Javascript framework.

(more…)