TL;DR; The switch was actually not that difficult for me as I was used to the paradigm of having a rich client and the server providing a slim JSON interface. The biggest gain for me is productivity. Having the same language on the server and the client side in makes things just much easier. On top of that, add the vast amount of NPM packages at your fingertips: things become really interesting.

Javascript syntax is not what makes Node.js better than PHP

In my opinion, your first steps with node.js will depend heavily on what you did before. Indeed, there are different ways to develop a web application in PHP. There is the old and ugly way everybody likes to hate and there is the better and modern way of developing in PHP. Depending on what you are doing right now, switching to a MEAN stack will either be a whole new world or not that crazy at all.

I tried both approaches. When developing in PHP the “modern” way, there were lots of javascript in the client and a server which acts more like a pure data API.

How I did things before on the server with PHP and the Laravel framework:

Route::get(‘user/{id}’, function($id) {

$user = User::find($id);

return Response::json($user->toArray());

});

And how I do the same thing now with node.js, Express and mongoose

app.route(‘/user/:id’).get(function(req, res) {

User.findById(req.params.id).exec(function(err, user) {

res.jsonp(user);

});

});

Looking at this you might wonder what all the fuzz is about and why people get so emotional when talking about different programming languages.

Async is your new best friend

The simple example above illustrates already one of the biggest differences though. All Input/Output functions in Javascript (reading a file, calling a database, API calls, …) are asynchronous procedures, whereas PHP gets executed sequentially. While you can just assign the output of a database call to a variable when working with PHP, you need work with callbacks or promises when doing this in Javascript.

This pattern is well known to every developer who touched a piece of javascript in his career (e.g. with jQuery). It’s however still something to get used to when doing multiple database calls, merging data and applying complex business logic.

The main challenge for me was to organize my code in a way that it stays readable (e.g. prevent the so-called Callback Hell). Once you figure this out and you know how to leverage the power of libraries like Async, everything becomes pretty easy. In fact, having the possibility to do several operations in parallel can be fun.

node.js’ package manager NPM proves the power of the Community

Chances are high that you were already using a package manager for one of your projects, e.g. composer in PHP or RubyGems for Ruby on Rails. The node.js package manager is called NPM.

At first sight, I thought there was nothing special about it, it just works as expected.However, when you look at the sheer amount of packages you can install (128k at the time of writing) the power of the community around node.js becomes clear. While using composer in PHP feels just like a convenient way to install libraries, NPM seems to be the center of the node.js community.

There is still more PHP source code available on the Internet than Javascript server side code. Most of it feels, however, outdated and doesn’t fit in the modern web development workflow. It seems there is node.js code available for every aspect of modern web development and you can solve most problems by installing the appropriate NPM package. This is a huge time-saver and changes the way you think about complex web applications.

#1 advantage: you only need to deal with one language

The biggest gain for me is however rooted in a very simple fact: Having the same language on the server and the client side. No more switching back and forth between languages context saves me a lot of time and is very pleasant.

While there is still a clear separation of concerns between the client and the server, all code looks the same and behaves the same way. When adding MongoDB as a data storage to the stack, JSON becomes omnipresent and there is just one way of accessing data objects. In addition, a lot of libraries work seamlessly on the server and the client at the same time (e.g. Moment.js) so chances are high that you just need to learn things once.

No regrets, definitely worth it!

Looking back, switching to Javascript on the server was less painful than expected. There is still a ton to explore for me and I’m pretty sure there are moments of desperation ahead. I would definitely recommend looking into the topic to someone who is about to start a new project and who is motivated to learn something new.

Web applications are nowadays heavily - if not solely - based on Javascript (AngularJS, Sails.js, Backbone… you name it) on the client side anyway. In this kind of setup, the server acts mostly as a thin data layer offering simple CRUD functions via an API. So why not just implement the API in Javascript as well and eliminate one language from the stack?

The simple fact of having the same language on the server had a big impact on my daily work and just for that I would do the switch again.

Ps: I’m looking for talented developers to join my team (in Paris) — ping me on Twitter if you wanna know more.