Join the DZone community and get the full member experience.Join For Free
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.
- Express: a framework for providing REST APIs and web pages on top of Node.js.
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.
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 support: ECMAScript 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.
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.
Published at DZone with permission of Giorgio Sironi , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.