Over a million developers have joined DZone.

Building an Application With a JavaScript-only Stack

Giorgio Sironi provides an example of how to build an application using the MEAN stack for a purely JavaScript implementation.

· Web Dev Zone

Start coding today to experience the powerful engine that drives data application’s development, brought to you in partnership with Qlik.

As I often do when checking out a new platform or language, I have been building a new pure JavaScript implementation of the Game of Life simulation like I did for Java 8.

In this case, my choice fell unto the MEAN stack:

  • MongoDB: a general purpose document-oriented (and as such NoSQL) database with support for querying and aggregation.
  • Node.js: the famous server-side JavaScript interpreter.
  • Express: a framework for providing REST APIs and web pages on top of Node.js.
  • AngularJS: one of the popular client-side JavaScript frameworks for building Single Page Applications.

The experience has been quite interesting, as you really get to know a language and its libraries when using it for a project; in a way that no book can force you to do.


Here are a series of myths I want to dispel after diving into a full stack JavaScript project for a few weeks.

It is true that there is less of a context switch when changing between the server-side and the client-side applications since you are always writing the same language. However, this seamless transition is limited by several differences:

  • different language supportECMAScript 6 has to be compiled down by tools like Babel to ECMAScript 5 to be compatible with any browser and Node.js version. Polyfills may be needed to try and unify the experience.
  • Different libraries: Testing frameworks change between server and client, and so does how you build mocks.
  • Different frameworks: Angular and Express both have their own ways to express controllers and views.
  • Different tools: You install packages for the server-side with npm but use Bower instead on the client.

The key to productivity is in being opinionated and choosing (or have someone choose for you) a single tool for each purpose, without being carried away by the latest fashion. In this case, I followed some default choices and trimmed that down to get:

  • Mocha and expect(), one of the three flavors of the Chai assertion library, for the server-side.
  • npm and Bower for server-side and client-side.
  • wiredep to generate script and CSS tags for the single page to be loaded.
  • Grunt as a build and automation tool, wrapping everything else.

One good way to pick up default and platform idioms is to start from a predefined stack, and you can do so by cloning a template or a generator like Yeoman. If the generator is well-factored, it will give you sane defaults to fill in the gaps such as JsHint and a configuration for it.

Another myth I would like to dispel is callback hell: if you use the ECMAScript 6 construct yield, you can pretty much write synchronously looking code by building an iterator of steps (each step producing a promise whose resolution will be passed in as an input for the next.) There's probably something even more advanced I didn't reach yet in ECMAScript 7. Don't take this as me saying you can write synchronous code in JavaScript (it only looks synchronous), and you definitely have to learn to use the underlying layers of callbacks and promises before you can grasp what yield is really doing.


With a reference to my previous experience in Java, the productivity of the JavaScript stack feels very good in the short term (I only explored that time frame), due to its simple syntax and structures, especially with support for ES6 which removes a lot of boilerplate.

For example, there is no need for Set<Cell> aliveCells = new HashSet<Cell>(); definitions like in Java, as you would write aliveCells = new Set() with purely dynamic typing (suffering the occasional unfortunate consequences of this choice, of course.)

To evaluate productivity and robustness in the long term, you would have to build a much larger project on a team composed of multiple people.

I found the tight feedback loop of grunt serve was another positive impact on productivity: you can set up a watch on files so that every time you save, the Node.js server is restarted, and the current browser page is reloaded. This is accomplished by LiveReload monitoring from the browser side with a WebSocket. Of course, once you get the hang of the testing frameworks and their assertions, you're back to the even stricter feedback loop of running tests and having their output in milliseconds.


I'd say you can reach good productivity in a pure JavaScript environment, even if I am unsure about the pure dynamic typing approach.

You'll have to get opinionated and choose wisely 1) to not introduce duplicates and clearly assign responsibility to each of this tool so that it's unambiguous that npm should not be used for client-side modules 2) to take control of your stack, as everything that you install is still only JavaScript code copied into your project and that you can read to get a feel for what it's doing.

In programming, a feature that seems to consist of just a few lines of code often turns into an engineering project. In very dynamic and immature stacks such as JavaScript, it's even more important to build strong foundations, tools, and processes to turn a blob of code into well-factored software.

Create data driven applications in Qlik’s free and easy to use coding environment, brought to you in partnership with Qlik.

javascript,mean stack,web design and web development,angular js,express,node,mongo db

Published at DZone with permission of Giorgio Sironi, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

The best of DZone straight to your inbox.

Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}