Node.js and the new web front-end

Front-end engineers have a rather long and complicated history in software engineering. For the longest time, that stuff you sent to the browser was “easy enough” that anyone could do it and there was no real need for specialization. Many claimed that so-called web developers were nothing more than graphic designers using a different medium. The thought that one day you would be able to specialize in web technologies like HTML, CSS, and JavaScript was laughable at best – the UI was, after all, something anyone could just hack together and have work.

JavaScript was the technology that really started to change the perception of web developers, changing them into front-end engineers. This quirky little toy language that many software engineers turned their noses up at became the driving force of the Internet. CSS and HTML then came along for the ride as more browsers were introduced, creating cross-browser incompatibilities that very clearly defined the need for front-end engineers. Today, front-end specialists are one of the most sought after candidates in the world.

The two UI layers

Even after the Ajax boom, the front-end engineer was seen as primarily working with technologies inside of a browser window. HTML, CSS, and JavaScript were the main priorities and we would only touch the back-end (web server) in order to ensure it was properly outputting the front-end. In a sense, there were two UI layers: the one in the browser itself and the one on the server that generated the payload for the browser. We had very little control over the back-end UI layer and were often beholden to back-end engineers’ opinions on how frameworks should be put together – a world view that rarely took into consideration the needs of the front-end.

In this web application architecture, the UI layer on the browser was the sole domain of front-end engineers. The back-end UI layer was where front-end and back-end engineers met, and then the rest of the server architecture was where the guts of the application lived. That’s where you’d find data processing, caching, authentication, and all other pieces of functionality that were critical to the application. In a sense, the back-end UI layer (often in the form of templates) was a thin layer inside of the application server that only served a front-end as incidental to the business logic it was performing.

So the front-end was the browser and everything else was the back-end despite the common meeting ground on the back-end UI layer. That’s pretty much how it was until very recently.

Enter Node.js

When Node.js was first released, it ignited a level of enthusiasm amongst front-end engineers the likes of which hadn’t been seen since the term “Ajax” was first coined. The idea of writing JavaScript on the server – that place where we go only when forced – was incredibly freeing. No longer would we be forced to muddle through PHP, Ruby, Java, Scala, or any other language in addition to what we were doing on the front-end. If the server could be written in JavaScript, then our complete language knowledge was limited to HTML, CSS, and JavaScript to deliver a complete web application. That promise was, and is, very exciting.

I was never a fan of PHP, but had to use it for my job at Yahoo. I bemoaned the horrible time we had debugging and all of the stupid language quirks that made it easier to shoot yourself in the foot than it should be. Coming from six years of Java on the server, I found the switch to PHP jarring. I believed, and still do believe, that statically typed languages are exactly what you want in the guts of your business logic. As much as I love JavaScript, there are just some things I don’t want written in JavaScript – my shopping cart, for example.

To me, Node.js was never about replacing everything on the server with JavaScript. The fact that you can do such a thing is amazing and empowering, but that doesn’t make it the right choice in every situation. No, to me, I had a very different use in mind: liberating the back-end UI layer from the rest of the back-end.

With a lot of companies moving towards service-oriented architectures and RESTful interfaces, it now becomes feasible to split the back-end UI layer out into its own server. If all of an application’s key business logic is encapsulated in REST calls, then all you really need is the ability to make REST calls to build that application. Do back-end engineers care about how users travel from page to page? Do they care whether or not navigation is done using Ajax or with full page refreshes? Do they care whether you’re using jQuery or YUI? Generally, not at all. What they do care about is that data is stored, retrieved, and manipulated in a safe, consistent way.

And this is where Node.js allows front-end engineers a lot of power. The back-end engineers can write their REST services in whatever language they want. We, as front-end engineers, can use Node.js to create the back-end UI layer using pure JavaScript. We can get the actual functionality by making REST calls. The front-end and back-end now have a perfect split of concerns amongst the engineers who are working on those parts. The front-end has expanded back onto the server where the Node.js UI layer now exists, and the rest of the stack remains the realm of back-end engineers.

No! Scary!

This encroachment of the front-end into what was traditionally the back-end is scary for back-end engineers, many of whom might still harbor resentment against JavaScript as a “toy” language. In my experience, it is exactly this that causes the organizational disagreement related to the adoption (or not) of Node.js. The back-end UI layer is disputed land between the front-end and back-end engineers. I can see no reason for this occurring other than it’s the way things always have been. Once you get onto the server, that is the back-end engineer’s responsibility. It’s a turf war plain and simple.

Yet it doesn’t have to be that way. Separating the back-end UI layer out from the back-end business logic just makes sense in a larger web architecture. Why should the front-end engineers care what server-side language is necessary to perform business-critical functions? Why should that decision leak into the back-end UI layer? The needs of the front-end are fundamentally different than the needs of the back-end. If you believe in architectural concepts such as the single responsibility principle, separation of concerns, and modularity, then it seems almost silly that we didn’t have this separation before

Except that before, Node.js didn’t exist. There wasn’t a good option for front-end engineers to build the back-end UI layer on their own. If you were building the back-end in PHP, then why not also use PHP templating to build your UI? If you were using Java on the back-end, then why not use JSP? There was no better choice and front-end developers begrudgingly went along with whatever they had to use because there were no real alternatives. Now there is.

Conclusion

I love Node.js, I love the possibilities that it opens up. I definitely don’t believe that an entire back-end should be written in Node.js just because it can. I do, however, strongly believe that Node.js gives front-end engineers the ability to wholly control the UI layer (front-end and back-end), which is something that allows us to do our jobs more effectively. We know best how to output a quality front-end experience and care very little about how the back-end goes about processing its data. Tell us how to get the data we need and how to tell the business logic what to do with the data, and we are able to craft beautiful, performant, accessible interfaces that customers will love.

Using Node.js for the back-end UI layer also frees up the back-end engineers from worrying about a whole host of problems in which they have no concerns or vested interest. We can get to a web application development panacea: where front-end and back-end only speak to each other in data, allowing rapid iteration of both without affecting the other so long as the RESTful interfaces remain intact. Jump on in, the water’s fine.

Comments

  1. Bill Scott

    Bingo! You nailed it. This is exactly what is happening at PayPal. When we named our Node project Kraken, it was partly because I knew that releasing nodejs on the organization was much like releasing a monster. It would be a forcing function to create really blended teams.

    If you think about it the delineation between "backend UI layer" and "fronten client UI code" is an artifact of the web. The HTTP request/response created an artificial division in our web apps. And the technology stack also created the same artificial divide. With NodeJS and I believe with JS Templating this really goes away.

    Imagine if a native app team split itself into the NSWindow team and those that do controller/data. Would make no sense.

    You have to ask yourself, what is the app? It is the experience. That is what experience engineers should be doing.

  2. akoskm

    Great idea. After putting together my first Node.js application (proof of concept, not yet in production) I see how Node.js (express more precisely) simplifies front-end engineers' life, for example when it comes to serving your static assets (in dropwizard - what we use currently in production - you need a complete plugin to do that, while in express it's just a one-liner)

    I totally agree regarding the business logic, there are things that shouldn't be in JavaScript, but the concept you introduced will basically double the number http/s request required to complete a business operation, therefore creating an overhead. Where this overhead will pay off?

  3. Justin Lowery

    Nice post. I would have touched on a few more things that I believe are additional arguments to the "why Node.js" question. They would be the following:

    - code reuse for the sharing of logic, data validation, et cetera
    - data formatting for AJAX requests
    - static file management/deployment (CSS, JS … )
    - caching
    - URI design

    But, I think this post is great with or without the above additions. Thanks for writing it! It's good to have more heavyweights like yourself champing this new architecture. It helps when nobodies like me try to argue the same point :)

    I'd love to know if you were ever successful in your Node.js persuasion we talked about a while ago.

  4. Justin Lowery

    @akoskm: " … but the concept you introduced will basically double the number http/s request required to complete a business operation, therefore creating an overhead. Where this overhead will pay off?"

    One thing to remember is these two servers are either 1) VPSs on the same physical server or 2) two different physical servers on the same rack. This means that the HTTP request you are familiar with — client (a browser) in location A and server in location B, which could be hundreds or thousands of miles away — is not the same as client X (Node) and server Y (Java, Python … ) being a foot from one another at max.

    The reason HTTP requests from browser to server is such a big deal is because we are limited by the speed of light. The further the two points are from one another the slower the response, but when the points are one of the same, or just inches from each other, we are talking about nanoseconds. Think of how fast your HTTP requests on when testing a website when it's installed locally, rather than remotely.

  5. Arindam Chakraborty

    This in reality, has been the need for decades. To those who have not been *egoistic* about what they can do.

    Even with god-like frameworks(like Rails) written on top of a language (Ruby), real world applications is 10x more messy with the HTML.

    Why should a Rails guy bother the 10 different ways the list of users can be shown. All he need bother is to know what are those 10 different ways.

    And why should a Front End engineer bother about the different calling semantics for a full page or an ajax call. Why should he have to play with rails/django/jsp/php ugly statements, for which he has no need, just to make sure he gets a 'div' inside the right parent 'div'

    These are things no-one cared. We all did coz we had to.

    And the best part in this article is that the craze about Node.js stopped at something. Not going on to write a full application in it.

    Perfect Read

  6. Brendan

    This is interesting but, I'm struggling with understanding how node.js sits on the front-end mainly just when I look at the illustration. By any chance did you mean for the illustration to show node.js UI Layer sitting on the server-side?

  7. Nicholas C. Zakas

    @Brendan - no, the diagram is correct. The point I was trying to make is that the front-end now extends back into the Node.js server.

  8. Brent

    Thanks for the post -- I understand Node.js a little bit now. However, I'm still confused about the need for it on smaller projects, where there is only one person doing both the front and the back end. Introducing Node would just seem to add another layer of complexity. To a Rails app, for example. Is Node.js worth the effort, if the squabbles between backend and front-end people don't apply?

  9. Seth Thornberry

    This mostly just sounds like whining about not being able (previously) to write your middle tier in your language of choice. That kind of undermines the real value of node.js. It isn't just some version of mod_js for apache -- it allows some really valuable architecture changes for real-time applications. It also brings along some caveats and requirements that are not ideal for every project. I think you really need to look at what problems you're trying to solve, not just who is trying to solve them.

  10. hadrien

    Nice concepts and arguments, but I still don't see the point... Let me ask you a very naive question : why do bother anymore with another server tier as long as educated JS developers are now quite familiar with "single plage applications" ? I mean, why not assuming that client-site UI layers are grown enough to query REST APIs themselves with out the need for a Node.js proxy ?

  11. Nicholas C. Zakas

    @Seth - the "who" and the "what" are very tightly coupled. I never claimed that Node.js was only good for outputting UIs. The point of the post is for what I do, this is where Node.js provides real value. As for whining about not getting to use a language of choice, there wasn't always a choice. Now there is. I firmly believe people doing the majority of the work on a layer should be allowed discretion as to how they want to deliver that work.

  12. Nicholas C. Zakas

    @Hadrien - you could, arguably, just make REST calls from the browser directly. "Single page applications" are not a panacea and you invariably end up pushing complexity into the client where it is more likely to break. I think a thin UI layer on the server is a nice compromise between the legacy web application architecture and the fully-client-side web application (which, for the record, I do not like).

  13. Bill Vezey

    Thinking into the future, when we are wiggling fingers in smart gloves, and walking through fun rooms of data in smart shoes: this architecture will still hold up. The back end is in fact freed up to write once and use in any application environment. Javascript might not always be the language of choice for a RESTful client and the browser API, but the architecture itself is a fine distillation of the last 15 or 20 years or so of figuring out how to best deliver content to the web. This is an intelligent and accessible, and philosophically pleasant post. Huh. Grist for the mill . . .

  14. Justin Lowery

    @hadrien: "why bother anymore with another server tier as long as educated JS developers are now quite familiar with 'single plage applications'?"

    Simple, because the browser is a fragile application platform. If you are building a toy/demo app, a to-do app or anything that is both narrow and shallow in structure, client-sided apps are fine. BUT, if you are building a wide and deep application for heavy interaction, a hybrid client-server app is optimal.

    Twitter is a great example of why we can't just rely on client-side only apps for real work: "Improving performance on twitter.com".

  15. danp

    Perfect encapsulation of what it means to care about your frontend. Node is a beautiful paradigm for modelling ideas that extend beyond just clicking on buttons, especially where (as you so clearly put) we don't have headspace for caring about what is going on behind the api calls. It's useful certainly to know about the architecture, but for day to day.. it just doesn't factor in.

    The one thing that I guess is important to think about is that as this frontend approach encroaches on traditional server land, that we shouldn't be reinventing anything unless we absolutely have to, something that sometimes seems to get lost in this gold rush. As a primarily frontend dev, it's fascinating and inspiring suddenly being able to look at this wealth of knowledge and see how it fits in, but this is something we need to do with a bit of an eye to the past, to avoid making the mistakes that perhaps have been made before. I wish we had more influence from that world.

  16. Justin Lowery

    @danp: "The one thing that I guess is important to think about is that as this frontend approach encroaches on traditional server land, that we shouldn’t be reinventing anything unless we absolutely have to, something that sometimes seems to get lost in this gold rush."

    The thing is, you're not reinventing anything. The server-sided templating, data validation, static file deployment, routing, JSON request handling, caching … it all has to be done by something, right? It's all about now having the choice of what does that something, just like what Nicholas said:

    " … there wasn’t always a choice. Now there is. I firmly believe people doing the majority of the work on a layer should be allowed discretion as to how they want to deliver that work."

    I couldn't say it any better!

  17. Adam Conrad

    What do you think of AngularJs for this UI layer abstraction? Wouldn't that be the same thing as using node without the need for an additional server?

  18. Eelke Boezeman

    I agree, but I would go a step further.

    Because both the UI runs on both server and client in the same language, they can start to become more of unity that abstracts away from the network stack in between them.

    Look at Airbnb rendr for example, it allows you to reuse your backbone models, views, templates and routes on the server, so you have to write code only once.

    We do this at peerby.com too (before Rendr was open-sourced, we developed our own similar Backbone plugin). It's not an easy problem to solve, but if executed well, greatly reduces the amount of time it takes to build a page.

  19. John Jelinek

    Can you please be more concrete with the difference between Front-End and Back-End UI layers? Do you mean the difference between static assets and dynamic content that is fed to templates? What are you placing in the new front-end UI layer and what goes in the node.js layer?

  20. heme

    You say that you don't like "fully-client-side web application", but I'm curious where you draw the line and go back to the server? What is the right mix of UI code running in the browser vs. server?

    I'm building a backbone app that is larger than anything else I've ever built on the front-end. It has multiple routes, going to XDomain for data and templates, uses requireJS/AMD, writing tests, etc. Currently everything is going very well.

    I've seen you make an argument to not render templates in the browser, but are there other general guidelines you've formed. Something like a specific feature or architectural style that indicates the code in the browser is doing too much?

    Thanks for your post and your insight!

  21. Allan Ebdrup

    On our project we are two teams of five and everyone is in principle full stack. And Everything is full stack.
    I think there lies a danger in dplitting concerns so ridgidly. We WANT people doing backend to worry about the client, and know it in detail, or you will be missing out on great solutions.

    I can see how this frontend backend divide can happen at large organizations especially. I don't like it. But then again I don't like working at big organizations for a whole host of reasons

  22. Max

    What if you are in a hosted environment and you cannot guarantee that the two servers are less than a foot apart? Wouldn't the overhead of another HTTP request be too great?

  23. Adrian Mouat

    @Brendan, ncz: I think the confusion is that by "front-end" you mean "presentation layer", including templating, html etc. Brendan is thinking of "front-end" meaning the client's computer.

  24. bl4de

    You've written about exactly what I've got now in my current project in company, where I work :D

    There's a Java/PostgreSQL/ApacheTomcat-based backend. JSP was (and still is, partly) the main UI layer, with awful jQuery spaghetti-code (for DOM manipulation and so on). Slow and very poor responsive.

    Since almost two months me and my colleague are trying to change this architecture. When we joined to the project and we saw UI layer code for the first time (created previously by backend team, 100% Java developers) - we were scared.

    Unfortunately, because the main architecture was fixed before we joined to the project, we can't "insert" Node.js middle-tier. So now, it's a little strange mix of a few separated SPAs, based on Angular.js. :D

    But it is much, much faster then on the beginning, seriously :D

  25. Aksel Gresvig

    Very interesting post Nicholas, thanks for sharing. I've been up and down the stack for years but more and more frontend lately, and your thoughts harmonize with my experiences .

    The last app I've worked on had a very JS-heavy (Backbone-based) client which consumed a REST API. But as both you and @Justin noted above, once the app scales and complexity arises you will almost always end up needing a backend UI layer that does data prep proxy operations between the client and the pure-data backend. It makes the separation so clear, the API exposes pure, semantic RESTful data-only services that the backend UI layer consumes and serves to the client in a UX-optimal fashion. Ahh, I love it.

    NodeJS is perfect for this. It is light, fast, and super-easy to work with. One example is sharing of validation code - you want it on your client for UX purposes, but you want to enforce the same rules on the server side (because clientside validation can be tampered with) for security reasons. With Node, this code can written once, not twice.

    I also support the argument that adding this "middle UI layer" leads to very little performance overhead as it will likely reside on the same physical rack as the API backend, as Justin pointed out.

    Overall, you hit the nail on the head here - very interesting to get this perspective from someone with heavy experience. And good comments

  26. Nicholas C. Zakas

    @Allan - I'm not a fan of having purely full stack engineers. You run not a jack of all trades, master of none situation where everything is just okay. This leads to problems in a growing company.

  27. Nicholas C. Zakas

    @John - front-end UI layer is the delivered HTML, CSS, JavaScript, images, etc. Back-end UI layer is templating, data fetching and cooking, etc.

  28. Nicholas C. Zakas

    @Adam - no, that's very different. With your solution, you are sending everything to the client. The client must then do the heavy lifting if figuring out what it cares about and what to discard. IMHO, that's the back-end's job. The client is inherently fragile, the server is reliable.

  29. Johnny Oshika

    Great post! Thank you.

  30. Sorin

    What do you think about technologies like MeteorJS where the difference between server and client it's just a folder naming convention away?

  31. Alistair Burrowes

    Can you give some tips on how the node front-end layer might work and what tech it would use? This is the first I have heard of this design and I don't know how it might be done.

  32. Clint Nash

    PERFECT! Finally someone said it. Well done Mr. Zakas. A new era is at hand. +1.

  33. Daniele Salvatore Albano

    The idea may be interesting but let me to say that this: it is philosophy and not real life :)

    Developing an architecture of this kind does not consider the fact this introduce another software layer that means bugs, problems and, not for last, overhead.

  34. heme

    @Daniele - Isn't that layer there regardless of where you put it? Don't most of those bugs exist even if the UI is smashed up into the server? Is it not better to have a set of experts in their domain working on UI/UX engineering? It is common to separate a DB Admin role from a Developer role. Why is this different?

    I agree that we haven't seen this architectural model in practice too much yet, but then again truly modern, advanced web applications are a fairly new thing.

  35. Daniele Salvatore Albano

    @heme - as i said, the idea may be interesting, i'm serious, but adding another software layer (node.js/php) doesn't take into account bugs, overhead, maintainability and other stuff.

    You can do the same using - only - node.js or PHP, you don't need both.

    I understand that the point is about a total sepration between front-end and back-end but (obviously i may be wrong) these aren't two different world but two different parts of the same world.

    if you decide to use php ... use php ... there are a lot of template engine (if you don't like to use php itself as template engine) that helps front-end developers, instead if you want to go with node use node ... both them let you to do what you want to do (a good enough separation without going too much over the border line)

    --- i think --- that using node.js just as a pseudo proxy that does data decoration, just as a "template engine", is not pratical and not so much convenient ... just that :)

  36. Nicholas C. Zakas

    @Daniele - the thing is that you are not adding a new layer. This layer already exists in most applications. What you're doing is extracting the layer into a different place (and not even necessarily a different server, in some cases).

    This is also not a philosophical or theoretical architecture. This is being used, in real life, by many companies already. I did not dream it up. :)

  37. joan

    Something that could remind me of ASP, also a server-side technique using the same language as client-side scripts did (at that time), but was invented a long time ago.

  38. colyn

    Great and badly needed post! I do have one issue with it though. You say that this separation has never existed before. N-tier architectures for the web have always dictated a need for a separate thin UI layer, one that doesn't necessitate it be written in the same language as any of the other tiers - that's the whole point. RESTful services is just one way the layers can communicate. This really isn't anything new. Also I've never met a front end developer who didn't know PHP or Python for which this thin UI layer can be written in just as easily. The innovation lies in the fact that now this it can be written JavaScript.

  39. colyn

    I just want to clarify that when I say a thin UI layer within an n-tier architecture isn't anything new, I'm not implying it's widely adopted. Hopefully this post as well as all the great talks by Bill Scott of PayPal will get people to take notice.

  40. Eli Perelman

    Excellent points, and I agree 100%. It's important though to make one delineation. While Nicholas states that you can use Node.js to split the logic between concerns, and that you don't have to place your logic inside of JavaScript, doesn't mean that it is always a bad idea. If your entire development team is more comfortable with JavaScript and Node.js than anything, and if there isn't existing technical debt (e.g. a new project), then it may make sense in that instance to use JavaScript for everything. You could even go as far as still separating the application into 2 different Node.js stacks to keep concerns separate. It just means properly evaluating the needs of the project and using the right tool for the job.

  41. mic

    Hallelujah! Great article. If I could write down what I think - that would be it!

  42. PeterT.

    Great article, but for better understanding an practical tutorial with code including the stack mentioned above (PHP, node) would be a benefit. I dont't have an idea how to implement PHP and node together in a real life example.

  43. David

    Let's go back to the days before the browser, when "Enterprise" applications were routinely written in 4GL's like Powerbuilder or Gupta SQL Windows or VB. Developers were simply developers and they weren't shoved into one hole or another. I know plenty of people who handle both disciplines to this day, although increasingly there is pressure to pigeonhole oneself as either a frontend or backend engineer, and I understand that there is a lot to master for anyone person, and one can only serve so many masters, although you will still find people who can and do take care of frontend and backend.

    You would think that Node.js would appeal to the ideal situation where an entire team can read and contribute to code up and down the stack, sharing and reusing code along the way.

    The problem is, that Node's event driven paradigm is entirely different than the procedural languages they know and are comfortable with. They can and should be concerned about the pitfalls inherent in changing your entire mindset and thinking process, and btw, code that is literally littered with event callbacks can quickly turn into a blackhole of spaghetti. Backend engineers are comfortable at this point with how you scale out PHP or EJB or Pojo java architectures -- with Node.js... not so much yet. I'm sure this will change in time as Node's community and documentation increase, but I'm afraid that your suggestion that making an architecture more complicated, simply because that might be desired by a group of developers who only know javascript, isn't what I'd call a strong argument. Convince backend developers that Node.js is a great platform us both, and you might get somewhere.

  44. Nicholas C. Zakas

    @Peter - PHP isn't a key part of this equation. If you know how to write a server that provides REST services, and you know how to consume those services from Node.js, that's all you need.

  45. Nicholas C. Zakas

    @David - you are severely simplifying my point, and in doing so, missing some important information.

    First and foremost, this architecture is not "complicated", this is a very standard separation of concerns - move business logic into one area and UI logic into another. This separation has been going on in software for a long time, the only difference is that I'm suggesting moving the UI layer out of the same box as the business logic. These both already exist, separating them isn't a big step.

    Second, this article is not about a group of developers who only know JavaScript wanting to use it more, it's about empowering people who previously had no say in the technology selection process for that layer. If those are the people who spent most of their day in that layer, they absolutely should have a choice as to what they spend their day in. Previously, the options were severely limited to the point of there be no different options. Having a different option now is empowering.

  46. Nate

    I would describe myself as a 90% backend expert with about 60% frontend expertise. My frontend skills aren't super-modern with canvas and css3 animations, but I consider myself to be more adept at frontend than some full-time frontend people, and certainly the average backend dev. What follows is a crazy rant against a certain kind of frontend dev - the one who wants to tinker and dabble in backend affairs without ever taking it seriously enough to actually learn what needs to be learned over a period of *years*. Don't worry, we're this an article about backend development, the rant would be longer and even nastier. ;)

    My belief regarding "allowing" frontend devs full control over a UI middleware like nodejs is that many, many frontend experts are simply not qualified to manage a server-side layer like nodejs. Most frontend devs I've met and worked with understand HTML fairly well (though they still insist on placing block-level elements inside inline elements; eg: DIV tag inside a SPAN tag, all wrapped in an A tag). Most are very good with CSS (but for insisting on the use of span { display: block; }). Yet it's rare to find a frontend dev who writes proper JavaScript that looks like real code rather than a copy-paste of some snippet googled from another dev who pieced the snippet together from other googled snippets. Global variable usable is still rampant, as is the lack of understanding of when to use event delegation (binding the same event to 100 nodes instead of delegation via the nearest common ancestor), writing spaghetti code with a few global functions instead of classes, etc.

    Back to the actual point of nodejs: who's going to manage that layer of the stack? I've not met a single frontend dev who knows his way around the command line like a backend dev, or one who understands server-side resource limitations, networking/tcp, etc. If the frontend devs in question for a project can install, configure, secure, test, maintain, scale and benchmark the performance of his server-side UI layer, then I'm open to the idea. Otherwise, don't expect the backend devs to have to worry about scaling out another technically-unnecessary point of failure. When it comes to programming in a server-side language (nodejs qualifies), the developers involved need to understand the OS itself (system-level calls), http protocol, security, working with limited RAM/CPU resources rather than the all-you-can-eat buffet you get in the browser, etc.

    As an aside, the reason php has such a bad reputation is that it's the easiest language to start with, so lots of frontend people who want to try their hand at backend latch onto it - and they're the ones posting to stackoverflow with the scary questions that show they don't have even the most remote idea what they're doing. I believe nodejs, which is genius for certain use cases, may slowly replace php as the lowest common denominator for entry into backend development. A frontend developer who thinks they can start writing backend code just because the JavaScript syntax is familiar is in for a whole world of hurt and will see the cold shoulder from the backend devs who know that you need to know a lot more than variable scoping and json.

  47. Nicholas C. Zakas

    @Nate - I know many front-end engineers who are more than capable. I'm not talking about designers who do some HTML and CSS, I'm talking about full-fledged engineers who understand that the browser is actually an operating system.

    It saddens me when I hear people say things like you just have about front-end engineers because I've been fighting the battle for proper recognition of our skills for my entire career.

  48. Mariano Ravinale

    I think that not only you may integrate business logic through http or rest service with edge.js you could integrate .Net or python backend to work asynchronously with node! thank you for awesome post!

  49. Mariano Ravinale

    here you can find a chart with more information about performance using edge.js vs http https://github.com/tjanczuk...

  50. Oliver Turner

    @Nicholas - This is an inspirational post. Thank you so much.

    I've been thinking of this as exactly the pattern to allow decoupling ongoing work on our legacy systems from parallel front-end updates and it's awesome to hear support for it from someone with your background and expertise. Can't wait to put this into practice.

    @Nate - Your rant is contrived to the point of strawmanship. None of the front-end engineers I have the pleasure to work with are as ignorant of the fundamentals as you blithely assert: they're seasoned professionals with years of experience building scalable architectures and they know more than you seem to about their field of specialisation: I suggest you consult the spec again before mouthing off about wrapping block level elements in anchor tags. It's been a documented part of the HTML5 years.

  51. Troy Wolf

    Mr. Zakas' article is the best argument and best use for Node,js I've read.

    I read most of the comments, and I don't think I saw this mentioned, but a general pattern I've gravitated towards is pushing as much of the processing as I can out to the client. I realize that doesn't sound very user-friendly! Also, like Mr. Zakas, I'm not a fan of building the UI completely with client-side script. For me, the main argument for client-side processing is SCALABILITY. The number of client-cores grows in accordance with your user count increase. Your server's processing power does not---unless you add more servers.

    Suppose I have a JSON payload to serve. Let's suppose it's highly efficient for me to query the data a certain way, but then it must be massaged and formatted. Let's suppose that post-query data processing consumes 50ms on my server. Let's suppose the client could process the raw data instead, and perhaps do it in 100ms, and perhaps even do it asynchronously in the background while other parts of the UI are accessible.

    Now imagine that my web app goes from 100 user to 1 million users. With the client doing the processing, it's like having 1 million cores doing the work--with no increased load or decreased performance per user. It's still only 100ms for each client. If I had done that 50ms of work on my server, it would be 1 million * 50ms of server time!

    In addition, the less UI-specific formatting I can do server-side, the fewer bits on the wire I have to send and the more generically useful the response becomes. That is, data consumers may come along later that are able to use the JSON response in ways I had not anticipated when writing the app.

    Of course we all know that speed and user-perception is everything, and if your page takes more than 250ms or so to be useful, you risk losing customers. So you do have to be concerned about the amount of processing you ask your clients to perform. Most of where I use this pattern is for "live" data components in the page where all the data requests are AJAX in the background. If the response takes a full second to process (as long as I don't interrupt the UI), the client is not unhappy.

    BUT, if you are going to follow someone's patterns, maybe you should follow the guy who write the books on great javascript, teaches at national conferences, and works for the biggest names in the business. Um...that's Mr. Zakas. Not me. :)

  52. Orlando Pozo

    Great article Nicholas!, you nailed it down, this also fosters the ability to reuse code across the UI layers, the same template language can be used to render the UI layer when the page is refreshed or an AJAX request is made, and the MV* API can also be reused.

    Separation of concerns are also done correctly, the front-end layer handles the presentation both in the client-side and the server-side, while the back-end layer focuses on the data access (RESTful API).

    Another thing to mention are offline web applications, where Web SQL DB or IndexedDB APIs are used to store the data in the client-side, this is an interesting use case where Node.js could be used in the back-end to reuse the data access API between the client and the server.

  53. Max

    What if the 2 servers are not close. Would the http overhead kill the performance?

  54. Tomek

    I used that and similar architecture already in my projects, and there is one question I asked:

    how to process file uploads?

    It is front-end concern, but also back-end, since files eventually land on server side?

  55. Alex

    Any case examples on github (or tutorials) that show an app with this type of architecture on the front end? It would help tremendously in getting a full understanding on how it should be done.

  56. PeterT.

    "how to process file uploads?
    It is front-end concern, but also back-end, since files eventually land on server side?"
    Good question Tomek!

  57. Lennie

    I suggest using an other webserver for the static files and routing/loadbalancing the non-static requests to node.js like generating the HTML.

  58. Lennie

    This allows for an optimization I've long wanted to make. To use the same code for handling templates, but without replacing the full backend.

    Using the same template code isn't just to make it simpler for developers, it allows for a more optimized way of delivering the data.

    At the first visit on the site/page/webapp/whatever you call it these days, you send the HTML and data combined in one response. Within the HTML you might have some parts of the template information still intact. So when the client-side code decided it needs a refresh of the data, it can just use AJAX to request it, the server can even look at the template if needed and collect the data and in the browser the client-code places the response in the DOM. All using the same templates and mostly the same codebase.

    I also think async node.js might be a good fit (better than PHP for example) in a service-oriented architectures because you can talk to multiple backend systems at the same time.

Understanding JavaScript Promises E-book Cover

Demystify JavaScript promises with the e-book that explains not just concepts, but also real-world uses of promises.

Download the Free E-book!

The community edition of Understanding JavaScript Promises is a free download that arrives in minutes.