Menu Search
Jump to the content X X
Smashing Conf Barcelona

You know, we use ad-blockers as well. We gotta keep those servers running though. Did you know that we publish useful books and run friendly conferences — crafted for pros like yourself? E.g. our upcoming SmashingConf Barcelona, dedicated to smart front-end techniques and design patterns.

An Introduction To Full Stack JavaScript

Nowadays, with any Web app you build, you have dozens of architectural decisions to make. And you want to make the right ones: You want to use technologies that allow for rapid development, constant iteration, maximal efficiency, speed, robustness and more. You want to be lean and you want to be agile. You want to use technologies that will help you succeed in the short and long term. And those technologies are not always easy to pick out.

In my experience, full-stack JavaScript1 hits all the marks. You’ve probably seen it around; perhaps you’ve considered its usefulness and even debated it with friends. But have you tried it yourself? In this post, I’ll give you an overview of why full-stack JavaScript might be right for you and how it works its magic.

Further Reading on SmashingMag: Link

To give you a quick preview:

full stack javascript6
(Large view7)

I’ll introduce these components piece by piece. But first, a short note on how we got to where we are today.

Why I Use JavaScript Link

I’ve been a Web developer since 1998. Back then, we used Perl8 for most of our server-side development; but even since then, we’ve had JavaScript on the client side. Web server technologies have changed immensely since then: We went through wave after wave of languages and technologies, such as PHP, ASP, JSP, .NET, Ruby, Python, just to name a few. Developers began to realize that using two different languages for the client and server environments complicates things.

In the early era of PHP and ASP, when template engines were just an idea, developers embedded application code in their HTML. Seeing embedded scripts like this was not uncommon:

        if ($login == true){

Or, even worse:

    var users_deleted = [];
        $arr_ids = array(1,2,3,4);
        foreach($arr_ids as $value){

For starters, there were the typical errors and confusing statements between languages, such as for and foreach. Furthermore, writing code like this on the server and on the client to handle the same data structure is uncomfortable even today (unless, of course, you have a development team with engineers dedicated to the front end and engineers for the back end — but even if they can share information, they wouldn’t be able to collaborate on each other’s code):

    $arr = array("apples", "bananas", "oranges", "strawberries"),
    $obj = array();
    $i = 10;
    foreach($arr as $fruit){
        $obj[$fruit] = $i;
        $i += 10;
    echo json_encode(obj);
        success: function(data){
            var x;
            for(x in data){
                alert("fruit:" + x + " points:" + data[x]);

The initial attempts to unify under a single language were to create client components on the server and compile them to JavaScript. This didn’t work as expected, and most of those projects failed (for example, ASP MVC replacing ASP.NET Web forms9, and GWT10 arguably being replaced in the near future by Polymer11). But the idea was great, in essence: a single language on the client and the server, enabling us to reuse components and resources (and this is the keyword: resources).

The answer was simple: Put JavaScript on the server.

JavaScript was actually born server-side12 in Netscape Enterprise Server, but the language simply wasn’t ready at the time. After years of trial and error, Node.js3613 finally emerged, which not only put JavaScript on the server, but also promoted the idea of non-blocking programming14, bringing it from the world of nginx, thanks to the Node creator’s nginx background, and (wisely) keeping it simple, thanks to JavaScript’s event-loop nature.

(In a sentence, non-blocking programming aims to put time-consuming tasks off to the side, usually by specifying what should be done when these tasks are completed, and allowing the processor to handle other requests in the meantime.)

Node.js changed the way we handle I/O access forever. As Web developers, we were used to the following lines when accessing databases (I/O):

var resultset = db.query("SELECT * FROM 'table'");

This line essentially blocks your code, because your program stops running until your database driver has a resultset to return. In the meantime, your platform’s infrastructure provides the means for concurrency, usually using threads and forks.

With Node.js and non-blocking programming, we’re given more control over program flow. Now (even if you still have parallel execution hidden by your database (I/O) driver), you can define what the program should do in the meantime and what it will do when you receive the resultset:

db.query("SELECT * FROM 'table'", function(resultset){

With this snippet, we’ve defined two program flows: The first handles our actions just after sending the database query, while the second handles our actions just after we receive our resultSet using a simple callback. This is an elegant and powerful way to manage concurrency. As they say, “Everything runs in parallel — except your code.” Thus, your code will be easy to write, read, understand and maintain, all without your losing control over program flow.

These ideas weren’t new at the time — so, why did they become so popular with Node.js? Simple: Non-blocking programming can be achieved in several ways. Perhaps the easiest is to use callbacks and an event loop15. In most languages, that’s not an easy task: While callbacks are a common feature in some other languages, an event loop is not, and you’ll often find yourself grappling with external libraries (for example, Python with Tornado16).

But in JavaScript, callbacks17 are built into the language, as is the event loop, and almost every programmer who has even dabbled in JavaScript is familiar with them (or at least has used them, even if they don’t quite understand what the event loop is18). Suddenly, every startup on Earth could reuse developers (i.e. resources) on both the client and server side, solving the “Python Guru Needed” job posting problem19.

So, now we have an incredibly fast platform20 (thanks to non-blocking programming), with a programming language that’s incredibly easy to use (thanks to JavaScript). But is it enough? Will it last? I’m sure JavaScript will have an important place in the future. Let me tell you why.

Functional Programming Link

JavaScript was the first programming language to bring the functional paradigm21 to the masses (of course, Lisp came first, but most programmers have never built a production-ready application using it). Lisp and Self, Javascript’s main influences22, are full of innovative ideas that can free our minds to explore new techniques, patterns and paradigms. And they all carry over to JavaScript. Take a look at monads23, Church numbers24 or even (for a more practical example) Underscore25’s collections functions26, which can save you lines and lines of code.

Dynamic Objects and Prototypal Inheritance Link

Object-oriented programming without classes (and without endless hierarchies of classes) allows for fast development — just create objects, add methods and use them. More importantly, it reduces refactoring time during maintenance tasks by enabling the programmer to modify instances of objects, instead of classes. This speed and flexibility pave the way for rapid development.

JavaScript Is the Internet Link

JavaScript was designed for the Internet27. It’s been here since the beginning, and it’s not going away28. All attempts to destroy it have failed; recall, for instance, the downfall of Java Applets29, VBScript’s replacement by Microsoft’s TypeScript30 (which compiles to JavaScript), and Flash’s demise at the hands of the mobile market and HTML5. Replacing JavaScript without breaking millions of Web pages is impossible, so our goal going forward should be to improve it. And no one is better suited for the job than Technical Committee 3931 of ECMA.

Sure, alternatives to JavaScript are born every day, like CoffeeScript32, TypeScript33 and the millions of languages that compile to JavaScript34. These alternatives might be useful for development stages (via source maps35), but they will fail to supplant JavaScript in the long run for two reasons: Their communities will never be bigger, and their best features will be adopted by ECMAScript (i.e. JavaScript). JavaScript is not an assembly language: It’s a high-level programming language with source code that you can understand — so, you should understand it.

End-to-End JavaScript: Node.js And MongoDB Link

We’ve covered the reasons to use JavaScript. Next, we’ll look at JavaScript as a reason to use Node.js and MongoDB.

Node.js Link

Node.js3613 is a platform for building fast and scalable network applications — that’s pretty much what the Node.js website says. But Node.js is more than that: It’s the hottest JavaScript runtime environment around right now, used by a ton of applications and libraries — even browser libraries are now running on Node.js. More importantly, this fast server-side execution allows developers to focus on more complex problems, such as Natural37 for natural language processing38. Even if you don’t plan to write your main server application with Node.js, you can use tools built on top of Node.js to improve your development process; for example, Bower39 for front-end package management, Mocha for unit testing, Grunt40 for automated build tasks and even Brackets41 for full-text code editing.

So, if you’re going to write JavaScript applications for the server or the client, you should become familiar with Node.js, because you will need it daily. Some interesting alternatives42 exist, but none have even 10% of Node.js’ community.

MongoDB Link

MongoDB43 is a NoSQL44 document-based database that uses JavaScript as its query language (but is not written in JavaScript), thus completing our end-to-end JavaScript platform. But that’s not even the main reason to choose this database.

MongoDB is schema-less45, enabling you to persist objects in a flexible way and, thus, adapt quickly to changes in requirements. Plus, it’s highly scalable46 and based on map-reduce47, making it suitable for big data applications. MongoDB is so flexible that it can be used as a schema-less document database, a relational data store (although it lacks48 transactions49, which can only be emulated50) and even as a key-value store for caching responses, like Memcached51 and Redis52.

Server Componentization With Express Link

Server-side componentization is never easy. But with Express53 (and Connect54) came the idea of “middleware.” In my opinion, middleware is the best way to define components on the server. If you want to compare it to a known pattern, it’s pretty close to pipes and filters.

The basic idea is that your component is part of a pipeline. The pipeline processes a request (i.e. the input) and generates a response (i.e. the output), but your component isn’t responsible for the entire response. Instead, it modifies only what it needs to and then delegates to the next piece in the pipeline. When the last piece of the pipeline finishes processing, the response is sent back to the client.

We refer to these pieces of the pipeline as middleware. Clearly, we can create two kinds of middleware:

  • Intermediates
    An intermediate processes the request and the response but is not fully responsible for the response itself and so delegates to the next middleware.
  • Finals
    A final has full responsibility over the final response. It processes and modifies the request and the response but doesn’t need to delegate to the next middleware. In practice, delegating to the next middleware anyway will allow for architectural flexibility (i.e. for adding more middleware later), even if that middleware doesn’t exist (in which case, the response would go straight to the client).

(Large view56)

As a concrete example, consider a “user manager” component on the server. In terms of middleware, we’d have both finals and intermediates. For our finals, we’d have such features as creating a user and listing users. But before we can perform those actions, we need our intermediates for authentication (because we don’t want unauthenticated requests coming in and creating users). Once we’ve created these authentication intermediates, we can just plug them in anywhere that we want to turn a previously unauthenticated feature into an authenticated feature.

Single-Page Applications Link

When working with full-stack JavaScript, you’ll often focus on creating single-page applications57 (SPAs). Most Web developers are tempted more than once to try their hand at SPAs. I’ve built several (mostly proprietary), and I believe that they are simply the future of Web applications58. Have you ever compared an SPA to a regular Web app on a mobile connection? The difference in responsiveness is in the order of tens of seconds.

(Note: Others might disagree with me. Twitter, for example, rolled back its SPA approach59. Meanwhile, large websites such as Zendesk60 are moving towards it. I’ve seen enough evidence of the benefits of SPAs to believe in them, but experiences vary.)

If SPAs are so great, why build your product in a legacy form? A common argument I hear is that people are worried about SEO. But if you handle things correctly, this shouldn’t be an issue: You can take different approaches, from using a headless browser61 (such as PhantomJS62) to render the HTML when a Web crawler is detected to performing server-side rendering63 with the help of existing frameworks.

Client Side MV* With Backbone.js, Marionette And Twitter Bootstrap Link

Much has been said about MV* frameworks for SPAs64. It’s a tough choice, but I’d say that the top three are Backbone.js65, Ember66 and AngularJS67.

All three are very well regarded. But which is best for you68?

Unfortunately, I must admit that I have limited experience with AngularJS, so I’ll leave it out of the discussion. Now, Ember and Backbone.js represent two different ways of attacking the same problem.

Backbone.js69 is minimal and offers just enough for you to create a simple SPA. Ember, on the other hand, is a complete and professional framework for creating SPAs. It has more bells and whistles, but also a steeper learning curve. (You can read more about Ember.js here70.)

Depending on the size of your application, the decision could be as easy as looking at the “features used” to “features available” ratio, which will give you a big hint.

Styling is a challenge as well, but again, we can count on frameworks to bail us out. For CSS, Twitter Bootstrap71 is a good choice because it offers a complete set of styles that are both ready to use out of the box and easy to customize72.

Bootstrap was created in the LESS73 language, and it’s open source, so we can modify it if need be. It comes with a ton of UX controls that are well documented74. Plus, a customization model75 enables you to create your own. It is definitely the right tool for the job.

Best Practices: Grunt, Mocha, Chai, RequireJS and CoverJS Link

Finally, we should define some best practices, as well as mention how to implement and maintain them. Typically, my solution centers on several tools, which themselves are based on Node.js.

Mocha and Chai Link

These tools enable you to improve your development process by applying test-driven development76 (TDD) or behavior-driven development77 (BDD), creating the infrastructure to organize your unit tests and a runner to automatically run them.

Plenty78 of unit test frameworks exist for JavaScript. Why use Mocha? The short answer is that it’s flexible and complete.

The long answer is that it has two important features (interfaces and reporters) and one significant absence (assertions). Allow me to explain:

  • Interfaces
    Maybe you’re used to TDD concepts of suites and unit tests, or perhaps you prefer BDD ideas of behavior specifications with describe and should. Mocha lets you use both approaches.
  • Reporters
    Running your test will generate reports of the results, and you can format these results using various reporters. For example, if you need to feed a continuous integration server, you’ll find a reporter to do just that.
  • Lack of an assertion library
    Far from being a problem, Mocha was designed to let you use the assertion library of your choice, giving you even more flexibility. You have plenty of options79, and this is where Chai comes into play.

Chai is a flexible assertion library that lets you use any of the three major assertion styles:

  • assert
    This is the classic assertion style from old-school TDD. For example:

    assert.equal(variable, "value");
  • expect
    This chainable assertion style is most commonly used in BDD. For example:

  • should
    This is also used in BDD, but I prefer expect because should often sounds repetitive (i.e. with the behavior specification of “it (should do something…)”). For example:


Chai combines perfectly with Mocha. Using just these two libraries, you can write your tests in TDD, BDD or any style imaginable.

Grunt Link

Grunt enables you to automate build tasks, anything including simple copying-and-pasting and concatenation of files, template precompilation, style language (i.e. SASS and LESS) compilation, unit testing (with Mocha), linting and code minification (for example, with UglifyJS80 or Closure Compiler81). You can add your own automated task to Grunt or search the registry82, where hundreds of plugins are available (once again, using a tool with a great community behind it pays off). Grunt can also monitor your files83 and trigger actions when any are modified.

RequireJS Link

RequireJS might sound like just another way to load modules with the AMD84 API, but I assure you that it is much more than that. With RequireJS, you can define dependencies and hierarchies on your modules and let the RequireJS library load them for you. It also provides an easy way to avoid global variable space pollution by defining all of your modules inside functions. This makes the modules reusable, unlike namespaced modules85. Think about it: If you define a module like Demoapp.helloWordModule and you want to port it to Firstapp.helloWorldModule, then you would need to change every reference to the Demoapp namespace in order to make it portable.

RequireJS will also help you embrace the dependency injection86 pattern. Suppose you have a component that needs an instance of the main application object (a singleton). From using RequireJS, you realize that you shouldn’t use a global variable to store it, and you can’t have an instance as a RequireJS dependency. So, instead, you need to require this dependency in your module constructor. Let’s see an example.

In main.js:

      function(App, Module){
          var app = new App();

          var module = new Module({
              app: app

          return app;

In module.js:

          var module = function(options){
          module.prototype.useApp = function(){
          return module

Note that we cannot define the module with a dependency to main.js without creating a circular reference.

CoverJS Link

Code coverage87 is a metric for evaluating your tests. As the name implies, it tells you how much of your code is covered by your current test suite. CoverJS measures your tests’ code coverage by instrumenting statements (instead of lines of code, like JSCoverage88) in your code and generating an instrumented version of the code. It can also generate reports to feed your continuous integration89 server.

Conclusion Link

Full-stack JavaScript isn’t the answer to every problem. But its community and technology will carry you a long way. With JavaScript, you can create scalable, maintainable applications, unified under a single language. There’s no doubt, it’s a force to be reckoned with.

(al, ea)

Footnotes Link

  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
  18. 18
  19. 19
  20. 20
  21. 21
  22. 22
  23. 23
  24. 24
  25. 25
  26. 26
  27. 27
  28. 28
  29. 29
  30. 30
  31. 31
  32. 32
  33. 33
  34. 34
  35. 35
  36. 36
  37. 37
  38. 38
  39. 39
  40. 40
  41. 41
  42. 42
  43. 43
  44. 44
  45. 45
  46. 46
  47. 47
  48. 48
  49. 49
  50. 50
  51. 51
  52. 52
  53. 53
  54. 54
  55. 55
  56. 56
  57. 57
  58. 58
  59. 59
  60. 60
  61. 61!/article/easily-index-your-single-page-application-thanks-to-phantomjs
  62. 62
  63. 63
  64. 64
  65. 65
  66. 66
  67. 67
  68. 68
  69. 69
  70. 70
  71. 71
  72. 72
  73. 73
  74. 74
  75. 75
  76. 76
  77. 77
  78. 78
  79. 79
  80. 80
  81. 81
  82. 82
  83. 83
  84. 84
  85. 85
  86. 86
  87. 87
  88. 88
  89. 89

↑ Back to top Tweet itShare on Facebook

Alejandro is a freelance software developer and JavaScript expert who works through Toptal, a rapidly growing network of top engineers. For more on his experience, check out his Toptal profile.

  1. 1

    everything looks about right with your diagram, however i dont think i’ll ever be convinced that javascript should be running on the server side or that node.js is any good for that matter as long as php exists.

    node.js is the false masiah: because it does not run on the client side, like wtf?

    • 2

      “Node.js is bad because I prefer PHP.”

      Nice logic you’ve got there, bro!

      • 3

        Rafael Gonzaga

        November 22, 2013 5:57 am

        lol, nice xD

      • 4

        I think node is actually bad because
        1. It creates callback hell, you can mitigate the issue (to some extent), but even when you have 1000-2000 lines of code you’re ending up in a mess, because you need to do callbacks for breaking-up long code blocks.

        2. You can’t break the execution of long running code and return to event loop, so you need to divide your code to very unreadable, unmaintainable “blocks” that have nothing to do with code functionality, nor design.

        You actually need to design your code for running pattern, and divide the blocks “equally”, so they won’t block the webserver altogether. Because you can’t simply yeld(); execution it’ll create a mess.

        2a. When you run that 5 mysql queries and end up with callback chain or 5 levels of execution… you can’t just simply “wait” for the callback to finish using some keyword. It’s not built in language, there are some third party libs to do that (unlike yeld, which is unavailable at all), but that’s critical functionality.

        3. To use same code on client you have to be insane. It’s typical argument of compute illiterate, pseudo-programmers. Because there are so many desktop implementations, and so many incompatibilities that there is NO WAY IN HELL that you can use same server side code on frontend. What you’ll get will be buggy and poor quality end product.

        4. There is no way of simply creating such a simple thing as a simple foreach loop, because in JS “everything is an object” so you’ll end up iterating over array functions… which is just FUCKING CRAZY.

        You can write your own code and use callback… so great. Then you have no break nor continue.

        5. Even simple things like trim are not built in into the language.

        JS on frontend – great. Node is just ill designed piece of crap. Great for some simple router, upload handling, etc. where you have 200 lines of code which you can super-carefully test.

        What can you do instead. Perl / PHP / Python for simple code. Google GO or C++ for that 5% that requires extra speed. 0mq for gluing that together. It won’t be simple currently. But node is no way production ready. And the language itself is so poorly designed, that code write currently will probably never be ready for production.

        It’s a shame but it is as it is. Speaking that language designed so badly that simple foreach loop is an issue… is future of the web is just pure BS.

        • 5

          Andrew Baldock

          December 6, 2013 11:42 am

          Paypal — who happens to have some very smart people working for them — disagrees with you.

        • 7

          Rafael Izidoro

          December 18, 2013 4:13 am

          All your argue is just about callbacks…. I think you don’t know PROMISES… it’s already implemented in ES6
          About YIELD, there’s generators implemented in ES6 too…

        • 8

          1) trueish, but using async library and promises helps alot. Once you get the hang of it it’s not bad. Also, you don’t HAVE to write your code that way if you don’t want to. You can write synchronous functions if you want.

          2) You mean yield not yeld right? it exists in ES6 i.e. Node –Harmony. And you can break up long running code using processes or domains or both.

          3) Lots of libraries work great on both, like Underscore and Async.. I don’t think the idea is to run your whole app in both. Just nice little components.

          4) I don’t follow… of course you can create a simple for loop.

          5) What!? Trim has been in JS for ages! If you’re using IE6 it takes 2 lines of code to polyfill it. One of the reasons I love prototype.

    • 9

      PHP is a terrible bloat language. I just ran into this problem were my server was on PHP v5 and my localhost was on 5.4 and the difference in syntax was causing errors when I looked up properties or array index on return values without first assigning them to a variable. PHP was not designed to handle all the stuff we do today and it shows. To write good OO PHP you have to use features that were introduced in the last few years and not use 80% of the features in the language. PHP guides even talk about how bad PHP is. I have yet to use Node but I prefer javaScript, and given the opportunity I would love to develop a CMS with it.

      My pain point with this article is the part about using Backbone and a bunch of other libraries. The author of backbone wrote an article about how he wouldn’t use it himself. The opportunity to create an excellent easy to maintain abstraction by using the language to render and interact with content is immense . Every one just wants to not learn design patterns and rely on libraries that were not meant to interact and have there own flaws and abstractions.

      • 10

        Rafael Gonzaga

        November 22, 2013 6:09 am

        I don’t think PHP is in truth all bad as you’re talking :) … Actually, the biggest problem, in my point is that, when people start using PHP back then, they were very “newbies”, as like all languages at that time and all the people too on the web, anyway, there is a lot of flame debates on the web, that talks about languages and theirs pros and cons.

        Take a look here, this is a good article, or a “sneak peek” from Brandon Savage:

        There is tools, like that:


      • 11

        > The author of backbone wrote an article about how he wouldn’t use it himself.

        Do you have a source for that? It’s sponsored by DocumentCloud, and was extracted from their production library.

        Your pain point might be Backbone. I think it’s probably because you’re not thinking about the tools in the right way (ie. bringing your thoughts server-side MVC design to the frontend). Use it right and you’ll love it. Especially with things like Marionette.

    • 12

      I would refrain myself from commenting PHP vs. node. There are many developers that can carry that burden. However, masiah? OMFL!

      • 13

        Quite correct rmvns.

        Also I take issue with a discussion starting with Node being too slow, and the smack down reply being that Node is great, and PHP is slow – two equally stupid blanket statements!

        *Any* language or tool used badly is going to be poor, the skill is in using, and choosing the right tools for the job.

        Now back onto the topic; I do like the diagram used, and I will most likely include that as a reference image in future. I generally find a Mongo/Node+Heroku/Backbone+Marionette+RequireJS stack to be pretty awesome, but again that one stack will not fit everyones needs.

        But where Javascript wins and loses right now is choice, don’t like the AMD pattern – use CommonJS, don’t like Marionette – use LayoutManager, don’t like Backbone and want something opinionated – try Ember or Angular.

        Of course what it then means is we are in the situation we are now, with tens/hundreds of JS stack boilerplates, little consensus around one, and a huge volume of articles debating which framework is the best.

        We aren’t at the point where we have clear winners, so as always, the best stack is the one you know how to get the mileage from and fits the job.

        • 14

          I totally agree with the sheer number of choices being both a pro and a con. This makes things difficult in a work environment too because you could end up hiring 3 different JS devs who each have experience in a different framework. Or you could hire a bunch of JS devs who agree to use one thing, but after they leave and new devs come in with different experience, they might want to completely rewrite the system because they don’t know the framework very well and would rather use the framework they do know.

          • 15

            A point well raised Joe.

            This places more importance in good project management, and ideally having a technical architect around who knows enough about the stack to be able to swat away personal preferences and keep people focused on delivering and not re-writing.

            A IT business that doesn’t understand what it’s stack is, and why, and have a roadmap of its own creation won’t be a business for long.

    • 16

      Not sure I quite get your last comment.

      “node.js is the false masiah: because it does not run on the client side, like wtf?”

      What does that mean?

    • 17

      What do you mean it doesn’t run on the client-side? It mostly does. In fact when people used Browserify (Much better than Require.js if you’re using Node anyway) they realised that many Node.js libraries work just fine in a browser.

      Plus, you can use NPM for client side libraries, and use node for command line tools (like grunt)

      Its fast, stable, and lets you use Websockets like no other language out there. I’m not sure PHP even supports them yet.

      It may be slightly harder at first though, but it mostly makes up for it by being more scalable as a result. Now to be fair, that mostly because of its limitations. But they are good limitations to have that stop you from doing anything stupid.

      PHP on the other hand gives you too much rope to hang yourself. Too many people use it without any framework or library, and generally write shit code.

      Frameworks like express have pretty much prevented that from happening with node, while mostly maintaing the ease-of-use that is expected of Javascript.

      On a final note, the author is definitely wrong about Javascript and node resulting in More-readable code. Callbacks may make sense, but they are ugly.

      • 18

        “PHP on the other hand gives you too much rope to hang yourself. Too many people use it without any framework or library, and generally write shit code.”
        I can say same thing about people who use Ember.js, backbone.js or node.js generally they can write shit code too.

        The Node.js interesting and sure helps with some aspects of development but it’s not replacement to server side languages.

    • 19

      Gregory Benner

      November 24, 2013 4:04 am

      PHP is a legacy language,
      Node is javascript and yes I think it may run on the client side.

    • 20

      Farax I think you got the wrong address, this is not the ‘Jersey’s shore’ fan page. What a ridiculous comment. Anyway, amazing article and one of the best reads I had lately. Thanks.

  2. 21

    Personally, I love Node.js, it offer great new possibilities and I hope using more everyday.

    Unfortunately, I feel like Node.js is kind of Ruby few years ago. It’s the new amazing platform that will change the way we code, etc… But like Ruby I am not sure it will “make it”.

    I hope I am wrong.

  3. 22

    Michel Richard

    November 21, 2013 9:17 am

    I like the described stack :). Should check out if you want a quick way to boilerplate pretty much all of the above.

  4. 23

    Nice read. I’ve always believed in JavaScript being the future of programming and it’s evident that it is heading to rule. I just hope browser vendors could keep up and include support for some of these frameworks as core features in the near future!

    I’m looking forward to an article that will demonstrate all this technology in action and in depth, and how to use them successfully without having to pull you hair out!

  5. 24

    Thanks for posting this. It confirms everything I secretly believed.

  6. 25

    Great article :)

  7. 26

    Great piece Alejandro,
    I found it informative about several technologies that we haven’t used before, so we’ll have to try them out.

    We’ve heard a lot of the same reasoning from some of our clients about why they want us to build things on node, especially the point about having the same developer able to work on the back-end and the front-end. I worry that this is kind of a mythical benefit, especially for some of our larger corporate clients who don’t exactly hire the most flexible of people. The types of folks who may not be able to transition into Node’s event loop mentality from their primarily PHP back-end focus and front-end only javascript experience.

    One technology that I think you should check out is Compound.js which is an attempted port of rails over to Node.js and it gets close. It’s still pretty green but we were able to deploy it successfully and it did speed up several pain points with great scaffolding.

    Here’s the GitHub:

  8. 27

    that was a very interesting article but it was not “An Introduction To Full-Stack JavaScript”. more like “JavaScript then and now”.

    • 28

      back then (late 90’s) there was JavaScript servers… so not sure how node got the credit.

  9. 29

    Great article! How would you recommend getting started & learning this type of development? I’m coming from a Rails and background.

  10. 34

    Thanks for this article, I learnt a lot about a number of technologies. It seems you are evangelising a little more than presenting balanced opinion on some points. Single Page Applications “…difference in responsiveness is in the order of tens of seconds”, sorry, but that is just a clear exaggeration. I agree they are a lot faster, but not to the scale you present. One other point is how easily you dismissed the fact that MongoDB lacks the ability to handle transactions. Wouldn’t that make it a no contender for most web apps? It would be great if you could use the same quality you used in the rest of the article to expand a little more on that.

  11. 35

    Excellent article.

    I’m looking for a complete CRUD example, in order to start trying with node.js in my own commercial apps.

    • 36

      Alejandro Hernandez

      November 21, 2013 4:44 pm

      Hi Juan Manuel, check for a full sample of a CRUD todo app with backbone express.js and mongodb

      • 37

        you’d be better looking at the todo mvc website ( where multiple frameworks build the same app so you can compare. Make an informed choice, not a quick choice.

        I wish there was a similar site for a complex app, but mostJavaScript micro-frameworks, even combined make for a nightmare in larger apps. Great for websites or small projects tho. ;-)

  12. 38

    This article is absurd. You’ve essentially reduced the full stack down to a system that displays and stores information in a contrived example, inconsiderate of design decisions that should be the driving force of a product.

    No language or technology is suitable for its own purpose. That’s the entire premise of its development. You’re breaking this fundamental principle by asserting that the technology you present is suitable for a range of problems that it’s simply not cut out for.

    A full stack solution relies little on the underlying technology or paradigms or unity of language. It focuses PURELY on the data it is dealing with and develops its execution from there.

    This piece does absolutely nothing to guide our insights about the design if data. Instead it gives us a shallow gesture of one trivial part of the underlying tech we use every day and promotes one specific solution over others for incredibly uninformed and frankly dull reasons.

    JavaScript isn’t “better” than PHP, just as a saw isn’t “better” than a hammer. These things are tools, and you’re arguing for a saw even if I need to drive a nail into wood

    • 39

      Clumsy Hamster

      November 22, 2013 6:27 am

      Absurd I feel is a bit strong. I do though primarily feel the same way. Each technology has its use and the best one is the one that meets your needs and delivers the intended results in the most efficient and beneficial way. I’ve touched a lot of technologies from open source to what not but I’ve yet to find one that meets all of my needs. The “full stack” idea is awesome and is something that will continue grow. There are many companies out there that already offer the full stack approach but go about it a different way and actually have for longer than most of these libraries were heard of. Client/pseudo-client technology may never replace the languages oriented from the server side.

      • 40

        You’re correct in saying that absurd is a bit harsh. That comment was accompanied by a beer or two. ;)

        There are two things this article gets dead wrong:

        1. JavaScript is a functional programming language.

        While it’s possible to write JS in a functional style, it does NOT by default implement pure functions, referential transparency or immutable data structures. The conventional way to manipulate an array of values is through ‘for’ and ‘while’ loops, not tail recursion, list comprehension or map/reduce; these are things a functional programmer uses every day.

        2. MongoDB is for JavaScript as MySQL is for PHP.

        Data simply isn’t modeled this way. Just because you can write JSON all the way down to your data store doesn’t mean your data is in ANY way represented properly by a schema-less document store. Try writing a web service with heavy relations (eg. a social network) with a nonrelational database like MongoDB, and you’ll quickly notice your data is poorly represented by your database choice.

        I think this article is targeted at those who’ve been writing front end code and want to dip into server side development. There is absolutely nothing wrong with wanting to learn more! But it’s very important to realize that “standards” in technology are incredibly subjective. It’s best to explore a wide variety of options by educating ourselves and making our decisions from there.

        • 41

          Hammer, meet nail.

          This seems to be trend among the ‘flavor-of-the-day’ development crowd. The focus is on ‘cool’ and ‘convenient’ and not on the problem domain. One specific example here is the author’s flippant dismissal (via omission and an aside on MongoDB’s lack of transactions) of the relational database model. As an employer I would expect any so-called ‘full stack’ developer to be able to clearly articulate in an interview not only MongoDB’s benefits, but also its disadvantages, and to understand and extrapolate on pluses and minus of the relational model as well.

          Don’t ever put choosing a solution ahead of understanding the problem domain. Those that spend the appropriate time understanding the problem to be solved, its measures of success, the stakeholders involved, and the true business value proposition–the correct stack (and, truly, what a horrible term in our current environment of polyglot architectures) will generally reveal itself in the natural flow of things.

  13. 42

    MEAN stack ftw!

  14. 43
  15. 44

    TBH I’m not sold on the whole “JS all the way” argument.

    Let’s take ourselves back to when the term Ajax was first coined…

    At this time IE6 was the dominant browser, less than 40% of UK households had broadband (and speeds were less than 2Mbps). The main selling point for Ajax was as the answer to the problem of poor web (app) performance when compared to desktop equivalents (why reload the entire page when you can just refresh the bit that changed).

    Where I worked I evangelised this method of writing web applications – and had written a JS UI Library that mimicked Java Swing for our development teams to use (10K+ lines of code including normalising the DOM, fixing cross browser issues, creating widgets, dependency loading, i18n, a11y etc. etc.).

    Fast forward to 2013 and web browsers have taken a massive leap forward in terms of rendering performance, caching and prefetching. CSS and HTML standards have also moved forward and we as developers have become better at tuning the apps we write for the web platform (by caching resources, base64 encoding images, combining and minimising CSS files and utilising http compression, thereby reducing the size and number of http requests).

    As a developer I strive to write less code. Less code is easier to maintain than more code. Less code is also physically smaller than more code and so loads and (usually) executes faster than more code.

    For an example, an in-house SPA (GWT) was rewritten using only HTML (via JSP) and CSS. Over a network the new app was approx. 10% of the size of the original (50K instead of 500K – 48k was CSS and therefore cached) and it had approx. 75% less http requests (3 instead of 13). There was also less code to maintain; 10 JSP files, 6 Images, 4 Java Classes and 1 CSS file, versus 128 Java classes, 24 XML files, 9 images and 4 CSS files. Compiling/building the app was also considerably quicker (seconds versus minutes).

    There was no visual/behavioural difference to the use – tabs, menus and trees still functioned as they had before.

    Now, if we really need to utilise JavaScript/Ajax we can do so in small, lightweight, focused modules.

    On a mobile network, the single biggest web app performance bottleneck is the http request (RRC –> DNS –> TCP –> TLS –> HTTP), if your app needs data from a server this latency is something you’re going to have to swallow and deal with, SPA or not.

  16. 45

    What about CouchDB ? I’m not an expert but I’ve read that it’s vastly superior to MongoDB in many ways while it serves the same purpose.

  17. 46

    Also, we have found Angular.js to be preferable to Backbone and Ember in many ways for our particular use case, so I would advise readers not to leave it out of the evaluation when choosing a front end framework.

  18. 47

    “This didn’t work as expected, and most of those projects failed (for example, ASP MVC replacing ASP.NET Web forms…”

    Sorry, WHAT? I couldn’t let this pass. ASP MVC is *thriving* right now, with a huge community of developers, and a lot of Open Source library support.

    Stack Overflow:
    ASP.Net MVC: 72K Questions tagged.
    Node.Js: 32k Questions tagged.

  19. 48

    Patrick Mulder

    November 22, 2013 5:56 am

    Very interesting article! I like the pipeline approach to develop a web application too. In this context, I found the ArangoDB incl. its Foxx application server ( ) a very good option for development for hacking on new applications. The corresponding TodoMVC is this:

  20. 50

    This is exactly what I needed that I didn’t know I needed. Perfect timing too. Finally deciding to make the leap from years of PHP to full-stack javascript I spent all of last week bumbling about on DigitalOcean tooling around with node/backbone/ express and mongo/mongoose but not really learning or accomplishing much. Too eager to dive in and play with all the new shiny things this article made me realize I need to take a step back and gain a better understanding of the fundamental architecture if I want to create anything of value. Thanks.

  21. 51

    This is exactly the article I needed but didn’t know I needed. Perfect timing too.

    Finally deciding to make the leap from years of PHP to full-stack javascript I spent all of last week bumbling about on DigitalOcean tooling around with node and mongodb but not really learning or accomplishing much.

    Too eager to dive in and play with all the new shiny things I’ve finally realized I need to take a step back and gain a better understanding of the fundamental architecture before I start building. Thanks.

  22. 52

    Ambrose Little

    November 22, 2013 8:05 am

    TypeScript is not a replacement for VBScript. They are entirely different things. Well except for the “Script” name. That’s like saying that JavaScript is a replacement for Java. Nor is TypeScript really an “alternative” to JavaScript. Think of it like a tool on top of JavaScript; it is complementary, not an alternative.

    • 53

      Typescript isn’t a replacement for javascript, it’s the next generation of JavaScript in a vendor package. (just as dart is).

      The vendors are once again fighting to have their implementation accepted by the W3C. Some things never change.

  23. 54

    Nice read. Thanks a lot for the effort :)

  24. 55

    Nice discussion. I’m among those Rails developers currently experimenting with full-stack JS, and I think one of the nicest advantages of having a “rich” client running in the browser is that it can considerably reduce complexity on the server side. E.g., an Angular app which handles its own templating etc can easily talk to JSON APIs offered by any kind of simple server; the server can then retain single responsibility for persistence and backend business logic while remaining completely decoupled from view-rendering and UI.

    For anyone interested, I recently wrote up a short exploration of a few approaches to AngularJS+Express here:

  25. 56

    I’ve been using RoR for the last year or so, coming from WordPress. A lot of this article aligns with my desire for simplicity. It would be fantastic to have one language do everything, but having all these different frameworks makes me think their addition to the learning curve would undo the convenience of having one language. Using RoR with an Agile, backbone or ember gem seems a lot easier to manage and a lot easier to learn.

    The potential is there though. I’d love to dive into a framework like RoR or Zend built on 100% JS. If it works, I wouldn’t budge from that framework for years.

  26. 57

    I’m a believer and I have seen the light! JS has come a long way and I’m excited to see what the future brings.

  27. 58

    You say that SEO can be solved for SPA sites. A few problems though:

    A single page app does not usually need SEO. The app views are not interesting nor rankworthy to put in the index.

    If you applied SPA methodology to a content website you have made a useability and SEO faux pas.

    So many web developers forgot how to provide reasonable javascript fallbacks that browsers vendors now delete the option to turn it off. Too many sites break, because they have that SPA use-js-for-ALL-the-things mentality. It has become a privacy and security issue due to TOR browser shipping without noscript, due to again too many pages breaking. That is bad web development my fellow devs. This has real world consequences.

    Cool url’s do not change and do not require you to tell “exclamation mark hash bang” over the phone.

    Using a headless browser to crawl your website shows something went very wrong. That you need a syntax from a single search engine shows something went wrong. And offering static content to search engines only like author suggests? Bad, bad idea for SEO. Treat search engines like any other (blind) user.

    You give static content but forget to offer content for noscript users? Shame on you! You contribute to vague and counter intuitive javascript UI elements? You cause the accessibility movement lots of pain. The biggest complaint for screenreader users are these SPA’s without good ARIA support.

    With great power and ease, comes great responsability. Your decisions have a real life impact. Your decisions make it so your website can exist for 1000 years or falls quickly into decay, because it needed server side JS to show content. We are the digital monks of our age.

  28. 59

    If you don’t want to go the MongoDB route, you can now use the new AWS SDK for Node.js:

    And if you think that is cool, you should check out the even more bad ass dev preview for JS in the browser which eliminates the service layer altogether:

  29. 60

    syed shaik shavali

    November 23, 2013 11:49 pm

    Nice …Article. Its nice to know that they are other JS also exists.

  30. 61

    Thanks for the server model diagram that is very usefull at how everything fits together (plus the write-up). I’ve had a quick play with Node.js many months ago and at the time I was quite impressed with it. It is something I am interested in re-visiting again sometime in the future.

  31. 62

    Davide Callegari

    November 24, 2013 11:53 pm

    Nice article, thanks for that.
    I believe you’ve addressed some of the issues a web app developer faces, but I think that the main problem is making client and server talk, having two different programming languages shouldn’t be an issue today, as most web developers easily know 4 or 5 programming languages (if you don’t then I highly doubt this is the right industry for you).

    I really like projects like Meteor ( ) because they tackle every single aspect of the problem in an interesting way.

  32. 63

    I’m kinda surprised that in a ‘full stack javascript’ article you left out Stylus when mentioning CSS pre-processors. There are pretty good bootstrap ports to both SASS & Stylus.

    ….just sayin

  33. 64

    I think this article is very informative, and that in particular cases this choice of the stack is a valid one.

    However, I’m not entirely convinced by the major benefits presented:

    “Non-blocking programming”

    Yes, it certainly is nice to have parallel programming so accessible, but in my experience, much (most) logic needs to run sequentially. In some ways, javascript can even make this a pain, not a benefit, having to chain call-back after call-back. Therefore, I wonder how much of a real world advantage this is. Note that many programming languages have had parallel programming them for years, usually in the form of threads. Very few actually use them.

    “The looking for a Python developer issue”

    The same issue applies to the JS stack. I think there aren’t many developers available and experienced for full-stack JS delivery. And worse, if they are, each is specialized in different frameworks. The JS stack does not score any better in this regard. It’s a problem across stacks. Whilst I love the open source community, they really ought to work together better to create less frameworks of a higher quality.

    Finally, I don’t really understand the whole single page app trend. It is claimed that they are amazingly faster. I don’t understand why though? I’m assuming these one page web apps have assets cached and make ajax calls to a back-end. How is that any faster than a classic web app that does the same thing?

  34. 65

    Synchronous sockets would handle one request at a time, each in turn and where one request can hold up all the other requests.

    Asynchronous socket is an event-driven solution where hundreds of requests means only hundreds of socket/state objects, not hundreds of threads or processes.

    Also a comparison of JSON and XML

  35. 66

    Um, nodejs was not even close to the first server-side js server. Netscape had server-side javascript servers in 1998… there’s been hundreds of them before node and there will be more. Node is nice, but it has it’s good points and limitations and like similar products on the market. Bring on the next fad.

    ” All attempts to destroy it have failed;” – um, never heard anyone with credibility try to kill JavaScript, purists laughed at it, but the one thing about purists is that they don’t last as long as the languages they bag.

    Ironically ColdFusion was (and is) the most transferable to JavaScript. It (and later Ruby) were very popular and used heavily for agency work in the early days (way more popular than PHP back in the ASP days) and in 2013 is massive again (in large enterprise) for integration and large web farms with older infrastructure and for super fast cloud clusters. A lot of people also now use the ‘Railo’ open source version which is lean and fast. (they now allow measure their page load times in nanoseconds)

    Best Practices: Grunt, Mocha, Chai, RequireJS and CoverJS (I guess we’re talking about basic websites then?)

    “flexible and complete.”, let’s you choose and assertion library.. um that means it’s NOT complete. how apple of you to gloss over it’s non-completeness. guess that’s what microframework fanbois have to do.

    Sencha’s and Teleriks’ stacks are the only full stable enterprise stack right now, so surprised you didn’t mention them? Also the Siesta testing tools by Bryntum are kick butt and allow unit and ui testing out of the box, TDD, and non TDD also (once again flexible).

    Sencha’s frameworks are super flexible too – you can use MVC, MVVM, or MVP (and bind to markup if you want). There’s really nothing like it. Their tools are first rate, and no need for grunt when using Sencha tools either, but you can if you want, and their build tool removes core library code that isn’t being used to minify your build, so the core lib starts large in dev, but minifies down to

    An introduction on a site like this should cover off on ‘ALL’ of the leading products, not your favorite niche products.

  36. 67
  37. 68

    Great Article!!! Thanks for good post.. Hope JavaScript rules web world in near future…

  38. 69

    Chris McIntosh

    December 2, 2013 7:06 am

    PHP v Node.JS is a misnomer, its the same as Drupal v WordPress. You should pick the best tool for the project and not force a project into something because its ‘better’, i have not seen many metrics comparing the two on speed/memory use/scalability/etc.

    Typically I use node js as a small part of larger projects and use Drupal/Wordpress to provide a simple CMS backend for administration.

  39. 71

    excellent article!

  40. 72

    Good article! But regarding the “full-stack-developer”-topic I had to write a comment (on my blog, as it got a little longer …):

  41. 73

    I’m gonna have to agree with many others here. The full JS stack is just one of many options that you may or may not use depending on the job at hand. There never has been, and never will be a “one-size fits all” tool for web development due to the webs very nature of being in constant flux due to its evolutionary nature.

    This mentality of “I MUST USE ONE LANGUAGE” has hurt more developers that I personally know than it’s helped. If you can’t properly choose the right tool for the job, then you probably shouldn’t be doing this as a career. No “Full-stack Developer” worth their salt will ever tell you that there is one tool for the whole job, that’s why we kill ourselves learning front-end/back-end programming principles, styles, and languages.

    TL;DR: Don’t try to shoehorn yourself in to a technology just because you “think” it’s the holy grail; Use the tool that fits the job correctly.

  42. 74

    i don’t like Javascript on the server for several reasons. First of all I get confused between client code and server code when everthing is in Javascript. Secondly the language itself lacks some features like integers, real class definitions and generators. I prefer Python (or Ruby). If your server application grows in complexity beyond marshalling data between the DB and the browser, Javascript quickly becomes a PITA. Thirdly node..js itself is not without ugly parts. A bug can completely bring down an event driven system it is less resilient against DoS attacks and node.js runs as root, which makes me extremely uncomfortably in terms of security.
    So my preferred architecture: angular.js (not backbone), a Python application framework (Django/Pyramid) and MongoDB

  43. 75

    Really great article! But did you forget a couple of words about Marionette?

  44. 76

    Re the point about code not being re-usable between the client and server because of browser differences – this should of course be irrelevant. If you have designed your application well it will be obvious which modules can be re-used, which ones can only run on the browser and which ones can only run on the server. And trying to program around browser differences is just giving yourself unnecessary headaches anyway.

  45. 77

    Thanks for the great article! Looking fwd to more!

  46. 78

    Great article!
    I have one question:
    How do You write mocha tests that use requirejs? How is it the easiest way to bootstrap it?

  47. 79

    Hi, I enjoyed reading this post and I thought it was a good idea to translate it to Spanish. So I did, as a post on my blog. Of course I gave you the credit and provided a link to this original post. I used your images, just linking to them. Hope that’s ok, if not please let me know. I’ll make any necessary changes.
    I can’t send the translation link here, for you to check. It’s on “sandravegaux” domain, in the folder “blog”, the page name is “una-introduccion-a-aplicaciones-full-javascript”. I posted it just today 09-02-14.

  48. 80

    Cool, we have the same point of view.. I agree javascript is a preferable programming language

  49. 81

    It’s important to note, I think, that although many commenters are weighing-in and agreeing that this is the future – it’s not the *only* future. Your application should be built using the tools that are appropriate. If you know your backend platform will not change then I think you’d be pretty mad not to consider a type-safe language for that.

    We’re used to debugging JS on the client (e.g. in the browser) because the speed of that debugging workflow is good. But in my experience you end up doing a lot more of it than when you write, e.g. C# code, because there are so many opportunities for runtime error.

    Being used to debugging JS on the client doesn’t mean we should naturally assume that the same dev workflow is good on a back-end server. Sure, not all languages support parallelisation “for free” but there are certainly options that are far better than they used to be (C#, Mono, new C++).

    I’m not advocating these approaches over server-side JS per-se, I’m just saying let’s use the right tool for the job.

  50. 82

    For a really good example of FullStack JS, take a look at

  51. 83

    Hi everyone, I’m interested in adopting a full stack javascript platform.

    Does anyone of you have used Wakanda

    Seems very promising

  52. 84

    Patrick Mulder

    December 12, 2014 9:00 am

    Nice overview article on full stack JavaScript. Indeed the evolution of web apps progresses towards rich clients on one side, and API’s on the other. With Node and JavaScript, it is even possible to have the first page load rendering on the server, while additional requests are just processed with Ajax at the client. Much of this, mainly with Browserify, I also discuss on my book

  53. 85

    Elliott Greaves

    January 24, 2015 2:34 pm

    Great article,

    The rewards for working with this environment are irrefutable, although I believe that the learning curve and initial setup of the full-stack JS environment is quite steep… and scary.

    Coders who have experience building ‘legacy’ websites using popular technologies like WordPress or Drupal (which are very straight forward to get started with) who want to take the plunge, may struggle to get going in this type of environment.

  54. 86

    The trouble with node async style is that if you have to do N things in a row to get a job done then you get N indents in your program (and/or N sets of brackets) and this mounts up quickly into an incredibly hard program to read, write and maintain. This is known as the “pyramid of doom” faced by all serious node programs.

  55. 87

    Crew Spence

    May 6, 2015 10:55 pm

    Thank you so much for this article! I’m doing a lot of learning in this area (I’m completely new to it), and you’ve answered SO many questions!!

  56. 88

    Good Article ,
    i have enjoyed reding it

  57. 89

    Thanks for this great information about JavaScript

  58. 90

    i am a book person…
    I feel comfortable with online documentation but in the end I love to have a “go to” expert’s book for references. Can you recommend some good JavaScript books?

  59. 91

    Preguntón Cojonero Cabrón

    August 6, 2015 6:38 pm

    Great and marvellous.
    I’m Windows and .NET C# developer. Using ASP.NET (JQuery) for websites.

    For full stack javascript,

    IMHO, better samples for minimize learning curve are real applications with full source code and good patterns.
    Any good getting started with a full stack js? step by step in 10 minutes with it?

    Full source code sample REAL application? not Demo, only real applications? but open source, if you can sharing or maybe another real project ( production-ready application using it)


↑ Back to top