The JavaScript Age
metamarketsgroup.com
metamarketsgroup.com
I love all the above technologies, but nothing is dead, everything is evolving, and I currently look at node.js a really great software toy that has a very prosper future, but that's it. It still needs to mature.
Besides, we all know what "drinking the cool aid" sometimes does don't we (I'm looking at you twitter).
Since 2005 (available to the public in 2008), we've (along with numerous other platforms) been offering event-based websites and WebApps, via PHP with NOLOH (http://www.noloh.com). In NOLOH, you the developer worry about writing your application, what it should do, how it should look, etc. and specify events on things, such as click, or your own custom events, and NOLOH takes care of the rest. In the case of a JavaScript enabled client, it'll render only the necessary JavaScript and DOM elements for that device at that given point in time and handle all the AJAX (and Comet where applicable), for search engines it will generate a semantically rich and standards compliant HTML version along with links to normally "non-crawlable" content. Similarly for text-based browsers, or non-JavaScript clients it'll output HTML. Furthermore, in the case of mobile devices, or slate devices, it'll output the correct code so that your app along with its clicks and drags still work. In all the above cases, the developer writes no JavaScript, nor does he even need to know that the client exists, he simply writes his app and it works. He/She can of course still use JavaScript if they please, but in most cases it's unnecessary, unless you're dealing with legacy code, or existing JavaScript widgets, and even in those cases, we abstract it out so that you can bind and sync without getting down into the nitty gritty.
So I don't believe the premise that we're in the JavaScript age is correct, as in many cases, you don't even render JavaScript, however, I do believe that the premise that we're in an event-based age is correct, I would even go so far as to suggest we're heading towards a platform or unified language age, as that's really the only way the craziness of the web is really manageable for rapid development, whether it's JavaScript, NOLOH in PHP, or something else, and I thought so in 2005.
Disclaimer: I'm a co-founder of NOLOH
[Edited: spelling and clarity]
I used to hate JavaScript, but now that I've spent so long working with it and Canvas I enjoy it a lot. Obviously it is not the best possible language for the future of browser applications, but it's here already, and it will do.
"use strict"; Cannot come fast enough.
How much difference a platform can make!
I haven't used JS server side so I don't have a comparison, though.
Delete the trailing comma in your object literal.
For large, essential apps I can see that. Although there are tools that make the experience much better.
But man do I love what JavaScript and browsers have blossomed into. I've always wanted a really nice, simple environment where I can just write a small, self contained app with little overhead, little fuss, and wide ability for it to be adopted. JavaScript plus the new HTML5 goodies fulfills that wish far better than anything else in the past. I've grown to really fall in love with the little bastard language :)
Secondly, search engines don't play too well with the Ajaxy web apps. It's not that you can't make them search engine friendly, it's just that once you do that, there's a bigger need for the "normal" frameworks.
Thirdly, I still prefer languages such as Python or PHP to JavaScript.
Search engines are for finding content, not for apps. If you have data in your app that a search engine could reasonably want to index, give it a resourceful route of some kind, and tell engines where to look - if that doesn't make sense, it's probably not a resource an engine would be interested in.
I agree, and one of the points that I forgot to write above is that the article seems to focus too much on apps. A lot of web development isn't about apps.
Events are fundamental too, and I'm quite happy that the web seems to be evolving to handle them as well.. But resources will always exist, and any 'event' that has enough data for an engine to be interested in indexing it is carrying a resource.
Also, handling lots of requests for small, static content is note exactly a tough problem. (Although it requires a minimum of care.)
To any author who cares about what he writes (publishes), being read by many people is a great chance. However, crappy blog software deliberately destroys all those nice opportunities in advance.
Mind you I am not convinced that event driven js is going to deliver high performance blogs either.
Must move my blog off Wordpress before getting featured here...
Those characteristics mean it can handle more simultaneous connections, but don't directly lead to more speed. I feel that is worth nitpicking about. Nodejs is pretty fast, but I think that has more to do with V8, libev, libio, and Ryan's http parser being really fast.
- an I/O multiplexor syscall must be called from time to time. Select/poll/kqueue/etc. These extra syscalls introduce overhead on top of the already required read/write calls.
- the event loop has some overhead too.
- the fact that read never blocks means that the kernel can't apply certain optimizations such as having the peer directly write to the receiver's read buffer instead of copying things though multiple buffers.
That said, I think microbenchmarks like this are bullshit. The overhead is so small that you never notice a difference in production. The benefits of evented architectures are clear: you can handle a much larger concurrency level and you use less memory thanks to not having to reserve so many threading resources.
However too many people seem to be ignorant about this and think microbenchmakrs mean something. All they care about is that 10000 req/sec > 8000 req/sec.
I am actually looking into switching Phusion Passenger to an evented architecture, but I'm a little reluctant to do so because I fear people would microbenchmark it, see that it's slower and conclude that Passenger X sucks and is slower than Passenger X-1 or $COMPETITOR.
Javascript is impossible to scale past the trivial application at the moment. Trying to read someone else's non-trivial source code in javascript is a total nightmare. It's too hard to write a big app in!
So it's not going to be the next big thing. It's a play language and always will be.
Unfortunately it's the only choice we have in the browser. If we had any other major language in the browser, even c++, it would have died long, long ago. We wouldn't even be talking about it today.
Still... 440k+ isn't small.
Javascript suffers from a lot of historical baggage and a lot of bad javascript on the web. One of the most helpful developments in the past few years has been the emergence of a "better" subset of js, led by Douglas Crockford's mafia, jslint, jshint, jsonlint etc.
It's hard to argue that any language+platform has a more vibrant ecosystem right now than js+node.js
Dismissing javascript as a 'play language' is to ignore, well, the internet. Sure, it's imperfect.. maybe more than most languages. But it's also wildly powerful, and there are plenty of ways to make large js codebases quite reasonable (ours is, and we build one of the most complex javascript front ends I'm aware of).
Suggesting that C++ would be a better language for writing web UIs really seems especially ridiculous to me. Have you written GUIs in C++? I have, and I assure you they're no nicer to maintain than javascript ones. In fact both languages require a similar amount of discipline and order to grow maintainable codebases with. The same is true for pretty much everything.. and when it comes down to it.. front-end code of any format can be very hard to keep manageable.
Javascript with tools like google's closure kit is about as reasonable as anything else I've built a front end with.
Yes, it is informed with experience.
My point is that if javascript were not the only language available in the browser it would have died years ago. Citing the example of the internet is like flogging a straw man. The only reason it's on the internet is that there's NO other language competing with it, apart from vbscript long, long ago which only worked in IE when Netscape Navigator was still around so won by default.
So your point was? Cause I really, really don't get your thing about Dismissing javascript as a 'play language' is to ignore, well, the internet. I already explained that one quite clearly. It's the only player in that space and the only reason why anyone even bothers with it.
The C++ was a semi-joke, but you've got to read it in the context of the article and javascript winning big server side. It's never going to happen. The article is totally fubar.
Javascript is one file. Everyone writes it like that in a single closure to make sure it never interferes with anyone else's namespace. Because of the total joke of variable scope. It's a nightmare when it comes to maintainability.
That's my point. It's not portable, it's not at all transferable. It's not at all appropriate server-side for anything apart from play sites.
I'm sure you've done great things with javascript client side but it's never going to be a great language server side because it's just not maintainable.
Generally speaking against javascript as well, it's a total pita when it comes to reading someone else's code anyway. You can't pick up someone else's code and know what's a constructor, what's static, what's a singleton, what's the actual entry point for the whole thing. There are still competing patterns for just writing a god-damn object constructor (Resig style vs Yahoo style, even though Resig's is clearly superior). And even then it's scattered about like crazy. There's absolutely no logical structure to it.
Anyway, talking to myself now. Signing off...
This. JS' success is because of lack of alternatives. It's astonishing that some people actually advocate JS.
That would be true if you write it as one would write a C++ program, or even to the sizes one would write C++ programs in.
If you structure your program as a set of responses to events (the user clicked this button, this field lost focus, post/get resquest to this url) you automatically split the program up in many smaller pieces.
In addition a program that would be a million lines of C++ might very well be a lot less in Javascript, since C++ lacks a lot of the features which Javascript has (first class fuctions being one of them).
To say something like that, you must clearly not understand the premise of the language.
Javascript is not a play language - it's a very powerful hybrid of Scheme and Self, with a C-like syntax, which makes it easier for most people to get started with. Using functional programming paradigms, rather than class based ones, makes Javascript scale very well to large applications.
The author points out that Douglas Crockford's writings have played a big part in the language's resurgence - his book "The Good Parts" was what turned me, and I suspect a lot of others, back on to Javascript.
Two "pro" points, no comparsions, and it is declared "ideal"?