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.
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.
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...
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.
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.
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.
10 comments
[ 13.4 ms ] story [ 37.7 ms ] threadThe 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.
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).
These 3 tools have me loving js development to the same degree when I first started using prototype (before the project stagnated and died).
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
1. http://fusejs.com
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.
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.