Node.js and MongoDB Turning JavaScript Into a Full-Stack Language 354
Nerval's Lobster writes "For all its warts and headaches, JavaScript has emerged as the lingua franca of the modern Web, arguably second in adoption only to HTML itself, which obviously is just a markup standard rather than a full-fledged programming language. It's effectively impossible to launch a sophisticated Web project without making extensive use of JavaScript and AJAX dynamic loading. That's precisely why recent projects that move JavaScript beyond its usual boring domain of defining in-browser interactivity are so interesting — because it's already dominant, and growing even more so. Writer and software developer Vijith Assar argues that Node.js and MongoDB are turning JavaScript into a full-stack language. 'In the grand scheme, Node and Mongo are still quite new; for the most part, ace JavaScript developers who can write brilliant code on both sides of the request transaction have yet to emerge,' he suggests. 'But if and when they do, the things they build could be jaw-dropping.'"
Full Stack? (Score:2, Interesting)
partly engineering resources put into compilers (Score:3, Interesting)
I wouldn't necessarily pick Javascript on its merits as a language, but for a language as dynamic as it is, it has very good optimizing compilers, probably research state-of-the-art for this kind of language (Google's V8 engine is largely built by ex-Smalltalk researchers). That gives it some advantages over, say, Python.
Javascript anywhere but the browser? No (Score:4, Interesting)
Javascript isn't really a very good programming language (its lack of strong typing and lack of pointers are two things that often frustrate experienced coders). The only reason it's so popular is that it is a universal standard for client-side scripting in the browser. If you want to run code on the user's web browser, you have to use Javascript.
On servers, that doesn't apply. There are much better languages, no matter which platform you prefer. And MongoDB isn't particularly impressive, either; it's basically a database for people too stupid to understand SQL.
No, node.js and mongodb are cancer (Score:4, Interesting)
The real thing that's turning javascript into the lingua franca of the web are really three things:
It's an inside-out stack.
Re: Citation Needed (Score:5, Interesting)
Anecdotally (having worked with node.js for the past year or so), whenever I've needed to do something not available in the core libraries, there has been an npm [npmjs.org] for it, usually several. But - and this is a rather big but - their maturity can vary quite a bit. The biggest issue really is documentation, that can be incorrect or completely out of date. Yes, there always is the source, but that's hardly ideal.
Having said that, in general I do like node.js. It takes some time getting used to and you have grasp Javascript well in order to use it efficiently, but if you're working with JSON data (we use CouchDB) it's quite a natural fit.
Re: Citation Needed (Score:5, Interesting)
I was speaking to a friend of mine the other day, who said "Don't you find it bizarre that Javascript has become the assembly language of the web?"
And that's just it: I think javascript sucks, and I avoid it whenever possible. Instead I use CoffeeScript, which I find unobjectionable. Sure, it "compiles" into javascript - and I don't much care.
I pointed out that I never really learned assembly when I was cutting my teeth (decades ago), and so I really didn't care what was down there. It's kind of nice that I know enough Javascript to debug tricky issues when the need arrises.
I thought that coding in assembly sucked, too - still do. The higher the language, the more I tend to like it. Besides CoffeeScript, I'm keeping an eye on Dart.
So, yeah, it's bizarre that javascript has become the assembly of the web world. But it runs all over the place because it runs all over the place. Whatever. As long as there's something better to write code in than javascript, it doesn't bother me...
Re: Citation Needed (Score:4, Interesting)
Personally, I find that cognitive load (or since we're talking about the web, perhaps a "cognitive refresh") to be a valuable thing when jumping tiers. There are things that must inherently be done differently depending on if you're on the remote client or local server. Access to data has vastly different cost, security expectations of the runtime change, consistency of the runtime environment (and thus how close to the "edge" of the environment's capacities you can target) change between a reasonably well controlled server environment and Aunt Tilly's IE6 install.
I find that needing a moment to shift gears when moving between tiers helps recalibrate my mindset about the target environment. It helps keep me from doing (as) stupid things that while standard practice on one tier (and thus in one language) are unacceptable on another tier. The difference in language is a bar to code reuse (which is a good thing with code that *shouldn't* be reused in the other environment), and it tends to reduce the frequency that I shoot myself in the foot.
Re:No, node.js and mongodb are cancer (Score:5, Interesting)
Re: Citation Needed (Score:4, Interesting)
There are a couple of advantages.
For one, the ability to run the same code on the server and client can be very useful. A number of years ago, I remember a presentation on GWT (framework for writing client-side code in Java) where the presenters mentioned that their app would benchmark the client and, when the client's DOM manipulation wasn't fast enough, would use an AJAX request to do the manipulation on the server and pass it back as HTML which was put into the document using innerHTML. In both cases, the exact same source code was executed, but they had the flexibility to run it in both contexts.
Also, using the same languages allows you to minimize the frameworks and technologies you use, making it easier for developers to know them in depth and making it easier, in general, to find developers. You also get a lot more organizational flexibility when developers can be assigned to either front-end or back-end tasks or even hybrid tasks that would otherwise require two different developers with separate skill sets to complete.
Node has been very successful thus far by making use of one important observation...the majority of applications spend most of their time waiting for things (mostly IO) to complete rather than actually doing something. This allows it to use a language that is still, by comparison, dog slow and still be faster than implementations in other languages when implementing most problems. The thing about functional languages like JavaScript is that they're ideally suited to the asynchronous style of programming where every call takes a callback and completes immediately. But functional languages don't seem to get used server-side. There is some Erlang (WebMachine and Riak are awesome at what they do), but most server-side languages are OO and make it very difficult to do this sort of asynchronous programming in a way that feels natural to the developer.
The problem with Node taking over the server side is, as mentioned, JavaScript is still dog slow. There will be times when your bottlenecks are computational and not IO. The Node answer to this is to drop to C/C++, but how many JavaScript developers can do this? Still, no matter what you think of JavaScript as a language, Node.JS is asking some very interesting questions about the nature of server-side programming and which optimizations are most important. Dismissing it because of the toy language it uses is a mistake.