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.
Would I recommend it for large-scale products? Absolutely not. Do people do that anyway? Of course they do. I tried to.
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”
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!
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.
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.
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 :)
I’m not sure what I’d use instead of Node – PHP? C#? Golang? Not sure. I’ll stick to Node.
All good, Francis, if it works for you ;)
What are you using instead?
Most of the projects that I am involved with are in PHP.