We’ve seen various attempts at using JavaScript on the server over the last decade. Mozilla’s Rhino (Java) engine fueled most of it. However, with the release of Google’s V8 (C++) engine (and the networking performance example set by Node.js), the conversation is gaining traction.
The motivation for a 100% JavaScript stack, per conversations at Texas JavaScript Conference (TXJS) last weekend, is the desire to use a single programming language when developing web applications, rather than the mix of technologies we use today. It’s not so much that JavaScript is the best language for application development (contrary to the JS fanboys), but since it’s what we’re stuck with on the client-side, it’s worth considering on the server-side. With a single language, business logic can be reused on the client and the server (think form validation), and you avoid bugs caused by frequent language switching (i.e., using, or forgetting semi-colons, putting commas after the last item in an array, using the wrong comment delimiter, etc.)
The wrinkle in the 100% JavaScript argument, is whether JavaScript is actually the language you want to write your back-end in. The language lacks package management standards (though CommonJS is working to change that); It lacks the standard libraries and tools that the incumbents offer (i.e., no batteries included); Maybe people who use it don’t actually know the language very well; And it suffers from the multitude of bad examples and advice freely available online.
There have been some interesting Node-based applications developed already (i.e., Hummingbird), and the JavaScript on App Engine efforts (i.e., AppEngineJS) will be interesting to watch as well. (I expect both to foster more mature development patterns for large applications written in JavaScript.) However, in the near term, the 100% JavaScript stack will likely remain as niche as the Erlang, Haskel, Lisp, etc. web frameworks (as interesting as they may be.)
The question for you (Mr./Mrs. web developer/web-savvy business person), is whether JavaScript on the back-end offers a competitive advantage. Can you execute on an idea faster/better/cheaper than your competition because of your technology stack?
George Moschovitis 10:49 am on July 22, 2010 Permalink |
The code-reuse benefits extend beyond the trivial form validation scenario. One example: if you are using contemporary ajax techniques, ie passing data to a rich html5 client, you can reuse the same code to render a server side response for search engines. Another example: you can use jquery/sizzle for server side web scraping.
Another benefit: since you are using Javascript all the time, it is easier to come up with better, more intuitive Javascript enabled UIs…
erik 11:06 am on July 22, 2010 Permalink |
The server-side rendering angle is an interesting one as well, particularly for supporting thinner, or older, clients. An example might be building a RIA that gracefully degrades to basic HTML by rendering state server-side and pushing the resulting HTML to the client instead of the more dynamic code. (Hopefully that’s a problem that eventually goes away though.)
I still think the more interesting thing to watch with server-side JS right now, is when, or whether, companies can use it to competitive advantage. From what I’m reading, some companies are already seeing advantages to using Node (either in reduced development time, or reduced infrastructure costs) as opposed to a more traditional web stack.
It’s always an exciting moment when small evolutions in technology fuel fundamental changes in what people can easily build.
erik 11:48 am on August 2, 2010 Permalink |
Another point to consider (inspired by “Node and Scaling in the Small vs Scaling in the Large“), is the amount of work required to make architectural changes. For example, it’s a decent amount of work to port an application from App Engine to Django, Tornado, etc.; But it shouldn’t be a 100% rewrite. With Python, and many other languages, you have an option to deploy your business logic within different frameworks and server-approaches.
With JavaScript on the back-end, what happens if you hit a scaling problem with Node? If analysis recommends moving to a different solution, there’s a high probability of a 100% rewrite (since your choices of JavaScript interpreters/compilers is limited.)