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.

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

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.

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

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.

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.

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).

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.. =)

http://safari.awprofessional.com/0596529198

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.

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

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?