Modern JavaScript(blog.rebeccamurphey.com)
blog.rebeccamurphey.com
Modern JavaScript
http://blog.rebeccamurphey.com/modern-javascript
32 comments
Suddenly CoffeeScript makes a lot more sense to me:
"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"
So true. The JavaScript we've got now is the assembly language of the client-side. We can't easily change it, but we have to start building better tools on top of it.
"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"
So true. The JavaScript we've got now is the assembly language of the client-side. We can't easily change it, but we have to start building better tools on top of it.
A pretty decent part of the CoffeeScript MO is to start implementing things proposed for future versions of JavaScript ... but that we won't be able to use cross-browser for years and years. For example:
* 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
* 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
This reminds me of Scala X expecting Java 7 discussion. I like the fact that we, as more agile communities (Scala's and Coffeescript's), decided that we should not wait for committees, and we should control the languages we want to use it. And we won't wait 2/3 years. We are doing it now.
I still think Javascript is a pretty elegant language. None of it's features are unique to only it, but it's the combination of the prototype model, the completely dynamic nature, the ability to easily convert objects to and from strings, the callback nature... all of that together makes it as elegant as any language I can think of. At the same time I welcome CoffeeScript and the many DSLs appearing on top of Javascript (Mobl, for example).
Indeed. When you consider the alternatives at the time, Java and VBScript, JavaScript doesn't look so bad...
>So true. The JavaScript we've got now is the assembly language of the client-side.
Huh?
Javascript is a high-level, dynamic language with very nice metaprogramming capabilites (compared to Ruby: http://fingernailsinoatmeal.com/post/292301859/metaprogrammi...). Totally bizarre to compare it to assembly.
Huh?
Javascript is a high-level, dynamic language with very nice metaprogramming capabilites (compared to Ruby: http://fingernailsinoatmeal.com/post/292301859/metaprogrammi...). Totally bizarre to compare it to assembly.
It's an appropriate comparison. Javascript was designed as a helper language, not what it's become - the level we code guis at. We need something more dynamic than html and less programmatic than javascript.
The core message is good but I think Rebecca's obsession with jQuery just kills here ability to deliver it.
jQuery is not a problem. jQuery's popularity is not a problem. Complex applications are the problem. People not knowing how to structure complex applications are the problem.
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. These are just tools that can be misused. Sorry, Rebecca, but if dojo were as popular as jQuery is the JavaScript land would not be any better than it is now. It would be just a different tool misused, that's all.
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.
Structuring complex applications is hard, no matter what language you use, it's not some trouble only JavaScript has. True, JavaScript comes with a couple more complications in that regard but these are minor in the context of the problem.
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.
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. These are just tools that can be misused. Sorry, Rebecca, but if dojo were as popular as jQuery is the JavaScript land would not be any better than it is now. It would be just a different tool misused, that's all.
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.
Structuring complex applications is hard, no matter what language you use, it's not some trouble only JavaScript has. True, JavaScript comes with a couple more complications in that regard but these are minor in the context of the problem.
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.
I appreciate your feedback and understand that previous posts of mine have framed this as a jQuery vs. Dojo debate; I tried particularly hard not to do so in this post, and I think you'd be rather hard-pressed to say that this post was a "jQuery vs. Dojo" diatribe. Yes, it linked to my Berlin slides, but that's simply because a post in response to them is what got this whole post percolating in my head to begin with.
The fact is, though, jQuery and Dojo are the two libraries with which I am quite familiar, and so they are the two libraries I am most able to compare. Having used both, it is easy to see the weaknesses of ... both! I truly believe there is a "jQuery divide" -- there are people who think jQuery is what there is to know of JavaScript, and that it can solve all of their problems; then there are the people who know there is more, either because they have always known or because, like me, they've discovered it through some painful mistakes.
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.
None of this is to say that jQuery is not a useful tool, and the right tool in so many situations! I have used it, I have contributed to it, I have taught it, I have recommended it. Its API is seductive and its API is a huge contribution it has made to the JS landscape. The point, though, is that it's just an API -- an API that can be and has been be readily replicated. My experience has been that other libraries' APIs can have their own elegance, once you get used to them. The problem is that the appeal of jQuery's API I think is what can lead people to keep approaching problems in a DOM-centric way long after it makes sense. I do not fault jQuery for this, but I think as a wider JavaScript community we do well to discuss -- and not in an us v. them way! -- other viable approaches that exist.
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.)
The fact is, though, jQuery and Dojo are the two libraries with which I am quite familiar, and so they are the two libraries I am most able to compare. Having used both, it is easy to see the weaknesses of ... both! I truly believe there is a "jQuery divide" -- there are people who think jQuery is what there is to know of JavaScript, and that it can solve all of their problems; then there are the people who know there is more, either because they have always known or because, like me, they've discovered it through some painful mistakes.
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.
None of this is to say that jQuery is not a useful tool, and the right tool in so many situations! I have used it, I have contributed to it, I have taught it, I have recommended it. Its API is seductive and its API is a huge contribution it has made to the JS landscape. The point, though, is that it's just an API -- an API that can be and has been be readily replicated. My experience has been that other libraries' APIs can have their own elegance, once you get used to them. The problem is that the appeal of jQuery's API I think is what can lead people to keep approaching problems in a DOM-centric way long after it makes sense. I do not fault jQuery for this, but I think as a wider JavaScript community we do well to discuss -- and not in an us v. them way! -- other viable approaches that exist.
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.)
Oops -- that's a very good point about the Model example being a bad one -- I was just trying to use something visible, in order to see the "change" event binding in action. Perhaps we should swap it out for something more model-y.
These days, if you're looking for complex Backbone examples, there's a bounty to choose from:
* http://getflow.com
* http://m.soundcloud.com
* http://basecamphq.com/mobile
* http://getcloudapp.com
* http://www.documentcloud.org/public
These days, if you're looking for complex Backbone examples, there's a bounty to choose from:
* http://getflow.com
* http://m.soundcloud.com
* http://basecamphq.com/mobile
* http://getcloudapp.com
* http://www.documentcloud.org/public
One other question: are there Backbone examples small enough to digest but large enough to be more authentic than a to-do list? This is where I struggle to come up with good teaching examples -- a whole real-world app is simply too much to take in when one is trying to transition to a JS app mindset (and of course the code is usually minified/obfuscated), but examples like to-do lists are so simple that they don't show how a tool addresses actual real-world problems.
Thank you for these :) I admit the last time I went hunting was a while ago, it's good to see so many more. For various reasons, the templated widget part of Dojo made it the right choice for my current project, but I strongly suspect a Backbone project will be in my future, either for fun or profit.
Excellent stuff. One issue Murphey's slides mention only glancingly is the Javascript-as-visual-design-aid vs. Javascript-as-programming-medium conflict. If jQuery is DOM-centric, well, a whole lot of JS jobs are "make it look professional using HTML, Javascript, Photoshop, and your trained artist's eye," so why shouldn't it be DOM-centric?
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.
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.
I wish Javascript has an easy to use unified library/module system. Something like,
Edit: Ha, a reply was deleted so fast that I didn't have a chance to reply to it. To clarify, Sha1.1.3.1 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 "http://ajax.googleapis.com/js/sha1.1.3.1"
Edit: Ha, a reply was deleted so fast that I didn't have a chance to reply to it. To clarify, Sha1.1.3.1 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.
If library writers were to use CommonJS Modules (i.e. just use require() and exports), we'd be most of the way there.
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.
http://github.com/mckoss/namespace
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.
http://github.com/mckoss/namespace
[deleted]
The problem is that browsers don't deal with libraries. You can implement a module and a script loader system, but in the end of the day you will concatenate most scripts for faster download and initial page rendering.
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.
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.
Argh, I hate reading slides without the accompanying audio/video, because I feel like I miss out on 90% of the context.
What are you referring to? This is a blog post and the talk that she refers to in the first paragraph has full audio/video available here: http://jsconf.eu/2010/speaker/the_jquery_divide_by_rebecca_m...
Hope that helps your hate.
Hope that helps your hate.
To be fair, she doesn't link it from the blog post.
Awesome - thank you, I'll watch that.
As a speaker, let me just say that I have yet to figure out how to handle this. When I'm presenting, I want people listening to me, not reading the slides. When people are consuming the slides online afterwards, they can quickly get misconstrued without the context of my spoken words. All of that said, I'll add a link to the video from the blog post :)
I have come to the conclusion that communicators must present to different audiences in different formats. Slides used in public speaking are no different from hand gestures. Slides posted online for the same speech have to be touched up or completely redone for the new online audience. The audience who heard my speech might benefit from having a copy of my slides as memory cues.
The only good way I have seen it handled without a lot of duplication or extra work is to have the speaker's own notes as a handout, and the presentation just for the audience. Of course that takes a little planning up front.
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.
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.
Consider, then, not referring to your slides as expository material. Instead, add paragraphs to further develop the discussion.
I think you've got it backwards, at least when it comes to good talks. It's always seemed to me that at least 80% of the important content is usually discernible from the slides (especially since you can probably infer the other things that the speaker was talking about, minus stuff like stories and jokes which are usually fluff anyways).
I don't really have it backwards - I'm just describing my experience. :/
I also always heard that slides are supposed to be guideposts to a presentation, not the main point of one.
I also always heard that slides are supposed to be guideposts to a presentation, not the main point of one.
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.
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.
I was too; that's why I said "I think". I've heard that too, but it nearly always seems like the "good bits" get put in the slides while a lot of the other things that the speakers say I could have done without. Of course, the rest of the stuff is often interesting, just not usually nearly as useful.
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.
Blaming browser vendors or our ecma overlords for package standards seems like a bit of a straw dog because javascript isn't a package distribution mechanism, it's a programming language. If you want to build apt/npm for browser js via require.js+jquery or your combination du choix, then by all means, but this isn't a failing of the language just as brew failing to install mutt is not a failing of ruby.
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.
I'm all for innovation, but i could do without "enterprise javascript" (isn't that was es4 was and, i mean, i'm not exactly losing sleep over that decision). For proof positive that we're already getting the 'roll your own' strategy, check out the modernizr 2 beta (or, the less modest jq-ui).
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.