So, today, I’m going to address the bigger issues around the question I first asked, which started off the conversation,

seems inefficient: emulating a DOM (built up w/ server-side JS)…which then has to serialize into a html string, transfer, then be rebuilt.

though it turns out I had to rephrase it, because I got answers to a different question than what I asked.

rephrase: i get why server-side js is awesome (code reuse, prog enhnc, etc). why a DOM approach instead of shared/reusable templating?

Tale of Two Questions

For the sake of sanity and clarity, let’s break down the conversation into the two fundamental questions, and address them separately:

1. Why is server-side JavaScript helpful for front-end/UI tasks?
2. Why would you use the DOM approach to the UI in server-side JavaScript as opposed to a templating approach?

Server-side UI

There’s some really exciting things you can do with the UI of your web application with JavaScript. This is probably not news to anyone who hasn’t had their head under a rock for the last 5-8 years.

But what role (if any) can server-side JavaScript have in the question of how to use JavaScript in the front-end of your application? Certainly that seems like an oxymoron to be doing JavaScript in your “back-end” primarily for the benefit and use of your “front-end”.

In fact, this is exactly why I’ve been banging the loudest drums I can find to try to define the “middle-end” (that is, what sits in between the front-end and back-end… the middle-end!) of the web application stack.

Specifically, there are a number of UI-related tasks which frequently occur in both places — the browser and the server. For instance: presentation “construction”, data/form validation (or data binding), etc. These tasks, along with others, I have defined as the “middle-end”.

Moreover, concepts such as “progressive enhancement” are heavily related — that is, the idea of progressively enhancing the presentation layer capabilities depending on the capabilities of the client making the request.

Where server-side JavaScript offers some really exciting answers is:

1. Code Reuse: If I can write my data validation code, or my UI construction code, etc, once, in JavaScript, and then reuse that code in both the browser and the server, I’ve significantly improved the maintainability of my application by achieving DRY (don’t repeat yourself).
2. Progressive Enhancement: If I can take advantage of JavaScript’s ability to build out my page’s UI dynamically, I can achieve some really awesome things in the browser. But what about browsers which don’t have JavaScript (enabled)? The typical approach has been to serve a more basic version of the content to such less-capable browsers.

   But what if I could get most of the awesome benefits of JavaScript-powered presentation and not be affected by the browser’s inability to do JavaScript? What if I could run all my awesome JavaScript to build up my page (or even to dynamically alter it) on the server, and just send the HTML result of such operations over to a less-capable browser? To the user of such a browser, they might see things updating slower and a little less gracefully (with full page-refreshes), but they’d get most of the benefits of a dynamically capable page experience without having any JavaScript at all.

   This could be a huge win for progressive-enhancement advocates, because it significantly reduces the amount of work that a site must do to provide some sort of alternate content experience for JavaScript-less browser users.

These are not the only interesting ways that server-side JavaScript could be used to really revolutionize the web application process, but they should be more than enough to answer the question: “Why is server-side JavaScript helpful for front-end/UI tasks?”

To DOM or not to DOM

The meatier question in play here is, if we agree that server-side JavaScript should be used to improve the web application stack, should we choose a DOM-based approach to building out the UI on the server, or should we use a string-templated approach?

I’ll cut to the chase. The short answer is… BOTH!

But the nuances of that assertion are what we’ll now focus on for the rest of this post.

Oranges & Squares

Let’s first define more specifically what we mean by each distinct approach:

1. DOM approach: By this, I mean that you build up your page by explicitly creating each element as a node in a DOM tree. For instance, if I want to add this <ol></ol> ordered-list to my page, I first create an “ol” node, then I create an “li” node, then I append some text to the “li” node (as a “text” node of course), then I add the “li” node to the “ol” node, etc. Once my “ol” node is ready, I then append my “ol” node as a child element of some part of my page, like the current section I’m in.

   Such an approach might look like this (using jQuery):

   var $ol = $("<ol></ol>");
   var $li = $("<li></li>");
   $li.text("Some text");
   $ol.append($li);
   $("body").append($ol);
   

   With this code, our JavaScript executes and programmatically builds up our DOM elements, eventually adding our “ol” element to the end of the “body” element.

2. Template approach: By contrast, here I mean that to build up the “ol” list as described above, you instead create a string like “<ol>”, followed by a “<li>”, then some text, then “</li>”, etc. Once the entire string of markup is done, then you insert that entire string into the page (or part of the page), either as the full HTML or as the .innerHTML of some element.

   Of course, I’m not suggesting that you literally have to manually add strings together with variables and such. That’s why we have template engines that do that for us. So, instead, you have a template like this:

   <ol>
      <li>{some_text}</li>
   </ol>
   

   With this “code”, our templating engine grabs the {some_text} part and replaces it with the value of that variable, and returns us the full constructed string, so we don’t have to mess with all the string operation details.

Zoom In

So, let’s examine the differences between these approaches.

The first most obvious difference is what the “code” looks like that generates something visible in our presentation layer. In the DOM approach, large chunks (if not all) of your presentation layer is written in JavaScript code, usually tucked in with all the other front-end JavaScript. In the templating approach, almost all of your presentation layer is in HTML markup (as a string), usually in separate template files.

The result of building your UI in the DOM approach is an actual DOM tree (a physical nested object heirarchy in memory). The result of building your UI in the template approach is just a string of HTML markup.

Let’s be clear about something: a DOM is required to render something the user can see in the browser. So, the string of HTML markup that you get from the templating approach must of course eventually get parsed into a DOM tree.

That presents an obvious question: if a DOM is eventually required to actually show the presentation layer, isn’t it more efficient to just start out with (and stay in) the DOM tree, rather than going with string manipulation as a first stage of the process?

This is a fine and fair question. I hope I can quickly distill a few thoughts to suggest why I’m not so sure that the obvious is entirely correct — there’s more here than meets the eye.

Designers

Firstly, I’d suggest that there’s a pretty strong precedent for building HTML pages in… HTML. Designers, IDEs, and most web developers have learned and in many cases mastered the process of writing HTML markup. To my knowledge, almost none of the web development IDEs and typical processes are centered around an “(DOM)object-oriented” building of pages — in other words, I’ve never personally seen an IDE where when I look at source-view of a page, I’m messing around in a nested tree structure and adding and removing nodes.

Moreover, the very concept of a string of HTML markup actually conceptually representing a hierarchy of parent and child nodes is a very programmer-centric view. It’s like the difference between saying “The Quick Brown Fox” is a sentence phrase versus saying that, as a programmer, that’s actually an array of individual characters. Both are true, but one view is more semantic and the other is more programmatic.

So, stylistically, you can make a strong case (although it is ultimately preference-driven) that building out HTML pages is more natural and well-established as HTML markup as opposed to JavaScript code. From purely a role-separation standpoint, it’s perhaps more natural for UI designers (and the markup/CSS role) to be able to work in simple HTML markup than they will in code (whether that be JavaScript code, or some other back-end language code like PHP, Java, .NET, etc).

Just because we layer on a simple templating engine on top of the HTML markup to represent the concept of dropping in a dynamic data value in a certain location, doesn’t mean we’ve changed the paradigm from working with HTML markup to working with DOM nodes. Of course, some “templating engines” are far more complex, including all kinds of “programming-like” stuff, like conditionals, loops, function calls, arithmetic, boolean logic, etc. The more of that junk you cram into the “templating language” of your choice, the more like programming your presentation layer construction becomes.

As should probably be obvious, my strong preference is at the far simple end of the templating spectrum, where a bare minimum of anything that looks like “programming” is going on inside my HTML markup. I think that’s backed up by lots of precedence in “separation of concerns”, and I believe a lot of people agree. But there are others who prefer to write code to build up their presentation layer. To each his own, on that, I guess.

Down To The Wire

The other major difference, when we factor in such tasks as presentation layer building occurring on the server, is how the stuff that gets sent over the wire is prepared for the trip from the server to the browser.

In either the DOM or template approach, if the browser doesn’t have JavaScript enabled, the entire process of building the presentation layer occurs on the server, and what gets sent over the wire is always and only a string of HTML markup. The exact same page built with the DOM or template approach will end up being exactly identical when it squeezes down to fit through the pipe from server to browser — a string.

If we accept that in that base case, what transfers over the wire must be a string, then the question above of what’s more efficient (DOM or string) gets flipped. If the in-memory representation of the DOM (on the server) must first be down-converted to a string to be sent over the wire, this will tend to be less efficient than if the presentation layer is already (and only) just a string, ready to send.

Now, what about the case where JavaScript is available on the browser? Assuming then that we’re in the part of a task where we want to off-load our presentation construction to the server, what gets sent over the wire is still going to be pretty much equivalent (though not the same). For the DOM approach, we’re going to send JavaScript, probably in the form of .js files, and in the template approach, we’re going to send HTML templates (strings), probably in the form of template text files. In each case, the files will be normatively cacheable to about the same extent.

Run Time

Both approaches are going to need JavaScript though, not just the DOM approach. The template approach is going to need a “template engine” that can do the same tasks that it did in the on-server scenario — do string operations and combine the string content with dynamic data. The DOM approach is going to need JavaScript logic to create, insert, append, and modify the in-memory DOM tree.

I don’t have conclusive statistics to suggest that either of those two JavaScript code logic paths are going to be substantially faster or more efficient than the other. String operations have, especially in recent JavaScript engines, become exceedingly optimized and fast (compared to really bad string performance in previous generations). Moreover, an intelligent template engine is going to “cache” the compilation of a template (that is, all the string parsing) into repeatedly-executable code, so the costly regular-expression-like parsing of the template string approach is going to be drastically reduced, considering the whole life time of the page view.

But let’s examine what happens at the moment when the presentation layer is about to cross the bridge and actually be added to the live DOM of the page. In other words, let’s compare whether it’s more efficient to inject a single ready string of markup via .innerHTML or to append a sub-tree of nodes to the main DOM tree. Fortunately, a jsPerf test exists to help answer this question: DOM vs. innerHTML.

I ran this test a few times in a few different browsers, and got conflicting results. In Webkit (Chrome/Safari), I got that the DOM insert was quicker (30-50% so) than the .innerHTML insert. But in FF (and to some extent, IE), I got the opposite. Opera was 40% faster at the .innerHTML than at the DOM insert. So, those results are mixed to say the least. I do however think it’s fair to say that as we would go back in time to older generations of browsers, the .innerHTML insert would tend to be a little faster, since most of the attention and focus in recent optimizations of the DOM has been in the DOM append operations. This is a conjecture at best on my part, but I think it’s not terribly inaccurate.

Ideal vs. Realistic

And let’s look closer at what’s going on in this test. The DOM insertion test case uses a DocumentFragment, basically a temporary non-rendered DOM sub-tree, to append the children nodes to. Why go to this effort? Because it’s common knowledge that the absolute slowest part of anything you can do in JavaScript is the actual DOM manipulation against the live DOM of the page.

The reasons for this are varied, but include even things like how DOM manipulations require updating of internal live nodeList collections, force the rendering engine to do reflow and repaint, etc. So, if we can do all our DOM manipulation in a disconnected sub-tree without such side effects, we’ll drastically reduce the cost of DOM insertion. This is a well known and cited optimization technique that has very tangible effects. If that same jsPerf test were run without the use of DocumentFragment and were just inserting the children directly into the live DOM one at a time, the DOM insertion test case would have been hundreds or thousands of times slower across all browsers.

So, are the DOM approach and template approach tied or inconclusive in terms of run-time performance? Perhaps. But I’d say maybe not. The test above represents the absolute best-case optimization, where you have everything you need for the DOM ready in a fragment, and can do it in one insert. In the real world complexity, you may have cases where you need to do 2, 3 or even 10 inserts all around a page. Because the overhead of the live DOM insert is, in general, much higher, the more of them you do, the quicker that negative performance will add up, and will be slower than the .innerHTML inserts.

DOM > string

There are a few cases where some valid arguments can be made that modifying the DOM dynamically is easier or better than dealing with HTML strings.

For one, whenever we’re dealing with event handlers (which get bound directly to DOM nodes), if you start re-assigning the innerHTML of nodes (or the entire page), you’re likely to screw up your event handlers. This is a common and costly mistake. It can of course be mitigated by the established best practices of using event bubbling/delegation, where you have event handlers bound only to top level DOM elements (like the body, for instance), which listen for bubbled-up events from any child elements — when you do it this way, you can freely re-create your elements using either DOM manipulation or innerHTML, and not mess up the event handling.

However, let’s keep in context what this post was about. If we’re talking about doing DOM building of a page on the server, we don’t have browser event handlers in place, so this problem is moot.

Another argument for the DOM approach is the ability to use CSS Selector Engine searching to find elements in the DOM tree. There’s no doubt that Selector Engines are extremely powerful, and using them to traverse through a DOM is equally so. But, when dealing with server-side DOM building, it’s less likely that you’re going to be layering on modifications to your DOM where you need to search the entire DOM repeatedly. For instance, you may be using the DOM approach, and you may “attach” a widget to the server DOM representation, where it creates a new set of DOM nodes to represent itself. But it probably won’t need significant CSS Selector Engine functionality to parse through the entire DOM when doing so — it’ll probably just operate locally in one area of the DOM.

And even if you did need to be able to push in different content into different places of your “page” (attaching different widgets), the regular expression’s power over string searching should be equally capable for most tasks. Your template engine can use a layered approach, where you have sub-template place holders for each widget, and you can tell the template-engine to build out each sub-template separately.

In short, there are cases where we may be more used to tasks (which we normally do in the browser) by using the DOM approach. But there’s not much if anything that can only be done with DOM and is impossible or impractical with string templating. It may take a slightly different mental shift to do so, but I believe templating can be every bit as useful (and perhaps even more so) as the DOM approach.

Oranges AND Squares

Let me wrap up this post with some final thoughts.

Firstly, as you’ve seen, there’s some awesome benefits to using server-side JavaScript to build your presentation layer UI. But more importantly, there’s more than one way to use server-side JavaScript to build it. You can use the DOM, you can use string templating, and you can do both in the same page as you see fit.

I’d just encourage you to realize that the DOM is merely a concept that the browser forced upon UI developers — it’s not actually the most natural way we deal with HTML for the presentation layer. The DOM API in the browser has some really ugly and non-performant warts, and yet some people are going to great efforts to emulate the DOM on the server. I wonder why we’re trying to shoe-horn the DOM into the server to accomplish our tasks, rather than using a string-templating approach that can work pretty naturally and capably in both places without any extra emulation layer?

But even if you’re unconvinced that the DOM is sort of an abnormal approach for the server-side presentation layer building, at least accept that both the DOM and templating approaches will serve you well. Pick which one (or both) is best for each task, and for each part of your development team.

Don’t just assume that because YUI or jQuery are DOM-centric, that this is the only way to achieve server-side JavaScript presentation layer logic. A good, intelligent templating engine will give you all the same tools, and may just be a more natural and efficient fit in the long run.

Overall, the reaction in discussions over beer, feedback/ratings, and tweets has been pretty positive. Even for those who seem to strongly disagree with my thoughts on this topic, I’m pleased that people are talking about it, which means they’re thinking about it, which means I accomplished my real goal: get people to start asking the right questions.

One of the most fascinating things to me was that immediately after I gave my talk, Doug Crockford’s talk on server-side JavaScript in some respects presented a very different view on things than my approach. So, back-to-back, two talks focused heavily on server-side JavaScript, and yet had a very different take on a key issue: synchronous vs. asynchronous.

After a few twitter conversations on the distinct differences between those two messages, I felt like it would be a good idea for me to write up a quick post to clearly state what I think about the sync/async debate, as I’m not sure it’s been well understood thus far.

Crockford is right

That’s correct, you did just read that. I think Doug is absolutely correct in his assertion that non-blocking I/O and asynchronous evented architecture are by far superior to synchronous, blocking I/O. There’s no question that JavaScript shines as an asynchronous language (despite the pains of us figuring out the right way to approach patterns like Promises), and so it’s a completely natural and right direction for Node.js to be taking server-side JavaScript into the asynchronous paradigm.

If I wasn’t clear enough, let me say it this way: async is better than sync.

Synchronous Middle-End?

So wait, if I agree that the async Node.js approach is the best way, why do all my talks deal with synchronous JavaScript on the server via BikechainJS?

What you really need to understand is that just because you run code synchronously doesn’t mean that such code will only run in a synchronous environment. If you write the code correctly, which I’m trying to do, then synchronous vs. asynchronous execution concerns become rather moot. More on that later below.

Again, let me be clear: BikechainJS is not intended to replace or compete with Node.js.

BikechainJS and my synchronous per-request POC code/demos for the middle-end are merely side shows to the main attraction: the importance of middle-end architecture in the web stack.

Hear me on this: you should be architecting the middle-end into your web applications regardless of whether you use JavaScript on the server or not, and regardless of if you want/need to do things synchronously or asynchronously.

The back story

So now, let me explain why I still am showing middle-end code demos using synchronous approaches.

Considering the variety of web application stacks I’ve worked in over the last several years, these architectures have ranged from Java to Grails to .NET to Python to PHP. The code bases have spanned from decent to horrible. Web performance optimization is always a tuning after-thought rather than a key business-driver feature. And the applications have all been built from the back-end up rather than the front-end down.

In all cases (and indeed for most of my 10 year web dev career thus far), some things have been true across the board:

1. I’m a front-end/JavaScript person, and I prefer not to have to dig deep into the bowels of back-end platforms to accomplish my front-end tasks.
2. Universally, when I attempt to re-factor the front-end for web performance optimization, I run into the hassles of not having adequate control over the middle-end pieces (buried deep in the platform/framework guts), and moreover, I often have to deal unnecessarily directly with how the back-end works just to make changes to the front-end.
3. And most importantly, they have all been 100% in the synchronous, per-request paradigm of the web stack. They all used synchronous, single-threaded (process-oriented) web servers like Apache or IIS.

That reality may not be your reality where you work. And if not, great. But having had a dozen jobs so far and seeing the same patterns repeated consistently, I’m willing to believe it’s more the norm than the exception that synchronous per-request is the overwhelmingly common paradigm, and that no matter how hard platforms/frameworks try to keep front-end and back-end separate, they all fail to do so well, when the rubber meets the road.

So, mentally walk in my shoes for a moment, in the types of jobs and environments I’ve been in for the majority of my career. The web application code bases are well established, and for the most part working ok. The boss(es), and 3-8 other devs on the team, are all pretty familiar with that paradigm. The IT support staff are all very familiar with the quirks and behaviors of that stack, and are in some cases quite experience/certified in how to manage it and ensure production up-time.

More than anything, stability and status-quo rule the pack.

The plot thickens

For my last several jobs over the last 2+ years (aka, long before Node.js came around), I’ve been trying to find a pragmatic way to introduce server-side JavaScript into the architectures of the web application stacks at my jobs. My goal has been to find a realistic way to address the middle-end failings of all these different web application stacks, especially in a repeatable and patterned way, and I feel that server-side JavaScript provides a very compelling answer to many of those questions.

Reality check: It is not particularly easy to introduce asynchronous code into a synchronous environment. It requires some very careful planning and often times some complicated and risky changes to existing architecture. In short: it messes with stability and the status quo.

I’ve tried to pitch how server-side JavaScript can be of benefit, but whenever my boss or team starts to evaluate how to make that happen, major sticking points like that are always the death of the idea. For my jobs, their pragmatic (and defendable) position is that they would not be willing to devote the time to such radical rearchitecture (like replacing Apache with Node.js) and/or re-writes of significant portions (or all) of the code base, just to get JavaScript in the server part of the stack.

The biggest argument for server-side JavaScript at this point is massively scalable performance. But most of the jobs I work at never see enough performance bottlenecks where we could ever eventually prove the speedups in any measureable way.

All in all, I’ve had to face this reality in my jobs: if I want to do server-side JavaScript, I’m going to have to find a way to do it that fits more nicely into existing architecture and doesn’t cause quite so many waves. Otherwise, server-side JavaScript will only ever be something I get to toy around with on fun experiments like chat servers (web sockets) and games, and never see any real production usage.

Swim with the current

Instead of trying to simultaneously fight the battle of changing to asynchronous architecture and to switch to middle-end architecture using server-side JavaScript, I’ve chosen to separate those two battles and focus just on one of them for now.

What do I mean? There’s still an uphill battle to get server-side JavaScript into the stack in my real-world job place, but if it’s ever going to happen, it’s almost certainly going to need to play easily and nicely with the existing synchronous per-request paradigm.

Is it possible to use Node.js in this way? Theoretically, yes. You can run Node.js as a separate server instance, and from your synchronous code (PHP, Java, etc), make a blocking I/O call over to Node.js to ask it do something, and block the process waiting for the response. You can run Node.js like a proxy server in tandem with Apache, etc.

But notice what we’ve done: we’ve taken something whose almost entire value-proposition is performance from asynchronous eventing, and handcuffed it in an awkward and inefficient way to make it fit into our synchronous world.

In that respect, running synchronously against Node.js over an HTTP connection is not really conceptually much different than just running the JavaScript directly in a sub-process. It is however probably going to lose any possible performance benefits when considering the on-server overhead of making such HTTP requests as opposed to direct process execution/communication. Moreover, Node.js is phenomenally powerful and complicated, but restricting it in this way makes it be very much overkill for the simple things we want it to do.

Switch into an easier gear

After pushing about and thinking on these complications for quite awhile, that’s where BikechainJS was born. It’s an incredibly simple, stripped-down, highly-focused, synchronous, single-thread/single-process approach to running server-side JavaScript. It has only the bare minimum necessary to accomplish middle-end tasks, like file I/O, process execution, etc. It has NONE of the bells and whistles that make Node.js so sexy, but it also isn’t hampered by any of them getting in the way of its very specific task: run the middle-end.

BikechainJS is not what you want if you’re planning to write a significant amount (or all) of your server code in JavaScript. BikechainJS cannot do many of the most awesome things that Node.js can do.

But BikechainJS can easily be fired up to execute some simple JavaScript logic for middle-end tasks without creating too much overhead in your existing web stack and code. It has absolutely no dependencies except V8, and it’s just a single executable binary file. It’s footprint is extremely small, and it touches almost nothing that you don’t tell it to, which greatly reduces the risks involved in introducing it into your existing code.

BikechainJS is not designed to replace Node.js, it’s designed to run in all the other places where Node.js is too awkward, risky, or difficult to implement.

Sync vs. Async

It’s very important to note that just because I’m currently executing JavaScript in a synchronous way doesn’t meant the code itself is purely/only synchronous.

Most of the code I’m writing, I’m using Promises as a way to cleanly express logical steps which are reliant on each other, even if one of the steps is not immediate/synchronous. Using Promises, code can easily be written that will either work synchronously or asynchronously with little or no code changes at all.

You see, I obviously don’t want to needlessly tie my code to having to run in a synchronous way. I just want to execute my code synchronously, for now, so that it’s easier to integrate with the rest of the synchronous stack. That’s not so evil, is it?

You can very easily take a lot of this code and drop it into an asynchronous JavaScript environment like Node.js, and without much effort to adjust, it should run just fine. This is important in terms of future-proofing the code to be more useful as paradigms shift. I have the flexibility to run synchronous or asynchronous as the situation dictates. This is a very powerful realization.

Putting it into practice

How I am currently using this approach (and middle-end concepts) for my real-world job is to start to take little tiny pieces of the existing code, such as routing, headers, etc, and little by little, re-write them in JavaScript. In my existing web stack, when I want to hand off the execution context to my JavaScript code, I simply execute the BikechainJS environment and hand it some data and wait for the response.

Since the tasks it’s doing are very small and focused, it takes practically no time/overhead at all to do so (certainly way less than constructing and transmitting an HTTP request, even on-server, to a socket server instance).

Eventually, I hope that all of the middle-end logic in our app will be in BikechainJS driven middle-end JavaScript code. But I have the freedom to make the switch in very small chunks without major refactoring or rearchitecture. I’ve found a more plausible approach that my boss doesn’t get as worried about when I propose.

Bottom-line: I’ve found a way to introduce server-side JavaScript to an environment that otherwise flatly rejected the notion of a major sync-to-async rearchitecture. I believe that some server-side JavaScript is better than none at all.

I secretly hope that this move will be just a “gateway drug”, and that eventually, we can move to a much more powerful and asynchronous approach to our middle-end and back-end, probably using Node.js. Because I’ve written most of my code to be agnostic of such concerns, such a switch down the road shouldn’t be as painful as it otherwise might have been. We’ll already be more than halfway there with server-side JavaScript in the stack, and introducing asynchronous architecture patterns (while challenging) won’t necessarily be impossible to sell to the decision makers.

But silver-bullet or the second-coming of the web? I’m not so sure Node.js can quite claim that status. Here, we’ll investigate the counter-point to Node.js, especially as it relates to practical usage in the middle-end. Raining on the parade may not be fun, but if we’re gonna gulp down the delicious Node.js grape kool-aid, we’re also gonna have to stomach a healthy amount of that ick-tasting Node.js cough syrup (that’s right, I just mixed 3 metaphors in one sentence!). We owe this topic some intellectual honesty and debate.

Brad Pitt in “Interview with a devil”

I want to (re)introduce you to a good friend of mine. He’s exceedingly well known, and I’m sure you’ve met him many times before. He’s not a popular guy by any means — probably more infamous than famous — but he can be very assistive in times when the hype of something new clouds our judgement of the things we already knew well.

Me: Devil’s Advocate (“DA”), welcome to the show. I’m glad you could join us for this discussion today.

DA: Thank you for inviting me over for some tea and a lively discussion. You know how much I enjoy calmly reminding people of reality, and in the process spoiling a lot of their fun.

Me: DA, are you saying you like being the least popular guy at the party? A lot of people think you are a Contrarian… that you just like to disagree for the sake of disagreement, and that you don’t really help the discourse very much. What do you think of that characterization?

DA: Well, that’s true that most people probably think of me that way. But that’s ok, I am secure in my manhood and it doesn’t bother me that much. I’m used to intellectual rejection. I mean, look at how hard I’ve been working to try and wake people up to Apple’s antics with the iPhone 4 antenna, and yet the masses still cling to Jobs’ every word like he’s a prophet or…

Me: Ok, DA. Let’s not get off on that tangent here. That is a fun topic, but we’ve got more important things to deal with today.

DA: Sorry, sometimes I just get carried away. But I do think my methods are helpful in encouraging people to question certain assumptions and make sure that all sides of a topic have been examined thoroughly.

Hello World

Me: That’s good. Let’s jump right in. I know you read my previous post where I gushed over how awesome Node.js is and where I explored how it might fit with the middle-end concepts I’m advocating for.

DA: Of course. I wrote that little editorial sidebar as a preview of our discussion today.

Me: Right. So, tell the readers, what do you think of Node.js?

DA: It’s awesome. Really it is. But it’s awesome for a specific set of tasks and for a specific kind of scenario. We have to be careful to remember that even though it’s very exciting for developers to jump on board and start experimenting with a new implementation like Node.js, that doesn’t mean in any way that it’s going to work for everyone.

Me: Obviously not, no one technology is ever right for everyone. I don’t think anyone is suggesting that. Seems like you’re just chewing on the soggy cheerios.

DA: No, it’s more than that. I’m actually trying to help people realize exactly what Node.js is and is not, so that we can have productive discussions not only about Node.js and its uses, but also about other alternatives for the rest of the crowd.

Me: Don’t you think it’s just too early to be judging what Node.js can and cannot do? I mean, isn’t it possible that it’ll grow to be useful in more parts of the stack as time goes on?

DA: It’s entirely possible and likely that Node.js will continue to grow in popularity, and more and more waves of developers will find innovative uses for it. But I don’t necessarily think that means it will ever win over the minds of conservative, established and slow-to-change development teams — and especially their bosses and IT support staff.

Me: Why not?

DA: It’s purely pragmatism, I feel. I’m considering the majority of the web application universe to be of the sort that is not naturally bleeding-edge (even if the bleeding edge is awesome) and often follows well behind the curve, and sometimes never follows at all. I’m thinking of the millions of PHP shops, and the Java shops, and lord knows the .NET shops… all of them out there, chugging along in their own little world. That world is not likely to be “rocked” (as you called it) by Node.js or even server-side JavaScript.

The payoff for them re-writing most or all of their current code base (whatever language it is) into server-side JavaScript would have to be epic and enormous, almost beyond adequate description in words, to convince them it’s worth all the time, money, and risk such a venture would entail.

Change you can believe in?

Me: OK, fair enough, a lot of them might be resistant to change. But aren’t all new technologies up against that same battle at first? The ones that eventually prevail do so despite the nay-sayers (like you) from the early days.

DA: On the surface, you’re correct. But again, I’m talking about something much deeper and more fundamental than just: will the masses ever accept server-side JavaScript?

In fact, I think that’s really your biggest question to answer as you try and convince people to embrace the middle-end with server-side JavaScript as the driving technology. Yes, the middle-end as a concept doesn’t require JavaScript, but the biggest payoffs in the middle-end come if people will accept server-side JavaScript into the stack. You’ve got a big uphill battle even trying to convince people that a little tiny piece of the stack can be done adequately with server-side JavaScript.

Me: Thank you for reminding me just how challenging this is.

DA: My bigger point is, Node.js at its fullest is much broader than I think most people realize. I think it represents a paradigm shift, not just the introduction of an existing technology into a new environment.

I think I’d liken this concept to trying to convince a company that makes desktop video-editing software that the new age will be their software web/cloud-based and mobile. Noone would argue that the mobile and cloud movements are huge and clearly represent the future. But the desktop application company is probably still likely to adhere to their core competency and continue to serve and rely on the paradigm of desktop application and hardware.

And they may rightly argue that the payoff for being able to take even part of their awesome video-editing functionality and stick it on a tiny screen device with 1/100th the CPU power probably doesn’t justify the efforts to try and get on the bandwagon with “everyone else”.

Me: A paradigm shift? Can you elaborate?

DA: Here’s what I mean: Node.js is not just an execution environment for server-side JavaScript. In theory, you could just run JavaScript on the server in an on-demand way, as needed. And I bet Node.js would be pretty decent at that task.

But by even thinking about Node.js in that light, you’ve drastically missed the point of what it’s trying to do. Node.js is trying to leverage the asynchronous power of JavaScript at a deeper level than on-demand application logic. Node.js is trying to become the network server itself, so that the server-side JavaScript you write for your application can be interpreted in a much more natural and almost native way.

Let’s look at this in light of some more established existing functionality. Consider a PHP web application. Now consider there’s some additional “module” for some task, like for instance doing OpenSSL encryption/decryption. There’s multiple ways your PHP code could accomplish this task. We know there’s command-line utilities (written in C and compiled to binaries) for managing OpenSSL. So, from our PHP, we can call out to those binaries by executing them as sub-processes.

But this isn’t necessarily the most efficient way to do things. It certainly can make code look less graceful and more complicated to maintain (more moving parts). Instead, we’d like it if someone could write a PHP “extension” that brings the capabilities of the OpenSSL engine natively into our PHP code. Coding against a PHP API for OpenSSL feels more natural than executing a binary sub-process, and it’s also likely to be a lot more performant.

Me: That sounds about right.

I can’t speak for the designers of Node.js, but I’d venture that among their various motivations, they wanted to do something similar (but in a much broader sense) for server-side JavaScript in the web stack. They wanted to make coding your entire application in JavaScript on the server as natural and native and built-in feeling as doing any other task in the web server, including listening for requests on port 80, doing file I/O, etc.

You see, the different paradigm that Node.js is bringing to the table is the idea that the web server and the application become almost synonymous. I think more than anything, that is the truly compelling story for Node.js. I’m not saying that Node.js is the first to do this, but I do think that Node.js is the most radical approach in this area that we’ve seen thus far.

Vive la Révolution!

Me: Ok, so that does sound pretty revolutionary. But I missed the part about how this doesn’t fit well with the middle-end.

DA: Well, you certainly are the primary advocate for the middle-end, so I won’t try to speak for you. But, I think you and I have some parallel thoughts in mind at this point, even if you don’t realize it. You have a vested interest (by virtue of your efforts to call attention to the middle-end) in convincing the “world” to adopt middle-end architecture as an intentional and carefully planned layer. The more applications/teams that do so, the more you will “prove” that middle-end architecture needs to be its own discipline and not just an after-thought of existing platforms/frameworks.

I’m trying to suggest that Node.js represents a fundamental shift in how people will think about web servers and applications, not as separate functional units but as conjoined parts of the same whole. A web application no longer has to be thought of as a set of business logic code and pretty HTML that relies on a web server to send it to users. A web application is fully self-contained and capable of doing everything it needs from within itself. And it uses a consistent language (JavaScript) to do everything throughout.

This idea is so radical that I think most web applications and platforms and companies will have a hard time swallowing it, at least any time in the relevant future. Thus, I submit that a “middle-end” that relies on Node.js will be less palatable to the masses than a “middle-end” that is more agnostic and flexible.

Me: Right, I’ve tried to make the point that the middle-end as an architectural pattern doesn’t have to have JavaScript on the server involved. Really, the primary reason for why server-side JavaScript offers an interesting answer to the middle-end is the idea that we can write code once and re-use it in both server and browser. No other language/technology can ubiquitously offer that.

DA: Exactly. You see, Node.js represents a particular narrowed down implementation of the broader middle-end concept into one specific form. That form happens to be increasingly exciting to the bleeding edge of the web development community, but I foresee problems in truly convincing the establishment that both Node.js and the middle-end together will be right for them.

Take the Chrome browser for example. It’s got a huge percentage of market-share among open web developers. Along with Firefox, Chrome is quite obviously becoming a web developer’s browser of choice. But when taken in the overall context of the web, Chrome’s percentage is still pretty low. There’s an established momentum around browsers like IE and Safari, and Chrome is not likely to completely overtake them any time in the foreseeable future.

Node.js is an amazing piece of technology. But it’s almost too amazing for the middle-end. It certainly will be more radical to convince existing applications to embrace the fullness of what Node.js is than it would be to suggest, as you have many times, that a more simple, stripped down approach to server-side JavaScript is possible, and in fact warranted.

Army of none

Me: Why isn’t using Node.js in a more limited fashion (like on-demand or per-request as you suggest) a valid usage of Node.js?

DA: I wouldn’t call it invalid. I’d just say that it’s a lot like driving a tank down to the corner store to buy some drinks. Can it get you there? Sure. Will it get the task done? Yes. Is that an effective mode of transportation? Perhaps not.

Some people like to argue that because Node.js has all this amazing capability built into it, it’d be foolish to not use it for your server-side JavaScript tasks because of all the extra stuff you’d miss out on if you ever decided later you needed it. This is kind of like arguing for taking the tank for the trip down to the corner store because you want to be prepared in case an invading army of aliens attacks. “Look, I’m better prepared to fight off the bad guys in my tank than I am on my little scooter.”

Me: Don’t you think that’s just a little bit of an exaggeration?

DA: Well, maybe a little hyperbole there. But my point remains, Node.js is way overkill for the simple middle-end tasks at hand. If someone is trying to shoehorn using Node.js into doing simple per-request on-demand JavaScript execution (the likes of which you’ve argued for in the middle-end), they are really missing the point of Node.js.

To put it another way: they’re using a sledge hammer to drive in a thumbtack.

Me: Isn’t there something to be said for using a project like Node.js for our tasks, because at least it’s pretty well known and has a lot of active developers and a vibrant support community?

DA: No question, it seems like using Node.js would be the obvious choice for this task. And perhaps a developer might be better able to convince their boss to try Node.js at first than some much less known project like your BikechainJS option.

But in the long run, I think that using the right tools for the job always wins out in terms of efficiency and maintainability over using the more popular or hyped solutions and later on finding it’s not a good fit.

Me: If one of those “established” companies was going to broaden their horizons, isn’t it riskier for them to venture off into the wilderness and choose an unknown project/option as compared to sticking closer to home with something more people know better?

DA: It may appear riskier. And definitely perception is hugely important in this game. But in reality, Node.js is actually asking an existing team/platform to put more of their eggs in the server-side JavaScript basket than what you’ve argued for in the stripped-down middle-end approach.

Like I said earlier, Node.js is a fundamental paradigm shift. This means that companies are going to have to retool a big portion of their web stack. They’re going to have to train IT support staff on a whole new set of technologies in the web stack. They throw out their 5, 10, 15 years of experience supporting and performance tuning traditional synchronous web servers like Apache, and now they have to learn it all again with a radically different asynchronous server-side JavaScript web server. I shouldn’t have to point out what a “shock” that would probably be to most organizations.

And the risk doesn’t stop there. Node.js itself is ever-changing. It’s stabilizing more recently, but it’s been incredibly volatile. I’d say right now it’s like walking over a bed of molten volcano lava that only a few hours ago started cooling and hardening into volcanic rock. How much do you trust that an inch of cooled volcanic rock is enough to protect you (and your 800 lb elephant) from the river of lava just below the surface?

Me: Doesn’t CommonJS offer us hope of stability and compatibility?

DA: Absolutely, it promises that. But it may be literally years before there’s consensus in the server-side JavaScript world on how all these API’s should really look and function. In fact, if the browser API’s have taught us anything, we may never fully have agreement.

Now, certainly the browser irregularities didn’t sideline 10′s of millions of companies from leaping into web applications, but most of them didn’t dare venture into the game until there was at least some sort of reasonable “gap fill” like any of the various JavaScript frameworks, which normalize differences across browsers and provide a stable foundation for companies to build upon.

So it may be awhile before CommonJS and/or some set of server-side JavaScript “frameworks” are able to secure a stable footing. If you look at Node.js right now, it represents a significant super-set of the small amount that CommonJS participants have “agreed” on. So, marrying yourself to Node.js right now is risky because it’s like marrying your web application to only FF and hoping that its rampant popularity will be enough to drive everyone else to commonality.

Fatalism: a cruel mistress

Me: So can we really do anything with server-side JavaScript at this point, given the immaturity and instability across the board?

DA: Of course! I’m not at all suggesting Node.js is bad to use because its unstable. I’m suggesting it has its places where it’s a natural fit (like in prototypes, developer experiments, and other flexibile-to-change dev environments), and then it also has places it’s not a good fit (like established teams with slow-to-change environments).

The same would be true of any server-side JavaScript option at this point, in my opinion. Of course there’s the obligatory “use-at-your-own-risk” label on all such things. But the smaller, more independent, and more custom your server-side JavaScript implementations are, the more likely you are to be able to adjust as the “industry” matures and changes.

At this point, if you were to go out and re-write your entire application in Node.js’s flavor of server-side JavaScript, you could be painting yourself in a corner if what evolves over the next few years is not in line with how Node.js is currently doing things.

My point is that the smaller the footprint of your server-side JavaScript at this point, the more insulated you are from these risks. Whereas Node.js represents a pretty big footprint conceptually, using stripped-down, per-request, on-demand JavaScript solutions represents a much smaller footprint both technologically and conceptually. Companies are more easily able to integrate such things little-by-little, and also strip them out if problems arise. A re-architecture to Node.js and server-side JavaScript would both be more comprehensive and also more difficult to undo.

Parting shots

Me: We’re almost out of time… do you have any final thoughts to share or clarify with the audience regarding Node.js and the middle-end?

DA: I think your idea of using Node.js as a go-between “proxy” for middle-end tasks is an interesting one. I think it represents probably the best possible scenario in which Node.js fits in with your “middle-end”.

But I’ll close by saying this: you must realize that Node.js may in fact be ushering in, at least for those (few) who are inclined and capable of taking up the banner, a new era of web applications. This era will be one defined by a blurring of the lines between front-end, middle-end, and back-end code. It will be a new class of web applications that is built end-to-end in JavaScript. In such a world, the middle-end tasks become the all-end tasks. So, more than anything, I think Node.js may mean there’s no need for a middle-end any more.

However, I think the reality is there will only ever be a select enlightened few who ever get to fully explore that new paradigm. For the overwhelming majority “rest of us”, the “middle-end” will still be a valid and important reality for our web applications, and as such, we should embrace this discussion.

Me: Well said. I have nothing more to add, except a thank you to DA for joining us today. I know you’re a busy guy, so I’ll let you get on to other pressing debates.

I regularly follow the chatter on the interwebs, and I’m amazed and thrilled at just how much gravity Node.js has accumulated in terms of developer excitement and actual project input. In fact, in some ways, the Node.js ecosystem of companion projects is even more awesome than Node.js itself! It’s a fantastic example of how the community was desperate for something (we didn’t even know exactly what) and how well we quickly rallied around it when we finally found it. It’s plainly obvious that server-side JavaScript is an idea whose time has come, and Node.js, in many ways, will take us there.

This post is an attempt to put my little niche spin on what Node.js could mean for someone wanting to tackle re-architecting the middle-end of their web application.

What is Node.js?

In the broadest terms, Node.js is an application server platform. It’s actually a server-side JavaScript execution environment (roughly similar to something like Narwhal) wrapped around the V8 JavaScript engine. But it’s a very special type of environment compared to other options in this space. Node.js is completely asynchronous. This means that everything you do in Node.js, you do in terms of asynchronous-friendly API’s, like network calls, file i/o, etc.

But even more important is that Node.js is specially designed to operate as an independent and fully-functional network server. What do I mean by this? Node.js’ flagship capability, and indeed how most people use it, is its ability to “listen” for incoming requests on a particular network port (like port 80 for web traffic) and service those requests like a web server like Apache or IIS might do. In other words, Node.js at its most optimal is a drop-in replacement for your current web server. And it wraps in a fully capable application server (using JavaScript) automatically. Cool, huh?!

Because Node.js is asynchronous, it doesn’t operate under the covers at all like other web servers do. Instead, it operates in an “evented processing loop” where it is simultaneously and asynchronously listening for incoming connections, firing off processing to handle each connection, and then “listening” for those processing contexts to finish to hand the results back to the requesting connection stream. The result is that in many use-cases, Node.js is able to achieve mind-blowing amounts of parallel processing and throughput compared to more standard web servers like Apache.

Bottom line: Node.js’ core competency is to take a server-side JavaScript application server environment and wrap it cleanly around a super-efficient asynchronous network server. In most respects, this is simply the most efficient server-side JavaScript environment you’re likely to ever find, and it allows JavaScript to compete head-to-head with even optimized, compiled binary alternatives.

Is it for me?

Up until now, every thing I’ve spoken about and written regarding middle-end architecture and server-side JavaScript has been conspicuously silent on the topic of Node.js. There is good reason for that, but I only want to touch briefly on it here, by means of comparison. The next post will dive into this much more thoroughly.

The utter awesomeness that is Node.js comes with a price. For most developers who are hacking and tinkering with new ideas all the time, this price is mere “pocket change” and that’s probably the biggest reason why the Node.js community has grown so quickly and so broad. But there is a “silent majority” lurking out there for whom the Node.js price may not be quite so trivial. What is this price? Infrastructure.

Thus far, my focused efforts have been on finding the lowest possible barrier-of-entry into the server-side JavaScript world. By barrier-of-entry, I mean the least amount of footprint/impact on existing infrastructure/architecture and to existing maintenance and support/IT staff. The current fruits of that labor has been the humble BikechainJS server-side JavaScript project.

I shyed away from presenting my middle-end ideas in the context of Node.js because there are many who cannot necessarily proceed under the guise of replacing their top-level web server (along with all its associated dependencies, modules, configurations, etc) with an entirely new (and fundamentally paradigm-shifting) solution like Node.js. No doubt we’d mostly all agree that it would be exciting and probably even more efficient, but the slow-to-change momentum of existing applications, teams, infrastructure, maintenance, reliability, and IT support staff have a noticeably chilling effect on the hyper-excited server-side JavaScript movement.

It was my goal that something like BikechainJS, with its synchronous, per-request paradigm, could squeeze much more nimbly into existing application infrastructure, even at the cost of the wins from Node.js’ performance.

But Node.js is just so damn awesome!

That’s absolutely true. And I’ve come to believe that the awesomeness of Node.js does not have to be mutually exclusive of the middle-end architectural ideas I’m advocating for, nor does it have sit out of reach from so many existing web applications, dev teams, and web shops.

Node.js can (and perhaps should!) be the magic key to unlocking the full potential of your application’s middle-end.

What if we can have our cake and eat it, too? What if we can find a clean way to plug Node.js into the existing infrastructure of our web applications, and at the same time give it the power to revolutionize our middle-end tasks? We’d get exponentially better performance and revolutionary better code architecture. That idea is just so full of win it’s hard to type without going nuts!

Augment, not replace

My biggest mental sticking point all along with Node.js has been the (im)practicality of asking an existing application to just simply swap out its entire web server tier for Node.js. I explored even the idea of running Node.js in a more limited, synchronous, per-request (CGI-like) context, but quickly found that was like trying to teach a bird to swim.

Then it hit me. The best way Node.js revolutionizes the middle-end of your existing/legacy web application is if you build your middle-end Node.js-based and insert it wholly into the stack in between the browser and your existing server.

In this respect, your middle-end Node.js layer becomes a “proxy” (or “web balancer”) server of sorts, sitting in front of your existing web server. All you have to do is bring up a Node.js VM/server instance (even cloud-based!) and direct all your primary traffic to that instance first. Then, you build out your middle-end architecture, doing templating, URL routing, data validation, and all the other tasks, as necessary, in your Node.js server-side JavaScript, and finally, you hook Node.js up to ferrying requests back over to your existing application server.

In this blind-proxy model, you start off with a dumb pass-thru of all your application’s requests, and then one-by-one you can inject some intermediate middle-end logic using the server-side JavaScript. For instance, as I talked about before, you can start doing data-validation of inbound data fields using your Node.js-driven JavaScript. And then you can move on to evolving your templating into a true middle-end task in your JavaScript. And so on.

Win, win, win

The benefits of this approach are hard to explain by mere words. First and foremost, you will see an insane jump in the request/response performance simply by letting Node.js manage your application’s front line web server handling. But equally important, you gain invaluable flexibility to start converting your thick back-end into a well-crafted middle-end/back-end approach. And you don’t have to change very much of your existing infrastructure at all.

This is what I like to call a “middle-win” scenario! Node.js really rocks the middle-end.