The State of Full-Stack JavaScript

[tl;dr: A brief look at JavaScript-based frameworks.]

I was having a conversation with a guy at work the other day, and I suggested (only somewhat jokingly) that the future of web development would be JavaScript-based, not just client-side, but server-side and database, too. I kind of surprised myself by being somewhat excited about the prospect.

I, like most developers I know, learned to love JavaScript (again?) through jQuery http://jquery.com/. jQuery made writing client-side code fun, similar to the way that Ruby On Rails http://rubyonrails.org/ made writing server-side code fun.

We recently started using MongoDB at work for a specific project http://www.mongodb.org/. We’re calling the project the “Analytics Engine.” It was originally called “Ad-hoc Reporting.” It’s actually very similar to a project I did years ago while working in the Academic Computing department at Dartmouth College. That project was for an undergrad course called “War and Peace in the 20th Century,” and it was meant to introduce students to basic data analysis concepts by allowing them to choose a couple of variables from a dataset and get some statistical information about the individual variables as well as the relationship between them.

You can have a look here: http://dataanalysis.q-media.com/

It’s using a database of terrorist incidents which had come from the Rand Corporation (before Rand had set up their own site for doing this type of analysis). http://www.rand.org/nsrd/projects/terrorism-incidents.html

Please bear in mind that this was just a prototype, and it was also my first ever Rails app (Spring 2006). It’s primative. The full-blown application never got built because the professor who was sponsoring it moved to Stanford shortly thereafter. I’m honestly surprised it still works at all. It’s got a sqlite backend, and it’s based on the idea that all the variables are either categorical or numeric (we left out time-series data, except for filters, as “Year” was entered as a categorical variable).

Anyway, the upshot of all that is that it turns out that databases can be fun, too! MongoDB has proved to be a really slick way to implement this kind of data analysis application. Because the data that we’re doing reporting on comes from a forms-based input system (built on Oracle APEX, don’t ask!), we had to be able to easily handle changes in the schema. Presto! Just don’t use a schema!

So, back to JavaScript (which is, after all, the point of this post)…

Some time ago, not long after that Terrorism application was built, people started to contemplate something outrageous: that JavaScript could (and should) be taken seriously.

We had Steve Yegge talking about the “NBL” in February, 2007: http://steve-yegge.blogspot.com/2007/02/next-big-language.html

Who knew he was talking about JavaScript at the time? C’mon, be honest!

We had JavaScript: The Good Parts by Douglas Crockford (© 2008): http://www.amazon.com/JavaScript-Good-Parts-Douglas-Crockford/dp/0596517742

(see also this Google Tech Talk: http://www.youtube.com/watch?v=hQVTIJBZook)

Now, we even have the (shock, horror) idea that MongoDB might begin to be taken seriously: http://www.theregister.co.uk/2012/06/11/mongo_db/

Other developments worth mentioning: CommonJS promises a JavaScript standard library[http://www.commonjs.org/], Rhino [https://developer.mozilla.org/en-US/docs/Rhino], which has been around for a while, provides interesting possibilities for Java integration, and, of course, Node.js [http://nodejs.org/], which is built on top of Google’s blazingly fast V8 JS engine, is the cat’s pajamas (according to many: http://notinventedhe.re/on/2011-7-26) for programming network services.

See the benchmarks on V8 JS here: http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=all&lang2=v8

So, what does it really take to put together a full-stack of piping hot JavaScript pancakes?

Well, first of all, to be fair, I’m slightly misusing the expression “full-stack.” Full-stack can mean Model (ORM), View (templates), and Controller, and Rails qualifies as “full-stack” by some definitions. I’m using a broader interpretation to mean not just the server-side framework, but the database interface language (where SQL served in the past), and, of course, client-side code (where JavaScript is the de facto standard).

So, we’re looking for the full banana. And, when I ask the question, “What is the state of full-stack JavaScript development today?” (to my friend, Google), what I get back, is this (more than two years old): http://jimbojw.com/fullstack/ which gives a nice overview of the issue.

The central idea is that it is now possible to use HTML, CSS, and JavaScript to build entire web applications, including interacting with the datastore.

OK. We get it. What about specifics?

A little more Googling, leads me, as with most questions about programming, to stackoverflow...

http://stackoverflow.com/questions/4180682/are-there-any-full-stack-server-side-javascript-frameworks-available

That’s very helpful, but it’s interesting to note that that post is from almost two years ago.

To be frank, I wasn’t blown away by the response I got. There didn’t seem to be a “clear winner” in the race to become the default solution. The playing field seems a few players short of a full squad.

Nonetheless, a few names did keep cropping up.

I shall endeavor to list the major players here (please let me know in the comments if there are any other things I should mention).

Derby: http://derbyjs.com/

“Derby is built on top of popular libraries, including Node.js, Express, Socket.IO, Browserify, Stylus, LESS,UglifyJS, MongoDB, and soon other popular databases and datastores. These libraries can also be used directly. The data synchronization layer, Racer, can be used separately. Other client libraries, such as jQuery, and other Node.js modules from npm work just as well along with Derby.”

Derby’s docs also includes a handy section called “Why Not Use Rails and Backbone?” that supports the central thesis of this post.

Tower.js: http://towerjs.org/

“Default Development Stack

• MongoDB (database)
• Redis (background jobs)
• CoffeeScript
• Stylus
• Jasmine (tests)
• jQuery“

Ringo (Helma): http://ringojs.org/ http://www.helma.org/

I’m struggling a bit to figure out exactly how these projects are related to one another (Ringo appears to be a newer implementation of Helma, but I’m not quite sure if it’s meant to supercede it). In any case, Ringo and Helma seem to be the big players based on Rhino (therefore Java) and use JDBC for database connectivity, as well as Jetty.

So, my mission, should I decide to accept it, is to attempt to evaluate this stuff over the next few weeks and post anything interesting that I find. In particular, which, if any, of these solutions seems Ready for Prime Time.

If I can bring myself to do it, I may re-code the above referenced Terrorism database application using one of these stacks. Hopefully, it will be more fun than the first time!