Joyent, by way of the Joyent Private Cloud and Joyent Compute Service, has developed its own solutions to the issues with Node.js debugging. The most painful of those issues is memory consumption.
"Historically," says Bryan Cantrill, chief technology officer at Joyent, "we have little insight into how memory is used in dynamic environments."
To that end, Joyent included inside-out Node.js debugging support in its platform by leveraging the DTrace functionality of Joyent's Solaris-derived SmartOS, on which the platform is built. The bad news is that anyone who wants to use the same toolset needs to run SmartOS, either on their own or via Joyent's cloud. Cantrill didn't rule out the possibility the debugging technology could be ported to other platforms, but admitted it has a lot of dependencies on SmartOS that would need to be resolved.
Testing frameworks represent another area for possible improvement. Bowery, creator of a cloud development-environment system, built the first version of its service in Node.js, but eventually switched to Go for a variety of reasons. Among them was the fact some testing frameworks for Node.js "worked better for front end, like Jasmine, and others were better for the backend, like Mocha." With Go, they reasoned, testing is built-in and standardized across the board; Node.js could benefit from having a testing framework of similar robustness.
One fairly high-profile exit from the world of Node.js development was spurred by the existing limitations on debugging and developing Node.js applications. TJ Holowaychuk, creator of Koa, Express, and the Node.js-canvas project, penned an essay in June 2014 wherein he bid farewell, albeit fondly, to Node.js development and its environment that "favours performance over usability and robustness." Debugging and error handling, especially for callbacks -- one of Node.js's core behaviors --struck him as grossly underdeveloped.
To Holowaychuk, Node.js is a worthy and powerful project, but "performance means nothing if your application is frail, difficult to debug, refactor and develop." Holowaychuk expressed confidence that these problems could be overcome in time.
A fork and the future
In theory, an open source project like Node.js should develop by leaps and bounds, with problems like the ones outlined here attacked in short order. In practice, though, parts of Node.js haven't evolved as quickly as others. Aside from debugging and inspection, concerns about the pace of Node development have arisen, as evidenced in release cycle issues over the past year.
Sign up for CIO Asia eNewsletters.