Andy McKay

Nov 26, 2013

When to use node.js


There was an interesting post on the PayPal blog about using node.js. But this line had me seeing red:

Historically, our engineering teams have been segmented into those who code for the browser (using HTML, CSS and JavaScript) and those who code for the application layer (using Java). Imagine an HTML developer who has to ask a Java developer to link together page "A" and "B".

PayPal Blog

First off, the term HTML developer is wierd, but the blog mentions the tools of their trade in the line above, so we'll let that slide. We'll call them front-end and back-end developers.

Secondly, why is hard to imagine a front-end developer writing some Java? They are developers, they probably know multiple languages and have experienced working in both the front and back-end. To reverse the scenario, why can't those who write Java, also write the front-end code?

Assuming that people can do one skill, but cannot do another is tantamount to insulting people's intelligence and ability to learn. I see little reason that you can't expect people to learn multiple skills and abilities. In fact doing so, is an key part of personal development for software developers.

This doesn't discount the fact that there will be experts. People will become experts in some domains, but its those experts jobs to be welcoming, opening and ensure that multiple developers can pick up and join their projects and work on them.

So I can only make some wild guesses on the state here, but let's make the assumption that you've got some big monolithic Java project where setting up Eclipse, Ant and the build tools or whatever they use is so horrible that people don't want to approach it (later it mentions that the new project takes 40% fewer files and 33% fewer lines of code). If that's the problem, what is being gained here is rewriting and using a different tool chain.

How does it work at Mozilla? We have experts in key areas, module owners if you like. If I want a front end fix, I can either ask someone to do it or send in a pull request and get them to help me get it up to speed. Everyone is free to send each other fixes to each other and people. I've never seen anyone at Mozilla get annoyed or grumpy when someone tries to send in patches to each others modules.

We interview a lot of talented developers at Mozilla and I often hear this phrase when discussing candidates "they are obviously a front-end (or back-end) developer, but I have no doubt they will learn the back-end (or front-end) quickly based on...". Ability to learn and be flexible is more important to us than the existing skill set.

Thirdly, why is it so hard to get different people on different teams to work together? Regardless of the language, I imagine an organization like PayPal will have teams that expand quickly. You will have people working on those teams grow and grow to the point that you cannot understand the whole flow and use cases. Soon you will have person on team X asking team Y for a fix. Not because of a technological difference, but because of domain expertise differences.

I don't doubt node.js is a good fix for PayPal, but that one justification annoyed the heck out of me. If there are organizational and development issues, PayPal better fix those too or they will be in the same boat a year from now. Just a node.js boat, not a Java one. There are many good reasons to use node,js, but magically fixing problems in your development team is not one of them. There are no magic beans.