Friday, December 29th, 2006

Prototype Sucks 2.0

Category: Framework, Prototype, Testing

<>p>Another day, another article bashing the Javascript toolkit everyone loves to hate – Prototype. The complaints can be narrowed down to a few points:

  • “it breaks the ‘for in’ loop” – no it doesn’t – you were probably using ‘for in’ where you shouldn’t have. Javascript is a flexible, powerful freedom language, and its _okay_ if your framework uses that to the full extent. That means you and your development team need to be educated and aware of the ramifications of it if you want to play ball. The stuff that Prototype did to Object in earlier versions, btw, was a bit too much and has been removed in the latest versions. (related reading here)
  • “its too big” – eh, cache it, compress it on the server side, or use a stripped down version.
  • “its has no docs” – although I’m disappointed to see that Sergio hasn’t updated his excellent reference since May, there are still so many fantastic howto’s and tutorials written using Prototype. Plus the books out now that base much of their code on Prototype. One official reference doc somewhere would be very nice, however.

My main gripes right now with Prototype would be what looks like a low level of activity in the source and this doc project, and the lack of any good references on how to do solid TDD or BDD in Javascript (with Prototype, or otherwise I suppose). I’m aware of rspec clones in javascript, but what I’m missing is the big picture on how to integrate those tests into the main test suite and what to use for mocks and stubs. I want to be able to write the bulk of my JS tests in textmate, without having to start a browser or use anything like Selenium.

Related Content:

Posted by Rob Sanheim at 4:03 am
19 Comments

+++--
3.2 rating from 63 votes

19 Comments »

Comments feed TrackBack URI

I’d say Prototype is an excellent library when you are developing a Javascript rich site, my only criticism is of course the lack of documentation, but that seems to cover a lot of the JavaScript frameworks out there today. In fact, from a corporate perspective, this can really hinder their widespread usage – a company may not necessarily want to develop a Prototype-dependant Web app if the only source of documentation is someone’s blog. A project may become dependent on a single developer who knows the framework, and it becomes difficult if developers change because they may not immediately know the framework.

I’d say the size of Prototype is also a killer… well… its a killer if your not actively using all the niceness in your Webapp. For instance, if you are just using the AJAX request and the $() bits, you are incurring a 60kb filesize hit for probably about 2kb of functionality. This is something I’m seeing more and more – people using whole frameworks for simple interactions. Its overkill and slows down your site!

It would be interested to see if that second problem could be tackled within an IDE, say you have an ‘Optimize JS’ function, which looks at your JS code and dynamically builds the supporting framework .js file, putting in just the functionality which is needed to make your site work, trimming out the redundant bits. Anyone up for the challenge?

Comment by Chris Korhonen — December 29, 2006

Its a lovely idea Chris, I really like the way MooTools has a compiler that does a similar job. But a IDE that analyses your work and does it on the fly would quickly reduce most concerns of speed/size regarding almost any js framework.

Comment by David — December 29, 2006

As I wrote on my post, I don’t think that prototype.js sucks. The primary point when writing my post was that many people abuse (under-utilize) prototype.js. They use the entire library just for a few functions and hence, the title “prototype.js != $()”. I believe that there are many tutorials such as this one that show people how to use AJAX and they do it using the prototype library. Hence, a lot of people think that prototype.js is an AJAX library and use it for XMLHttpRequests when AJAX is only a small part of the library. Even Digg, one of the best social sites today, includes slider.js and I don’t think it uses a slider control . Am I missing something here?

So, the problem here is with people abusing prototype.js and of course, that does not mean prototype.js does not have problems. But I am a bit baised against using javascript libraries in general. If everyone did not use libraries, debugging would be much easier and they would learn much more in the process. After all, Javascript is a simple language except for browser discrepancies.

Chris’s idea of Optimising JS is really cool

Comment by Chim — December 29, 2006

We’re a world full of monkeys with keyboards, this could go on forever. It’s very easy to rehash an argument on what some people see as being wrong.

for…in – It’s gonna be that way until JS 1.7′s native iterators can be used by every browser. In other words, it’s not gonna change in the foreseeable future. If you don’t like that, don’t use it.

File size – Dojo anyone? Honestly, the load time between 15kb and 50 kb isn’t that much, and it’s cached on the first go around. Has anyone actually run an benchmarks on this? If the sky is falling, I want proof. gzip if need be. It takes about 10 minutes to add semicolons in and compress Prototype with a packer. I’ve seen CSS files that are far heavier.

Documentation – Easy to kick an open wound. But we’re working on it, you won’t be disappointed. We don’t have financial backing, and my wife would be disappointed if I couldn’t pay the bills.

In the end it boils down to the same type of people complaining about the same thing. But before you go popping prototype.js blindly into all of your pages, these are things you should consider.

Comment by Justin Palmer — December 29, 2006

There is one more decent reference. I’ve been using it on O’Reilly Safari.

http://safari.awprofessional.com/0596529198

Comment by matt m — December 29, 2006

Size is an important issue, but it is very relative. If you are using 90% of the functions in this library for various purposes through out your application, than Prototype is amazingly small. But as Chim was saying, if you only using the “$()” function and nothing else, than Prototype is terribly bloated for your usage (in which case you are much better just copying that function out of prototype and using it).

Comment by Kris Zyp — December 29, 2006

Chim: Its in developer’s nature to use libraries, because we are lazy. That means that much of the library will go unused by 90% of those using it, which is just how things work out. Look at Dojo – even with one of the smaller builds I’m betting most devs don’t have a clue what is going on underneath or just what they can do with it. Thats a good thing, though, as it lets you get stuff done w/o having to know the nuts and bolts. There will be a time for learning the guts, and there will always be those people who are curious enough and passionate enough to dive in. For the “rest” of programmers, knowing the primary things a framework does for them is usually enough.


Justin: Isn’t wasn’t an attempt to kick you guys – I just hadn’t seen any updates since a comment in November. A simple “we are working on it” would be fine.. =)

Comment by Rob Sanheim — December 29, 2006

So that those are not aware of it, there is an existing project being developed as a part of Dojo called the JSLinker, which does exactly what Chris asks for: it will scan your code and remove all dead code paths. Obviously this isn’t completed yet but the initial results look *very* promising.

As far as download size goes, I honestly think that there is too much paranoia going on about file size downloads (unless you really do start getting into major ones, such as trying to push *all* of Dojo to a browser–which is kind of ridiculous). I’ve worked on corporate sites where optimized images still push the 40kb barrier–if not more–and the reality is that in this day and age, most of the people using more advanced apps are much more likely to be on some sort of broadband connections than not. This doesn’t mean one should go hog wild, of course–downloading many files is still not a good thing–but taking it to some of the extremes mentioned seems a bit, well, extreme. All of these choices need to balanced; you can’t just say “this is bad because of the file size download” without also taking into account a good portion of what is actually being used.

Of course, there’s always what I like to call “spurious linkage”, which many frameworks are guilty of; these things need to undergo constant refinement, which Prototype does seem to do (as well as Dojo).

Comment by Tom Trenka — December 29, 2006

Tom, do you know if JSLinker is going to be Dojo specific, or something which will work independent of the framework being used?

I’ve found the site (http://archive.dojotoolkit.org/nightly/tools/jslinker/docs/readme.html), but some of it leads me to believe that the more cook stuff will only work for Dojo based apps.

Comment by Chris Korhonen — December 29, 2006

JSLinker can be used with any kind of javascript code you like… It will try to analyse and optimize whatever you pass to it!

Comment by andyhot — December 29, 2006

The problem with extending the Array prototype is *not* associative arrays (pretty much everyone agrees now that you should use Object for that) but sparse arrays. for..in is the *only* way you can tell between a never defined item and an item set to undefined and it’s also the only efficient way to enumerate the items in a very sparse array. Having stuff hanging off the prototype just makes it more difficult than it needs to be.

Comment by Bertrand Le Roy — December 30, 2006

God, Dojo has so many great projects that I feel like it often doesn’t get the attention it deserves. There needs to be some high-level breakdown of the project so that it can be better understood by developers..

I feel like the reason that prototype and scriptaculous get so much attention is because they are simple to define: they’re frameworks. Dojo, on the other hand, is so much more; it’s a framework, it’s a packaging system, it’s components, it’s a developer toolset… It’s difficult to sort it all out.

Comment by anonymous — December 30, 2006

David,
Slider.js is part of Script.aculo.us, not prototype.

Justin,
Well said. Most HTTP servers compress content before sending, anyway, so the 54k file becomes

Comment by Beau — January 3, 2007

The issue with a lack of Prototype documentation is a big one. There are plenty of gotchas, none of them are clearly explained.

As for for..in, Prototype 1.5 itself uses it. Moreover, it is dependent on properties being returned in the order they are added, which is very dangerous since the ECMAScript spec specifically says you shouldn’t to that and it is known that some browsers don’t do it.

Prototype has its issues, I just wish people would do balanced discussions in regard to it rather than the black-and-white absolutism that seems so popular.

Comment by Fred — January 18, 2007

The issue with the lack of documentation has been solved as been written here:

http://ajaxian.com/archives/prototype-15-now-with-documentation

Comment by Dave — January 19, 2007

The file size of a js file isn’t the problem – it is cached anyway, so you only download it once unless you clear your browser cache. The problem is the time it may take to parse the file, which is done again and again on every page load.

Comment by Michael — February 23, 2007

Compressed versions of Prototype:
http://ajaxian.com/archives/compressed-versions-of-prototype

Comment by anon — March 13, 2007

I love prototype because it has good wrapper functions that can handle cross browser issues really good. I need my code running on multiple browsers.
I don’t agree that everyone should not use library. A good language like java needs encapisulation, that ppl don’t always need to reinvent the wheel. That’s how complex functionality come into being.

Comment by Gang — June 26, 2007

My experience with Prototype/Scriptaculous has been very, very frustrating. I much prefer jQuery, which is 80k lighter, has truckloads of functions, effects and plug-ins. The syntax was extremely easy for me to grasp in a very short amount of time.

In Prototype, it took me a long time to figure out how to apply a Scriptaculous Opacity effect to an array of objects. In jQuery, I did it in one, very short line of code, and thanks to the documentation, it was easy to find out how to do this.

I’m moving a lot of my freelance development to Rails, and would love to find a reference as good as jQuery’s for Prototype/Scriptaculous, as they’re baked right into Rails, but I just can’t seem to find one that has examples similar to what I need.

I’m sure my experience with Prototype/Scriptaculous could be as smooth as jQuery, and I am all for learning those libs, but so far, my opinion of them from a usability standpoint is not so great.

Comment by Brandon — July 5, 2007

Leave a comment

You must be logged in to post a comment.