Comments
PayPal Finds Node.js Secret To Successful Makeover
Newest First  |  Oldest First  |  Threaded View
rradina
50%
50%
rradina,
User Rank: Ninja
3/17/2014 | 11:03:16 PM
Is it really an advantage?
From the article:

"Whereas a Java process would suspend further operations until a database query had been answered, Node.js's non-blocking system continues to execute commands and get work done while the query is going on."

Java code is almost always executed in a web application container like JBoss, Tomcat, Weblogic or WebSphere.  Those servers have thread pools that service a configurable number of concurrent HTTP requests (based on the number of cores in your server, each core's speed and total server memory).  They also have connection pools that allow for a configurable number of concurrent DB operations (depending on the strength and type of queries issued to the DB server).

I understand the Node.js asynchronous architecture.  It uses callbacks when work is finished and that Javascript closures make this seemingly easy to code (depends on whether or not the developers are used to closures).  However, somewhere there's still a limit to throughput based on the number of concurrent asynchronous operations permitted and backed by the number of concurrent DB requests permitted (some kind of connection cache).  It cannot be a free-for-all.

When analyzed on a deeper level, this statement seems to be a six to one, half dozen to another subjective call.  Both environments allow more than one thing to happen at a time but they achieve it through different architectures.  I fail to see how or why an asynchronous callback that must end up processing the work via a pool of synchronous threads, is any more efficient than having an up-front thread pool of synchronous threads.

I also fail so see why one architecture would be more efficient than the other.  In fact, the asynchronous programming model looks hideous and even the article mentioned it's a pain to debug.  The up-front thread pool model where each thread blocks on synchronous, relatively long-running requests seems more straightforward to program and for the life of me, I'm not sure why anyone would hail the asynchronous architecture as an advantage.

That said, I cannot disagree that it would be absolutely fabulous to change code and see instant results.  When I first started writing web pages in 1996 with Microsoft's Active Server Pages, it had a fast-turn-around programming model.  While still a shock to those familiar with stateful, event-driven fat-client GUIs (but like a warm blanket to those used to CICS), there were no long build times and changes were instant.  Save the file, hit the site.  However, the larger an ASP application became, the more disgusting and impossible it was to maintain.  There were no internationalization features or built-in support to organize code.  Server-side includes would only go so far.  While Javascript is much nicer than VBScript (it was really limited), it would seem Node.js would also run into similar problems.

While developers can make a mess with anything, it seems Node.js is returning to where the web began and we evolved from that to more complex architectures.  Maybe we went too far (I often think that) but what does Node.js offer that makes it a "back to the future" alternative?

 
Charlie Babcock
50%
50%
Charlie Babcock,
User Rank: Author
3/17/2014 | 1:33:50 PM
A line from his first review?
I didn't get a chance to ask. Bill Scott once had a consulting company, LooksGoodWorksWell. And his blog still appears under that name. Is this a line from his first review as a programmer? You can see the irony, if it is.


IT's Reputation: What the Data Says
IT's Reputation: What the Data Says
InformationWeek's IT Perception Survey seeks to quantify how IT thinks it's doing versus how the business really views IT's performance in delivering services - and, more important, powering innovation. Our results suggest IT leaders should worry less about whether they're getting enough resources and more about the relationships they have with business unit peers.
Register for InformationWeek Newsletters
White Papers
Current Issue
InformationWeek Government Oct. 20, 2014
Energy and weather agencies are busting long-held barriers to analyzing big data. Can the feds now get other government agencies into the movement?
Video
Slideshows
Twitter Feed
InformationWeek Radio
Archived InformationWeek Radio
A roundup of the top stories and trends on InformationWeek.com
Sponsored Live Streaming Video
Everything You've Been Told About Mobility Is Wrong
Attend this video symposium with Sean Wisdom, Global Director of Mobility Solutions, and learn about how you can harness powerful new products to mobilize your business potential.