After a year of using NodeJS in production

There are days, when I feel jealous of all the young kids playing around with new technologies.  I need a certain level of stability and acceptance of the technology before I can apply it to client projects.  And I need time, which is a very scarce resource lately.

And yet there are days, when I feel good about being somewhat reserved and conservative in my technology stack choices.  Reading this blog post makes me feel just that.  Of course I need to try it out for myself and shape my own opinion, but with my lack of time, this should do.

I spent a year trying to make Javascript and more specifically Node work for our team. Unfortunately during that time we spent more hours chasing docs, coming up with standards, arguing about libraries and debugging trivial code more than anything.

Would I recommend it for large-scale products? Absolutely not. Do people do that anyway? Of course they do. I tried to.

I would however recommend Javascript for front-end development such as Angular or React (like you have another choice).

I would also recommend Node for simple back-end servers mainly used for websockets or API relay.

Now if only somebody wrote a similar post about Docker …

9 thoughts on “After a year of using NodeJS in production”


  1. Recently in EmberConf, held in London, did a nice comparison of typical MEAN stack, Angular/Ember module comparison (https://www.periscope.tv/embercamp/1mrGmzPBvQqJy). Way too many modules, too many dependencies to track, and tones of changes that might affect your application. From the back-end developer side, it looks like the guys haven’t come up with something stable at least for a year or two. It’s really distracting!


    1. Yup. Also, this is more or less manageable if you are working on a single application / project. If you do client projects at a rate of two a week – you are pretty much screwed.


      1. True. In case of two weeks iteration, I’d choose solid/stable back-end PHP/Ruby/Python backed frameworks (full, or micro-, depending on the task), and for the front-end I’d rather choose Ember/React. IMHO, React is currently “too fancy” to build something solid, unless you have one-two front-end dev’s in the team, that would constantly monitor all the feature releases.

        For the last 3-4 months, I’ve noticed something evil-ish happening in the main JS frameworks (Ember/Angular/React), every major release (Ember 1.x to Ember 2.x, Angular 1.x, Angular 2.x) ends up with developers to completely re-write whatever’s been done.

        Doing some basic maths, you gonna get stuck with legacy (nontransferable) code every 6-12 months, that’ll make your dev’s cry.

        To sum things up, JS ends up to be very expensive for SMB, unless you specialise on it, and be a part of it, like DockYard for instance.


        1. That’s exactly what we do. We basically limited ourselves to two technologies – WordPress and CakePHP. WordPress is mostly used for simpler projects. For CakePHP stuff we’ve created our own setup, which even features a very basic DSL, so that we can cut down on the maintenance A LOT.

          Gladly, we don’t need much on the front-end. Good old jQuery with plugins does the job.

          This works very well for us, as we do a lot of projects and we primarily target business users, who are not too demanding when it comes to user interfaces. It’s mostly paper forms on steroids :)

Leave a Reply to Francis KimCancel reply