A blog post from PayPal validates that theory very well.
The author of that post says they, PayPal, is looking for "full-stack engineers" who can code both front- and back-end stuff. He even described the boundary between browser and server code as "artificial."
They like Express, but found that it's too flexible and desired to have some conventions used in PayPal's applications. They came up with a library to house those conventions.
To test whether Node.js would work at PayPal, they chose to take their "account overview page", one of the most trafficked pages on PayPal's service, and recode it in Node. To hedge their bets they had a second team work on a Java implementation.
The Node team had a slow start because they had to build up some infrastructure for node.js to work in PayPal, e.g. sessions, centralized logging, keystores. Even with a two month lag before they could start work on the actual application, they beat the Java team to the end goal. Further the Node implementation had these gains:
- Built almost twice as fast with fewer people
- Written in 33% fewer lines of code
- Constructed with 40% fewer files
- Double the requests per second vs. the Java application. This is even more interesting because our initial performance results were using a single core for the node.js application compared to five cores in Java. We expect to increase this divide further.
- 35% decrease in the average response time for the same page. This resulted in the pages being served 200ms faster— something users will definitely notice.