Abstractions like Scala, Groovy, and Clojure were built on top of the Java Virtual Machine’s finely tuned bytecode processing power.
Virtual machine innovation is now happening atop V8.
V8-powered NodeJS apps compile directly to machine code at a speed that rivals the JVM’s compilation from bytecode to machine code.
What does Node.js have to do with Docker and microservices?
Not much. This question was an example of my vulnerability to hype vortices.
What are the tradeoffs between frameworks like Meteor.js, Express.js, and React.js?
Meteor is also extraordinarily fun and easy to work with. Remember how much fun you had when you used Rails for the first time? It’s like that, but better.
A tradeoff is that, as Mattias said, “Meteor is a bit full-stacky.” Adoption is hampered by the fact that one does not simply integrate Meteor into a preexisting microservice-based, RESTful stack. To build a simple, friendly RESTful JSON service in Meteor is to miss the point of Meteor.
But–there are plenty of other options for a friendly RESTful JSON service:
- LoopBack is an end-to-end API framework maintained by the same people as Express.js.
- restify is a RESTful API framework with built-in DTrace support, which simplifies debugging.
- Sails.js, Hapi.js, and many others are also available.
If a company has an established strategy for building and deploying microservices in Java or C#, how hard is it to add NodeJS apps to the ecosystem?
Another question rooted deep in the buzzword nexus of the Hype Vortex.
How do Node apps compare to Java apps in terms of size, speed, time-to-market, garbage collection, and maintenance?
These benchmarks are hard to measure.
- Size: Node apps are probably smaller in terms of program size itself, but more relevant is the memory footprint. Even still, that is hard to measure (unless you are haphazardly adding duplicate routes to an array).
- Speed: Benchmarks exist, but probably don’t make much sense beyond contrivance.
- Garbage collection: Without getting into the weeds, I couldn’t find anything conclusive about V8 being dramatically worse at garbage collection than the JVM–but its probably not better than the JVM. Building good garbage collection is a long war of attrition that every language has to fight, and JVM has had a lot more time to fight that war.
What is the relationship between Node.js and V8?
Going further requires looking into V8.**
What is the Node.js single-threaded event loop?
Any time something happens in a NodeJS application, an event is created.
New events are loaded onto the event queue. These events are processed serially. The event loop takes events from the head of the event queue one at a time and hands them off to the file system, network, or another process.
As those events are processed, they create more events. Those new events are placed at the back of the event queue, and the cycle continues.
Is a single-threaded event-based model preferable to a multithreaded model?
Yes. Humans should figure out more ways to behave serially. Multitasking is a myth. Single-threaded event programming is more comprehensible for programmers.
It’s not a stretch to extend this philosophy to how we think about programming models*.
But also no. A Node microservice may be processing each individual event serially, but different services are doing different things at once. In this sense, a Node programmer’s overall system is multithreaded.
Node’s single-threaded event loop is only a part of an overall application that is doing multiple things at once.
*opinion is the author’s own
**Anyone who has performed a comparative analysis between V8, SpiderMonkey, Rhino, and Nashorn, please leave a comment. I’d like to know more about how these differ.