One of my most productive days was throwing away 1000 lines of code.
— Ken Thompson

Tuesday, 14 August 2012

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.

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.

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...

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 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.

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!

@Anonymous (if that's your real name, haha) - I agree that it's a couple of years away. I concluded (for myself) that it was time to take a look. I don't expect to see it in production in the near term, but, inevitably, that day will come. I don't have any great love of JavaScript, but there are compelling reasons why this will come to pass, so I, for one, am trying to get used to it.