Prototype 1.7 | Hacker News Reader

Prototype 1.7

prototypejs.org

30 pointskuahyeow10 comments

Anyone still using Prototype for new projects? I have a few legacy rails apps (over 3 yrs old) that use it, but like most people I've have moved on to jQuery.

I used to favour Prototype.js over jQuery for more complex JS apps and leave jQuery for smaller tweaks.

Nowadays I'd definitely consider something on top of jQuery instead, such as backbone.js (http://documentcloud.github.com/backbone), eyeballs.js (https://github.com/paulca/eyeballs.js) or sammy.js( http://code.quirkey.com/sammy).

Agreed, underscore and backbone.js are amazing. JQuery is awesome at dom manipulation, backbone is great at structuring reusable js components, and underscore provides the prototype like helpers for manipulating collections (underscore.strings is also an essential library).

These 3 tools have me loving js development to the same degree when I first started using prototype (before the project stagnated and died).

Just had a little discussion at #documentcloud regarding UI components (in terms of ui-widgets) that can be implemented using Backbone.View in very efficient ways. Here's just an example of a MultiString editor, that we're using for our document authoring engine. https://github.com/michael/substance/blob/master/src/backend...

You can try out the editor at http://substance.quasipartikel.at:3003/# by clicking on the document's title (at the sheet) to activate the doc annotation pane.

I used to use the jQueryUI widget factory for that task, but Backbone.View feels way more natural. Esp. declarative events and the fact, that Backbone encourages you keep an internal state, and re-render on demand instead of tying data to the DOM.

Regarding UI components in general... imo, it would be better to have a number of widgets (each one targeting a specific use-case) instead of having one widget that takes 100 options handling a number of use-cases. This option-madness is what drives me crazy sometimes...

Same is true for visualizations. developers should keep the codebase small, reusable and should not try to solve 100 use-cases at once — at least this was my conclusion.

As we agreed in the channel, it makes sense to break UIs up in to small functional pieces, each being a view in their own right.

Thoughts?

-- Michael

What I loved about Prototype (apart from changing my opinion about Javascript) was that it sort of extended the language itself, and made more possible with less. But now, I feel coffeescript is a better way to go. What I hated about Prototype was performance. And jQuery is way better there.

This seems to be like Firefox v/s Webkit. Prototype 2.0 is going to fix a lot of things (by not extending the DOM), but that approach is in many ways closer to jQuery.

One thing that we're trying to maintain with CoffeeScript is that the generated code is just as performant as you would have written in raw JS -- i.e. loops are just loops. It would be lovely if that sort of performance were possible in a JavaScript library that supplied "each", but sadly, it's not.

The verbosity problem in JS cannot be solved with libraries, although methods like "each" made life a lot easier.

Seeing CoffeeScript is the first time I've felt I can write a full app in Javascript. You and your team have produced something truly significant.

From the "What's next" section:

The next bugfix version (1.7.0.1) will feature a rewrite of the DOM code to be easier to read and faster at the same time.

That sounds like a lot of impact for a bugfix release.

It does sound like a lot of impact. As long as there's no developer impact and the API remains stable, however, I'm a-okay with the devs pushing something like that into a bugfix release.

I hate that they approach minified versions with, "Do it yourself." 1.7.0.1 is what 1.7 was suppose to be and there is no ETA at all. The future of Prototype is so much brighter in FuseJS[1] once it is out of beta.

1. http://fusejs.com

Reply on news.ycombinator.com