Node.js' success exposes its weaknesses

The server-side JavaScript juggernaut's complexity and vulnerabilities still bedevil many devs

Node.js' success exposes its weaknesses

Node.js has been a revelation. Initially received as a curiosity, the server-side JavaScript platform has become a juggernaut, in use by tens of thousands of organizations in more than 200 countries, according to the Node.js Foundation. But for some, the Node.js glass remains half-empty, thanks to several frustrating weaknesses.

Take Gavin Vickery, CTO of web app builder Input Logic. Vickery made the switch to Node.js from Python in 2015, mostly for web back ends. But he soon grew dissatisfied with the promise of Node.js, writing early in 2016 that Node.js was “easy to learn,” especially for those who know JavaScript, but “impossible to master.” He described the Node ecosystem, particularly NPM, as constantly moving. “You’ll never master something that moves at breakneck speed, not to mention the potential of dependency instability.”

Node’s error-handling is also an issue, Vickery said. And callbacks presented problems, with promises lacking a single standard to implement them. “I spent a year trying to make JavaScript and more specifically Node work for our team,” he said. “Unfortunately during that time we spent more hours chasing docs, coming up with standards, arguing about libraries, and debugging trivial code more than anything.” He does not recommend Node for large projects, but feels the platform is adequate for use on back-end servers deploying WebSockets or API relay.

Another critic, consultant Paul Shan, of the Void Canvas blog, has found issues with Node being single-threaded. “You really have to design your devops things very well to use your server machine properly. I think this is the biggest problem with Node.”

Meanwhile, the company Snyk is building a business tending to vulnerabilities in Node.js and Ruby apps. Here, Tim Kadlec, Snyk’s head of developer relations, sees Node’s issues as similar to those of other open source platforms.

“Companies are pulling in code that [is] written by people that they don’t know and code that they are not familiar with,” says Kadlec, referring to NPM and Yarn JavaScript packages. RubyGems have a similar problem, he adds. “I would say that Node potentially has a little bit higher risk just because of the way JavaScript runs,” being event-driven, he says.

Vickery describes the NPM ecosystem as “huge and dead easy,” meaning the ease of publishing packages adds to package noise.

“Anyone can submit a trivial amount of usually untested code as an official package. As soon as it has a decent amount of downloads per day or stars on GitHub, it’s now been vetted and ready for production, apparently,” Vickery says. This leads to the rise and fall of heavily used packages at a ridiculous pace, he adds. “Our team found we often had to switch packages halfway through a project due to development stalling and issues being fixed in a new-and-improved package.”

Input Logic has not found Node to be successful for use in long-running tasks with a heavy amount of disk I/O. The company’s primary back-end services, APIs, and worker queues have been moved to Python.

But the Node.js Foundation is quick to defend Node, especially around security.

“The Node.js Project takes security very seriously,” foundation community manager Mikeal Rogers says. “Node.js has one of the most secure out-of-the-box SSL configurations, and we take pride in our security process. We were one of the first open source projects that went through and passed the Core Infrastructure Initiatives best-practices badges program from the Linux Foundation.”

Node has proved its ability to scale at organizations such as Walmart and Uber, Rogers says. It also can be used for CPU-intensive tasks, stresses David Mark Clements, a Node working group member and an architecture and performance consultant.

“In practice, Node.js performs well for CPU-intensive tasks, but when a bottleneck occurs there are thousands of C/C++ libraries that Node.js can connect with to perform at the best possible speed,” Clements says.

Moreover, Node.js fits cloud deployments nicely, he adds. “In an application, there is often a group of servers to handle the HTTP requests, and a group of servers to handle the CPU-intensive tasks. Both groups can scale automatically based on demand.”

Addressing NPM dependency issues, Node apps can total hundreds of dependencies, which Matteo Colina, Node Core collaborator and consultant, called a “great” thing.

“Node.js has an unprecedented level of code reuse through projects and throughout the whole ecosystem,” Colina says. “This is often one of the main reasons why people choose Node.js: It has a vast module ecosystem, so developers don’t have to continually reinvent the wheel. If we developers can reuse code, we can develop new projects quicker.”

That said, NPM suffered a calamity last year when the removal of a 17-line NPM module caused others to fail. Node services vendor NodeSource is working to curate modules to prevent situations like this.

Even Vickery gives Node a nod, albeit with reservations.

“Node can be superhelpful for some things, NPM build scripts come to mind, but I find most of the products we build quickly outgrow its other use cases,” he says.

Shan lauds the Node community. “The community has a hell lot of modules and packages, which makes development supereasy for the developers. Even beginners are being able to write very handsome code.”

Kadlec sees Node security getting better. “The awareness is improving and the tooling is improving.”

Copyright © 2017 IDG Communications, Inc.

How to choose a low-code development platform