After a discussion at work today about how expensive Prototype’s $$ function is in the lovely Internet Explorer, I decided to run the Slickspeed tests in IE7 – something which I’m a little embarrassed to admit I’ve never done before. I knew the results would be bad – but seeing just how bad they were made my stomach turn. It also piqued my curiosity to dig into this some more.

With the preset settings and my own custom frameworks (I chose Prototype 1.6.0.2, 1.6.0.3, and jQuery 1.3), both Prototype’s came in at over 2 seconds (2142 and 2169ms, respectively). Granted, I’m running my IE’s on a VM powered by a nearly 2 year old MacBook, but an ‘average’ website visitor is probably powered by something on a similar level.

To pour some salt in the jQuery vs Prototype war, jQuery’s results are in a whole ‘nother division, coming in at 386ms. While it really burns me to knock on Prototype, I can’t look at the framework and not see it’s downward spiral into disrepair. It’s only glimmer of hope is the strange fact that 1.6.0.3 performs extremely well in Safari, but at 5-7% of the market, that really don’t mean squat. Not when IE7 is that pathetic.

Deciding to dig a bit deeper, and take advantage of the true customization allowances of the Slickspeed tester, I decided to actually use some real code from the Zenbe app. So I took the source code of one of the frames, changed the selectors list to mimic some of the ones we call frequently, and ran the test again.

The results were similar, but on a slightly smaller scale (the default testing document they provide is somewhat heavy, and does include a lot of CSS3 selectors which most devs never use). However, the ratio of difference between Prototype and jQuery is astonishing (like 400% faster astonishing), and even moreso is the fact that in IE7, 1.6.0.2 outperforms 1.6.0.3.

I’m not going to get into my thoughts on what all of this means for Prototype, that’s another blog post (or two…), but I hope this post encourages developers to try Slickspeed out on their own site, and see how your JavaScript framework is treating you compared to others.

For those who aren’t familiar, Canvas is an HTML5 element which enables you to do script-based drawing, specifically Javascript. While not natively supported by the IE’s, the wonderful Explorer Canvas script works very well in converting Canvas drawing to the IE-supported VML. While I hear you can’t do everything with Explorer Canvas, most drawing, coloring, and animations will work just fine.

After getting around the initial mind-warp of drawing with script, Canvas has proven itself to be flexible, fast, and fun, and although it’s very new and not (officially) globally supported, I would recommend that anyone who’s considering adopting it to do so.

There’s quite a few reasons I suggest this. First, it will lighten the load on the client-side quite a bit. You end up with some seriously simplified CSS (there’s no browser inconsistencies with canvas drawing), and a lot less images, which saves both bandwidth and http requests. Gradients, shadows, transparency, and rounded corners become nothing but an afterthought to develop (screw sliding doors), and theming becomes as easy as changing some hex values (or rgb, or hsv… it’s easy like that).

Without giving too much away, Canvas is going to be a big part of some upcoming releases at Zenbe, and I couldn’t be more stoked about it. It’s done very well in the tests so far, and I’m looking forward to being on the bleeding-edge of client-side web development. Officially and thoroughly.

Expect to hear more Canvas stuff from me in the upcoming months. After I wrap up my work with it at Zenbe, I plan on continuing development with it, releasing some core classes open-source to help gain support for this extremely powerful drawing framework.

The conference kicked off this morning, and it’s been an interesting experience so far. I’ve been assigned to the Breakout 1 room, which this morning hosted the Prototype presenters, Christophe Porteneuve and Andrew Dupont. They were part of this morning’s “developer day” events, where the leaders of some of the main JavaScript libraries (Prototype, jQuery, and Dojo) had 5 hour sessions (side by side) where they introduced their library and explained how you can get the most out of them and contribute to the community.

The ‘hotness’ of jQuery was more prominent than ever this morning, as our room was very very sparsely filled, while the jQuery room, which was the same size, was packed to the brim.

The imbalance of the turnout was clearly noticed by the Prototype speakers, and this brought about some discussion on the differences between the libraries, and the cases for using each. Now, these guys are obviously biased towards Prototype, but what they mentioned was pretty accurate. Basically, they proposed that jQuery is better for simpler web applications, while Prototype is still more robust for creating custom classes and prototypes, and creating your own sub-library. I completely agree with this, as we use Prototype at Zenbe for our very complex, intricate js needs, and the library makes it completely easy and fun to write complex classes.

The bad thing here (at least for Prototype) is that most web developers are not looking to create super complex JavaScript applications. Most of the time, JavaScript is used to enhance the user experience, adding fancy bells and whistles to make a website faster, smoother, and more interactive.

However, I feel that the complexity issue is not the main reason behind the seemingly mass migration from Prototype to jQuery. A few years ago, jQuery was brand new, contending against the giant which was Prototype. Prototype was the original js library, and once upon a time had almost every front-end developer worth their weight using it. Then jQuery started to gain net buzz, building the strongest web community since Rails. And Prototype was left in the dust.

So, what are the reasons behind this?

The first difference between Prototype’s community and jQuery’s, which the most important and probably the most obvious, is the differences in documentation. jQuery’s documentation is completely brilliant. Their wiki is thorough, accurate, and every function has a series of examples showing how to use it. The documentation really does help ’sell’ the library, providing new users with a wide array of friendly, interactive solutions that are not only slick, but very minimalistic and they help make the developer feel empowered.

On the other hand, Prototype’s API is ‘ok’ at best. The biggest fault with Prototype is the lack of examples. This is a big turn off and frustration for new adopters trying to figure out the language – maybe it’s just me, but seeing sample code is the #1 most important thing I count on during the learning phase of programming. No examples adds ambiguity for novice developers (and sometimes even pro ones) and hinders adoption of a new library. You can’t even compare the two API’s – jQuery’s clearly won the cake.

Another reason people are flocking to jQuery has to do with the user community. I’ve heard that Prototype has a plugin community, but you would never know it by looking on the website. jQuery’s use of keeping the base code as minimalistic as possible, and allowing individual developers to release plugins not only fosters a strong community, but it provides the next selling point of jQuery over Prototype: file size.

By itself, jQuery (compressed to the max) is 15k. Keep in mind, this includes some powerful (yet simple) methods for creating animation. If you were to get the same functionality in Prototype, not only would you need Prototype itself, but you would need to use Scriptaculous as well. Combined and compressed to the max, they rank in at a relatively whopping 50k. Relatively speaking, that’s a massive difference, considering the two libraries do the same things.

One last point I am going to bring up is about the progress of the library development. During the Prototype presentation, the developers admitted that the progress on Prototype has been hindered by busier than normal ‘day jobs’. I can’t hold this against them, nor would I – life happens, I know this as well as anyone. However, it still affects the product. I have been completely frustrated by the lack of development that has been going on with Scriptaculous (moreso than prototype) – the animation library has obvious shortcomings (slideup/down needs a container div? blindup/down forces overflow: visible – which funks up ie), and when Tomas Fuchs Skyped into the conference today to talk about how little the library has been worked on in the last year – well that was a huge let down. jQuery has stomped all over this with rapid development, and it’s progress is clearly paying off, and the recent news of them being adoped by Nokia and Microsoft is only going to help make their development cycle faster and more accurate.

So, with all respect in the world towards Prototype, they need to step it up quite a bit if they want to stay competitive with jQuery in the long run. I’m afraid that if they don’t take some pretty big steps to rebuild the community and actually come out with new releases, they might turn into a thing of the past.

This last weekend I picked up the ‘jQuery in Action’ book and it really opened my eyes to just how cool jQuery is. I mean, I was pretty stoked about it already, but now I want to take it out to dinner and maybe make out with it a little in the back of my car.

So, reading the book, I learned just how powerful their wrapper element is. A lot of it’s css-based, so it’s easy for a front-end dev type like myself to catch up on, and then it mixes in simple regular expressions and has() checks and .. my mind is blown.

I wrote this little function last night to both test some advanced wrapper selectors and solve a practical and common goal: hilighting the navigational item of the active page. Before, we’ve done all types of things to accomplish this goal, mostly dealing with writing some sort of server-side code that detects the page and does an if statement to add a class to the markup.

It would always get kind of messy.

But no more! Here’s the function that turns that former headache into a simple JS function call:

function activateNav(nav) {
// split url and get page (or lack of page - index)
var url = document.location.href;
var urlSplit = new Array();
urlSplit = url.split('/');
var page = urlSplit[urlSplit.length-1];

// catch for root (index)
if(page == ”) {
page = ‘index’;
}

// detect location of nav items and classify right one
$(nav+’ a[href*='+page+']‘).parent().addClass(‘active’);
}

Breaking it down into detail, the code above gets the page from the url (the string split on the ‘/’ character and pulling the last array item provides a consistent way of getting only the page file name) and then checks all of the nav link href attributes to see where they’re linking to. If the page name matches any part of the link target, the javascript will add an active class to the element containing the link.

Natrually, this is set up for a list-type nav. Adding the active class to the parent tag and not the anchor itself may or may not be the smartest thing to do, but it made the most sense to me at the time (since 99% of my navs are in lists).

As this code evolves I’m sure it’ll change, but that’s part of the beauty of jQuery – it feels so natural to scale.

At Fox, now I have to think more than ever about file size, code efficiency, flexibility, and scalability. Ever since I’ve been “into” JavaScript I’ve been a fan of the Prototype framework. And why not? It’s solid, efficient, and the footprint… isn’t that bad. Coupled with Scriptaculous, it’s a powerful set of tools for any kind of JavaScript / Ajax functionality.

However, I’ve always had my reservations about this combo. First, Prototype is pretty useless in any kind of animation work on it’s own. Chances are, if you’re using Prototype, you’re using Scriptaculous, and they’re not exactly the lightest loads in the world. Also, not to knock on Thomas Fuchs, who is a brilliant JS developer, but the Scriptaculous website / documentation is poor at best. I’ve stumbled through the framework for 1+ years and still struggle to make my way through that site for any sort of a decent API. Prototype’s, by contrast, is beautiful.

But what about the alternatives? God knows there are plenty, but are there actually any good ones? There’s Spry, Mootools, Mochikit, Rico… the list goes on. Each has it’s advantages and disadvantages, but none of these I’ve really felt comfortable as using as a “Prototype replacement.”

But then there’s Jquery, and for the first time I’m taking notice of this powerful little framework.

The idea is simple – keep the base footprint light, and make mini ‘plugins’ for additional functionality. It allows for excellent customization for any project without having 100k+ of JavaScript. The framework also allows for chainability, which my quasi-developer head can barely wrap around, but keeps the lines of code written to a bare minimum (and somewhat elegant if I do say so). The framework also seems to have high standards for their plugin development, which leaves me confident that I am getting code that is solid through all standard client environments. All this, coupled with their basic yet functional Drupal installation of a website allow me to comfortably leave Prototype behind (sorry, guys).

It had a good run.

I’m calling it PageSlide JS, and it’s proof positive once again that I am super awesome at naming these things. Just like with SmoothScroll, this is being released under the MIT license, so you can do whateverthehell you want with it. Unlike SmoothScroll, I actually have a mini-site for it up and running. You can find that at http://pageslide.ifeedfish.com.

On the site there are usage instructions, samples, and even a writeup for a weird Safari bug I encountered when implementing it.

This bit of software requires both the Prototype JS library as well as Scriptaculous.

Enjoy, and please do leave feedback if you manage to do interesting things with it!

However, since the release and adoption of JavaScript libraries, namely Prototype and Scriptaculous, I’ve finally been able to hop over the JavaScript learning curve. I’ve been doing more JS code both at work and at home, and creating some pretty cool effects.

So, for the first time ever, I am releasing a piece of code to the world. It’s being released under the MIT license, so you’re free to do just about anything with it, and it’s called SmoothScrollJS. Essentially, it’s an animated horizontal scroller, with left and right triggers for a smooth scroll effect. You can adjust the width, speed, and ’smoothness’.

It also includes a reporting tool, which helps take any guesswork out of the old, ‘just how long is the div’ question.

If you would like to check out the demo, go to: http://sandbox.ifeedfish.com/slider/

To download the source files, click here.

A permanent site is on the way, but the zip includes everything you should need to set something running. Check the readme for instructions for use. The code is an extension of the Prototype library, and needs Prototype 1.5.0 or newer to run.

Also, keep in mind I’m still pretty new to this JavaScript thing, and I’m sure there are efficiencies I’ve missed or ways I could have had cleaner code (and I’d love to hear about them), but it works cross-platform and it’s very lightweight.

Yesterday I started working with the library, and after just a short time I had something awesome looking up and running. I was using the slider effect to collapse and show comments on a blog post.

However, this morning, I decided to add the prototype library because I needed to do some AJAX work.

That turned out to be a bad idea, as all of a sudden my mootools effects stopped working, and I was getting very odd JavaScript errors. As soon as I took the prototype.js call out, they went away.

After some digging around on the Internet, I found out that there are conflicts between the two libraries – and as far as I can tell, there’s no way around them. Of course there’s the moo.fx library, and that works to an extent, but there’s far fewer things you can do with that one (read: you can’t do the slider).

So, what started as a great morning left me with a sad heartache – and even though I was able to move over to scriptaculous and accomplish my task, I felt let down by JavaScript libraries in general – JS has always been my weakness as a programmer, and when the libraries came about they were refreshing.

…until one dumped me.