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.

Disclaimer: The criticisms I have of various web application frameworks and platforms are not entirely universal. There are some solutions out there which have vastly improved their approaches. For instance, I’ve borrowed some good parts from Django, Mustache.JS, even (whisper) .NET MVC. The problem is, the bad stuff is so overwhelmingly prevalent in the development community, it chokes out the life of those who really are trying to make it better. Add my voice to that list, and a +1 for all the others who are on that same page.

This will not be a simple quick post. There’s so much I need to write, and it just can’t all fit into a few paragraphs. Please bear with me as I expound on this topic.

Handlebar?

Before I go into further explanation, go check out HandlebarJS Template Engine, my entry into the arena of how to construct web UI. It’s important to note, this is not some “Yet-Another-” all-in-one framework that has sexy themeable widgets, a CMS, or auto-generated admin interfaces. All you will find there is a basic, simple Templating Engine, that takes JSON data as input, processes and compiles text-based templates (that you create and control 100%) into “executables”, and pumps the JSON data into the compiled templates to return a “View”.

There’s much more planned for HandlebarJS, including tools for build-processes, filters, compression, UI optimization, etc. They will come in the form of loosely coupled “plugins” that are compatible with HandlebarJS’ “view” of the world.

HandlebarJS is really quite the opposite of most UI frameworks: it’s a stripped down, deconstructed, anti-framework tool for what is now being called the “middle end” — the stuff that sits between the front-end and the back-end, and negotiates communication, View construction (templating), URL routing, data validation, and other fun things.

What HandlebarJS is not is any kind of RIA framework that attempts to handle the behavioral side (JavaScript) of rich UI. HandlebarJS is only concerned with as quickly and efficiently as possible generating the markup for the UI.

HandlebarJS is intended to be one of several independent components for re-thinking the middle-end UI architecture of web applications. Those other components deserve their own full projects and explanations/write-ups, so you’ll just have to keep an eye out here over the coming weeks for those.

Why should I care?

You may ask yourself at this point: “I have XYZ framework or platform (.NET, Java/Swing, RoR, Django, etc) already, and it does all that stuff for me. Why do I need something else?” Well, that’s a great and valid question, one that deserves a lot more discussion than can ever fit into one blog post. I do have a very specific set of answers to that question, and I will be unveiling it little by little through blog posts (including this one), separate dedicated websites, and even an upcoming planned book.

For now, I’m going to ask you the reader to take my word just a little bit — that’s there strong reasoning behind what I’m trying to do — and let me develop and explain it bit by bit. This post will present some of the high level motivations and discuss specifically HandlebarJS for templating — my goal for now is that you’ll come away more knowledgeable about just an alternative to how your web application currently approaches its Views. I’m not yet trying to convince you that you need an entirely different application architecture — we’ll get there slowly, and it won’t be as scary as it may seem.

What am I trying to solve?

I don’t want to re-write here the entire article and underlying arguments I had against the HAML approach. But, I do encourage you to read it to understand better where I’m coming from.

However, here are the primary thoughts that were motivating factors for creating HandlebarJS:

1. DRY and Portability: For decades, the development community has operated (to varying degrees of authenticity and success) under the principle of not repeating yourself, meaning as much as possible, don’t have two different sets of code that do the same thing. The advent of functions/sub-routines laid the ground work years ago, upon which Object-Oriented programming expounded to give us even better patterns for write once, use many.

   The problem is, the explosion of the web application paradigm has thrown several wrenches into the mix. What fundamentally used to be a single monolithic application, or even a straightforward server-client application, is now a highly complex, distributed, cloud-integrated, web connected, desktop and mobile consumed, rich, thin-and-thick application conglomeration that challenges with orders of magnitude more complexity than our older patterns are capable of handling. It’s almost like we went from n-tier to n^2-tier architecture in a relatively short period of time.

   Moreover, the paradigm of the presentation layer residing in a browser has both extended and limited the evolution of such applications. For several years, even after the invention of Ajax (which revolutionized the page-refresh), web developers have struggled with wanting to do more with Rich Interfaces than the browser (or even internet connection or host computer) was capable of handling. The latest generation of browsers, web technology standards, and computing equipment has finally broken down many of those barriers.

   But just as we finally got to the point where the desktop web browser could be an effective tier in the overall application (not just a thinly veiled client), now we have an intense push to extend all our web application presences into a new frontier of “connected” devices (mobile, smart phone, netbooks, etc), many of which are (in some ways) throw backs to the performance (CPU, connection speed, etc) we could rely on with desktop browsers 5 and 8 years ago.

   Even as mobile Safari pushes to implement the latest and greatest HTML5/CSS3 standards, the reality is that mobile web apps are still handcuffed by limited processor capacity, severely limited browser caches, and unreliable (at best) connectivity.

   So what does all this have to do with DRY and portability?

   I believe we are at an inflection point in the web UI evolution where we must start to think about things differently if we have any hope of keeping up with the exponentially complicating trends of consumer technology. We’re starting to see the fundamental inadequacies (and the pain it brings) of established solutions, in their inability to efficiently handle the rapidly expanding array of consumers of UI presentation.

   These all-in-one frameworks are so attractive to development teams because they fully abstract away all of the messy details of how markup and data are combined to be the delivered UI product. But with that ease-of-use comes a price — lack of flexibility to control and optimize such UI delivery on the fly depending on who is consuming it. A fancy .NET list widget may rock for UI delivered in IE8 on a desktop, but is it up to the task of usable and functional behavior/display in a mobile Opera browser on a screen 1/16 the size of a laptop screen and with 1/10 the memory and CPU? The sad answer is often: absolutely not.

   And no, it’s not enough to just have a different stylesheet for mobile browsers and expect that CSS will save the usability of your app. Mobile (narrow-screen) is an entirely different paradigm in almost all respects to desktop computing. To effectively leverage both platforms simultaneously, AND with the same (unrepeated) code bases, we’re gonna have to get a lot more creative.

   “And now, for something completely different”

   We need an approach to UI that is powerful yet compact, that is portable (meaning it can run in both a server environment and in a variety of browser host environments), and that is flexible enough to be extended/composed/dissected/etc as necessary for the different devices consuming the UI. This isn’t just an incremental improvement on existing systems, it’s an entirely new new kind of approach.

   Of course, if you prefer to write code over and over again, and maintain different application branches for different presentation consumers, then you’ll probably totally disagree with me here — you’d probably rather just stay the course. But I think the future is more re-use and convergence, not less. And I make no apologies for the fact that this is my fundamental bias for everything I’m trying to do here. I do not like at all to Repeat Myself, and I’m going to do everything I can to keep that out of my development practices.

   And I’m just crazy enough to believe in the idealism that it IS possible to achieve this utopia. We’re just gonna have to be brave enough to question everything we’re currently doing. No big deal, right?

2. Do front-end type work in…<gasp>…ONLY front-end technologies: I feel like I’m probably admitting frequently on this blog to not only being strongly opinionated but also a little bit crazy. But that’s ok with me. I can tell you we are not gonna ever solve any real problems by thinking the same way we always do. And I like that I’m a fundamentalist — that I believe less is more.

   I think we could use a lot more of that mindset in the development community. You wouldn’t get in a jet-liner to travel up to the corner store — so why do we feel that these immensely complex frameworks and platforms are the right approach to web applications?

   Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away. — Antoine de Saint-Exupery

   Let’s face it: we all (at one time or another) entertain dreams that our web application is going to need to scale to hundreds of millions of concurrent requests, and our development team is going to balloon to hundreds of distributed development groups, and we must plan for that now by using an enterprise-ready Solution.

   Yet, when you look at the world’s biggest web applications — the Googles, the Yahoos, the Facebooks, and the Twitters of the world — you actually don’t see them using such non-sense to drive their applications. In fact, you often see fundamentalism blatantly plastered across their approach. Why? Because as things scale, what’s not needed is more machinery to manage it, but less to abstract away and play middle-man in the transformation of a request into a response.

   This post is about UI, right?

   Nowhere is this more true than in the UI layer (the middle-end). It’s been recently suggested by Steve Souders of Yahoo and Google fame that actually most of the performance bottle necks (of small and large applications alike) is the UI layer.

   My thesis: the fewer layers of abstraction sit on top of the presentation layer, the more efficient the application will operate (in both low and heavy traffic situations). My corollary: This fundamentalist approach to UI will also lead to better separation of skillsets — a front-end engineer can completely control the UI of an application using only front-end technologies like HTML, JavaScript, and CSS, which they are likely best at.

   This means that when they want to streamline the way their UI is constructed and delivered to address a page-load efficiency issue on their site (like JS/CSS concatenation for instance), they can get directly and immediately to the problem, in the front/middle-end layer (instead of wading through who knows how much back-end cruft that they may or may not be fully capable of navigating or changing). They can also use the technologies they are likely most familiar with (their core skillset) to solve the issues.

   This may seem like a trivial distinction. But I believe it’s a critical and overlooked factor in developer efficiency: staying within one’s core skillset — the sweet spot — as much as possible. And this doesn’t just apply to developers but to technologies as well. I believe there’s a reason that Java largely didn’t survive as a pure front-end technology, and why there hasn’t been a pig push by the community to bring native Ruby processing to the browser. These technologies have their place, but the browser is not that place.

   Whether you like JavaScript or not, it’s quite clear that it is uniquely and best positioned to service all the needs that the UI layer needs. And as you’ll see in a little bit, that means both in browser and on the server. You may not ever (want or need to) re-write your hundreds of thousands of lines of Java, but I hope maybe you’ll consider delegating your UI code to the technology that rules the UI.

   “Both-enders”

   I can just hear some of you right now: you’re the ones who wear both the hat of front-end developer and back-end developer (sometimes at the same time). For you, it’s no big deal at all to “context switch” mentally and use back-end technology (like a JSP taglib) to generate your front-end. In fact, if you’re not a specialist in UI technologies, that may be more comfortable and productive for you to do so.

   I don’t claim that I can convince you otherwise. But let me just submit to you this suggestion: is it possible that you might be more efficient at your UI hat tasks if you didn’t have to concern yourself at all with back-end architecture issues? And vice versa, would your back-end work be more fun and efficient if you didn’t have to constantly worry about markup, box model quirks, or cross-browser JavaScript’ing?

   I think it would. In fact, I’m almost certain of it (at least the UI hat side of things). I’ve worn both hats many times in many different jobs. And I can tell you that unequivocally, I was noticeably more efficient when I had the ability to only wear one hat any given time. What is good for the back-end is often times irrelevant (or bad) for the UI, and vice versa. They are two entirely different disciplines, and it’s time we admit that. Not that you can’t do both, and effectively, but just that you can’t do both at the same time effectively.

3. Stop meddling in my code: Probably my biggest issue with how most frameworks and platforms approach templating is that the templating engine is deeply embedded in, and hopelessly intertwined with, the back-end technology. This invariably leads to far too often bending/breaking the fundamental rule of the MVC pattern (keep the View, Controller and Model separate).

   For instance, consider PHP as a simple example. PHP is a templating engine (if you weren’t already aware). It allows you to take a predominantly HTML file and litter any manner of PHP code logic all throughout it. THIS IS NO BETTER THAN THE SPAGHETTI CODE OF QBASIC FROM 20 YEARS AGO. You actually have to fight hard against these urges (and pretty much every tutorial on the web), and go to great lengths to keep your templates free from such mess.

   And why go to this trouble, you may wonder? Let me give this example:

   <div id="#controls">
      <?php if ($user->IsLoggedIn() && $user->CanPublish()) { ?>
         <a href="publish.html">Publish</a>
      <?php } ?>
   </div>
   

   Seems harmless enough, right? WRONG. This is pure and undefiled evil. You think that just because you put the login session logic and access control logic into your Model (wait, shouldn’t that actually be in the Controller???), and you merely call and use those methods in your template, you’ve achieved separation? WRONG.

   Why do I feel so strongly? Because this pattern is blatantly opening up the doors to putting Controller (and Model) logic right inside the View. First of all, your front-end developer (if that’s not also you Mr. Back-end Engineer) has to know something about your back-end technology (PHP in this case) — and in some cases, they need to know a lot about the back-end to even accomplish a small UI task. This is probably not his or her core skillset (see #2 above), so it’s bound to slow down the efficiency of UI work.

   Also, you have now tied business logic into your View, which is against proper patterns we all learned in Software 101. Consider this scenario (which is so common it’s almost self-obvious): The View developer writes code like the above. Then he leaves the company.

   6 months later, a back-end developer goes through and refactors the Model. He decides for one reason or another that Access Control Permissions are now going to be exposed in the Model (ie, across all the back-end code) as a bitmask property upon which efficient bitwise operators (| &) can be used to figure out permissions. Because they want to keep the back-end code pure and efficient, and don’t want unnecessary methods literring the Model, they remove the $user->CanPublish() method. No problem, right? We just do a grep/code search and find all instances of CanPublish(), and we change that code to instead be ($user->perms & USER_CAN_PUBLISH).

   Ugh. If this doesn’t scream out at you as bad, I don’t know what planet you develop on. It gets worse. 6 months later, the back-end developer quits, and shortly thereafter, the business folks decide that a user must have both USER_CAN_PUBLISH permission and not ($user->restrictions & USER_IS_DISABLED). I bet at this point, the new back-end developer instead gives in and creates a method $user->CanPublishAndEnabled(). Yet more Controller/Model logic hopelessly embedded in the View. And yet another round of View refactorings. I bet your front-end developers (who don’t know much PHP) are getting annoyed by now. Are you seeing the pattern?

   What if instead, there was a pre-agreed-upon Boolean property in the View data (ahem, not Model), called “allow_publish”. The Controller takes care of setting that property (with whatever logic is appropriate at that moment in time) before it invokes the View, and it just passes along that Boolean flag to the View. Then, no matter what kind of back-end refactorings or logic changes occur, the View always look like this:

   <div id="#controls">
      <?php if ($data["allow_publish"]) { ?>
         <a href="publish.html">Publish</a>
      <?php } ?>
   </div>
   

   The difference may seem subtle, but it’s actually enormously important. While I’d definitely call this an improvement, there’s definitely more we can (and should) try to achieve.

   But, my MVC can do that

   The point is not really whether your current environment can do what I’m suggesting. The point is that it probably isn’t, and moreover, it probably feels easier to all involved if it doesn’t. Otherwise, you probably wouldn’t still be reading this article, because you’d be so furiously effciently coding away in your utopian development environment and would have no desire to read my crazy ramblings on the topic!

   I believe we need to encourage Templating Engine solutions to be absolutely minimalist on the amount of “programming” they allow in the Views. The bias should be: allow only the bare minimum of logic as is necessary to select templates and fill them with data. If it’s any harder than that, then it’s logic that belongs back in the Controller (or deeper). Sure, you need basic things like boolean logic for selecting sub-templates, simple looping constructs, and such. But you don’t need the ability to call functions, invoke complicated, deep instantiation heirarchies of mixed Models, run math computations, or any of that non-sense. Remember: Jet-liner to the corner store.

Nodding off

OK, so at this point, you must be exhausted reading this post. I’m exhausted writing it. I promise I’m gonna wrap up quickly. I know it’s a lot of information to take in, but I’m intensely passionate that it needs to be said, and these questions and issues need to be addressed.

This article has thus far been almost entirely me laying out the reasons why I didn’t like most of the templating solutions that are common across the vast majority of web application frameworks and platforms. This is by far not an exhaustive list of the problems, but those 3 points above are a pretty good summary of the types of problems motivating me to find and present another way.

So, if you’re still with me after all that, let me try to briefly explain how I believe HandlebarJS addresses these concerns (and others).

Finally, some Handlebars

HandlebarJS gets its name as the upside down mustache (from MustacheJS templating). The { and } are the things of which we speak.

Here’s what you should know about HandlebarJS:

1. HandlebarJS is entirely written in JavaScript. In fact, it’s entirely written in a manner that allows it to run in either a synchronous or asynchronous environment, either in the browser or on the server (using any of several available server-side JavaScript environments). This allows the exact same code base to run either in browser or on server. Period. Doesn’t get any more DRY than that. You can do templating in either place, or both, as your application requires.

   It’s small and portable and so should be suitable for your templating tasks in a wide variety of JavaScript friendly environments, including even (and especially) mobile.

2. It follows naturally that since the HandlebarJS code is portable and identical both in browser and on server, the templates themselves are also identical. Absolutely. The templating “language” is simple but expressive and capable of any tasks you should rightly tackle with templating. And so you can write your templates once, and run/interpret them in any HandlebarJS capable environment. Again, this is really DRY.
3. HandlebarJS accepts JSON data, and only JSON data, as its input. This means that any platform/environment which can serialize its Model/data down to JSON can send that data to a HandlebarJS instance and get back a processed template View output. Pretty much every language on the planet has JSON serialization/de-serialization support built-in (or at least available easily). JSON data is also the only format of data that is fully and natively portable from server to browser.

   That’s right, some browsers (and clients) don’t natively understand XML even, but they all understand JavaScript, and thus all understand JSON data. Why go to the inefficient trouble of wrapping your data up in some other non-natively-parseable data abstraction? Just use JSON. Trust me, there is no other format better for the task.

4. HandlebarJS is built with simplicity and efficiency in mind. The templating language is as simple as possible to get the job done. It doesn’t give you too much rope to hang yourself. You really can’t embed Controller or Model logic in these Views.

   Also, HandlebarJS compiles templates from their text files into executable JavaScript snippets. This “compilation” can be done on the fly (in either browser or server) if necessary, or it can be done as part of a build-process to increase efficency. HandlebarJS will operate the same functionally regardless of whether it’s dealing with pre-compiled templates or needing to compile them on-demand.

Fin

OK, that’s it, I’m done, I promise. I hope by this point you’re at least convinced it might be a good idea to take a look at HandlebarJS. Even if you are still certain that your existing application architecture is sufficient and won’t need to change, perhaps you might consider exploring if just the View portion can, in whole or in part, be separated off and delegated to a HandlebarJS instance.

If you only want to use HandlebarJS in the browser, you can do so without any architectural/server changes at all. Just drop it into an existing page and start converting your existing templates one-at-a-time. See how easy it is!

And absolutely the only required dependency for HandlebarJS (on the server) is a simple server-side JavaScript environment (many options are available). In fact, keep an eye for the next blog post here, as I will be discussing my brand new released BikechainJS, which is a SSJS wrapper around the V8 JavaScript engine, allowing drop-dead simple JavaScript execution on the server. HandlebarJS and BikechainJS are specifically built to be simple and compatible.

Seriously, stop reading this blog post now and go check out HandlebarJS — isn’t it about time for you to grab your UI by the “Handlebar” and make it do what you want?


]]> http://blog.getify.com/grab-ui-by-the-handlebar/feed/ 4