"the language itself is held hostage by browser vendors, some of whom have shown a strong inclination to not give a fuck about owning up to and fixing their egregious mistakes"
* Destructuring Assignment.
* Splats (Variadic Arguments).
* Lexical "this".
* Array and Object comprehensions.
* Classes (As sugar for prototype wrangling).
* String interpolation.
... to name the bigger ones. Many of these can be found in draft form on the ECMAScript Harmony wiki: http://wiki.ecmascript.org/doku.php?id=strawman:strawman
Let's see the context there: jQuery is wildly popular, but it is the right tool for the job in most cases. Not all web pages jQuery is used on are webapps. Not all webapps are GMail. Yup, jQuery is "DOM, AJAX and effects" library which is great for trivial tasks. A lot of tasks are trivial.
But there is no "jQuery divide", like there was no "Prototype divide" some six years ago.
The second point she is way wrong (again, IMHO) is the API. Don't you ever underestimate
the importance of the good API. When you have tools X, Y, Z which more or less do the same with more or less the same performance, API is the main differentiating factor it's the think you write and look at the whole day. jQuery's API
is awesome for many reasons. Dojo's is not.
What she is right about it's the lack of good examples going beyond the basics. But I think the reason for that is that we are just on the way to find out what works reasonably well. It will come, I hope.
So my point is: stop talking about jQuery and dojo. Talk about the core of the problem (and any js lib is not the core).
Oh, and I would like to see Rebecca's take on backbone.js.
What I am asking for, in this post and in my Berlin talk, is for the people who know there is more to take some responsibility for bringing the others up to speed, to show people what can be done if you leave behind the "get some elements, do something with them" mentality.
Finally: Backbone is a viable entry in the field, and I am eager to see more complex examples (to-do list applications fall far short of this) that use it. I haven't used it personally, but I mostly like what I see and have heard good things about it. Unfortunately it had just come out right before my Berlin talk, and while I may have mentioned it in my actual talk, it isn't in the slides. (That said, I do cringe a tad that its examples suggest (http://documentcloud.github.com/backbone/#Model) that a "Sidebar" is a thing that should be a model.)
These days, if you're looking for complex Backbone examples, there's a bounty to choose from:
That suggests those who fight the good fight from a software engineering perspective will not win with a frontal assault. C++ and Perl were both subject to years intense pressure to rethink their basic assumptions; both refused* and carried on with more-or-less the same group of folks who loved them warts-and-all.
In other words, the evidence suggests that it will be easier to move forward by organizing and strengthening those who agree with Murphey (and Crockford, etc.) than by converting those who, to use her phrase, "don't know what they don't know" but can do amazing things with Photoshop.
* I acknowledge there is an argument to be made that Perl 6 contradicts my assessment. My point is that Perl 6 has not brought a bunch of previous Perl critics into the fold.
You see this all the time in even jquery packages: are they $.pkg.method(elts) or $(elts).pkgmethod() or is it $(elt).pkgmethod(spec) or .... and so forth. Part of it is a matter of taste even if sometimes it goes against 'the jquery way.' Again, this is so religious that it's often not even worth fussing over.
Certainly, there's bound to be some overlap in packages, but this happens everywhere and who cares? underscore+jquery seems like a strange example especially when the two are complementary. If the goal is to have a "lightweight core" with "components that deliver specific, isolated functionality" i mean, aren't we there right now? And for where we're not, as mentioned by other commenters, coffeescript and friends certainly seem to be fighting the good fight.
If the point of modern js is that people are working together and optimizing, then yay!! but if the point of modern js is that we need to abide by some static discipline where each function only accepts a single spec object and conforms to some require.js loading protocol then, umm.. thanks but no thanks.
Edit: Ha, a reply was deleted so fast that I didn't have a chance to reply to it. To clarify, Sha126.96.36.199 was meant to be an example of a library, not the SHA digest of a library, though that would be a nice feature. Also "require" should be a feature of the language, not using the html <script> tag so be able to work in the server environment.
Require.js and AMD still feel like they are not appropriate in all scenarios (e.g., I really don't want or need a "loader" in simple single page applications).
This is my suggestion for a very light weight way of using CommonJS Modules in the browser which is agnostic about how your scripts are loaded.
The big problem is that we still have: IE6, IE7, IE8 and probably IE9 too
They are too slow, they will not allow you to write nice modularized code.
Hope that helps your hate.
Good talk, watched it a few weeks ago, still trying to work out how to solve dependancies on my application in an extensible easy to hand over to other devs way.
I also always heard that slides are supposed to be guideposts to a presentation, not the main point of one.
I've increasingly been viewing slides as a means to get people to just look up from their keyboard or phone and stop twittering or chatting for at least a minute or two.