JavaScript’s rising popularity has brought with it a lot of changes, and the face of web development today is dramatically different. The things that we can do on the web nowadays with JavaScript running on the server, as well as in the browser, were hard to imagine just several years ago, or were encapsulated within sandboxed environments like Flash or Java Applets.

Before digging into Node.js, you might want to read up on the benefits of using JavaScript across the stack which unifies the language and data format (JSON), allowing you to optimally reuse developer resources. As this is more a benefit of JavaScript than Node.js specifically, we won’t discuss it much here. But it’s a key advantage to incorporating Node in your stack.

As Wikipedia states: “Node.js is a packaged compilation of Google’s V8 JavaScript engine, the libuv platform abstraction layer, and a core library, which is itself primarily written in JavaScript.” Beyond that, it’s worth noting that Ryan Dahl, the creator of Node.js, was aiming to create real-time websites with push capability, “inspired by applications like Gmail”. In Node.js, he gave developers a tool for working in the non-blocking, event-driven I/O paradigm.

After over 20 years of stateless-web based on the stateless request-response paradigm, we finally have web applications with real-time, two-way connections.

In one sentence: Node.js shines in real-time web applications employing push technology over websockets. What is so revolutionary about that? Well, after over 20 years of stateless-web based on the stateless request-response paradigm, we finally have web applications with real-time, two-way connections, where both the client and server can initiate communication, allowing them to exchange data freely. This is in stark contrast to the typical web response paradigm, where the client always initiates communication. Additionally, it’s all based on the open web stack (HTML, CSS and JS) running over the standard port 80.

One might argue that we’ve had this for years in the form of Flash and Java Applets—but in reality, those were just sandboxed environments using the web as a transport protocol to be delivered to the client. Plus, they were run in isolation and often operated over non-standard ports, which may have required extra permissions and such.

With all of its advantages, Node.js now plays a critical role in the technology stack of many high-profile companies who depend on its unique benefits.

In this post, I’ll discuss not only how these advantages are accomplished, but also why you might want to use Node.js—and why not—using some of the classic web application models as examples.

How Does It Work?

The main idea of Node.js: use non-blocking, event-driven I/O to remain lightweight and efficient in the face of data-intensive real-time applications that run across distributed devices.

That’s a mouthful.

What it really means is that Node.js is not a silver-bullet new platform that will dominate the web development world. Instead, it’s a platform that fills a particular need.

What it really means is that Node.js is not a silver-bullet new platform that will dominate the web development world. Instead, it’s a platform that fills a particular need. And understanding this is absolutely essential. You definitely don’t want to use Node.js for CPU-intensive operations; in fact, using it for heavy computation will annul nearly all of its advantages. Where Node really shines is in building fast, scalable network applications, as it’s capable of handling a huge number of simultaneous connections with high throughput, which equates to high scalability.

How it works under-the-hood is pretty interesting. Compared to traditional web-serving techniques where each connection (request) spawns a new thread, taking up system RAM and eventually maxing-out at the amount of RAM available, Node.js operates on a single-thread, using non-blocking I/O calls, allowing it to support tens of thousands of concurrent connections (held in the event loop).

Diagram of traditional vs. Node.js server thread

A quick calculation: assuming that each thread potentially has an accompanying 2 MB of memory with it, running on a system with 8 GB of RAM puts us at a theoretical maximum of 4000 concurrent connections, plus the cost of context-switching between threads. That’s the scenario you typically deal with in traditional web-serving techniques. By avoiding all that, Node.js achieves scalability levels of over 1M concurrent connections (as a proof-of-concept).

There is, of course, the question of sharing a single thread between all clients requests, and it is a potential pitfall of writing Node.js applications. Firstly, heavy computation could choke up Node’s single thread and cause problems for all clients (more on this later) as incoming requests would be blocked until said computation was completed. Secondly, developers need to be really careful not to allow an exception bubbling up to the core (topmost) Node.js event loop, which will cause the Node.js instance to terminate (effectively crashing the program).

The technique used to avoid exceptions bubbling up to the surface is passing errors back to the caller as callback parameters (instead of throwing them, like in other environments). Even if some unhandled exception manages to bubble up, there are mutiple paradigms and tools available to monitor the Node process and perform the necessary recovery of a crashed instance (although you won’t be able to recover users’ sessions), the most common being the Forever module, or a different approach with external system tools upstart and monit.

NPM: The Node Package Manager

When discussing Node.js, one thing that definitely should not be omitted is built-in support for package management using the NPM tool that comes by default with every Node.js installation. The idea of NPM modules is quite similar to that of Ruby Gems: a set of publicly available, reusable components, available through easy installation via an online repository, with version and dependency management.

A full list of packaged modules can be found on the NPM website , or accessed using the NPM CLI tool that automatically gets installed with Node.js. The module ecosystem is open to all, and anyone can publish their own module that will be listed in the NPM repository. A brief introduction to NPM (a bit old, but still valid) can be found at

Some of the most popular NPM modules today are:

  • express - Express.js, a Sinatra-inspired web development framework for Node.js, and the de-facto standard for the majority of Node.js applications out there today.
  • connect - Connect is an extensible HTTP server framework for Node.js, providing a collection of high performance “plugins” known as middleware; serves as a base foundation for Express.
  • and sockjs - Server-side component of the two most common websockets components out there today.
  • Jade - One of the popular templating engines, inspired by HAML, a default in Express.js.
  • mongo and mongojs - MongoDB wrappers to provide the API for MongoDB object databases in Node.js.
  • redis - Redis client library.
  • coffee-script - CoffeeScript compiler that allows developers to write their Node.js programs using Coffee.
  • underscore (lodash, lazy) - The most popular utility library in JavaScript, packaged to be used with Node.js, as well as its two counterparts, which promise better performance by taking a slightly different implementation approach.
  • forever - Probably the most common utility for ensuring that a given node script runs continuously. Keeps your Node.js process up in production in the face of any unexpected failures.

The list goes on. There are tons of really useful packages out there, available to all (no offense to those that I’ve omitted here).

Examples of Where Node.js Should Be Used


Chat is the most typical real-time, multi-user application. From IRC (back in the day), through many proprietary and open protocols running on non-standard ports, to the ability to implement everything today in Node.js with websockets running over the standard port 80.

The chat application is really the sweet-spot example for Node.js: it’s a lightweight, high traffic, data-intensive (but low processing/computation) application that runs across distributed devices. It’s also a great use-case for learning too, as it’s simple, yet it covers most of the paradigms you’ll ever use in a typical Node.js application.

Let’s try to depict how it works.

In the simplest example, we have a single chatroom on our website where people come and can exchange messages in one-to-many (actually all) fashion. For instance, say we have three people on the website all connected to our message board.

On the server-side, we have a simple Express.js application which implements two things: 1) a GET ‘/’ request handler which serves the webpage containing both a message board and a ‘Send’ button to initialize new message input, and 2) a websockets server that listens for new messages emitted by websocket clients.

On the client-side, we have an HTML page with a couple of handlers set up, one for the ‘Send’ button click event, which picks up the input message and sends it down the websocket, and another that listens for new incoming messages on the websockets client (i.e., messages sent by other users, which the server now wants the client to display).

When one of the clients posts a message, here’s what happens:

  1. Browser catches the ‘Send’ button click through a JavaScript handler, picks up the value from the input field (i.e., the message text), and emits a websocket message using the websocket client connected to our server (initialized on web page initialization).
  2. Server-side component of the websocket connection receives the message and forwards it to all other connected clients using the broadcast method.
  3. All clients receive the new message as a push message via a websockets client-side component running within the web page. They then pick up the message content and update the web page in-place by appending the new message to the board.

Diagram of client and server websockets in a Node.js application

This is the simplest example. For a more robust solution, you might use a simple cache based on the Redis store. Or in an even more advanced solution, a message queue to handle the routing of messages to clients and a more robust delivery mechanism which may cover for temporary connection losses or storing messages for registered clients while they’re offline. But regardless of the improvements that you make, Node.js will still be operating under the same basic principles: reacting to events, handling many concurrent connections, and maintaining fluidity in the user experience.


Although Node.js really shines with real-time applications, it’s quite a natural fit for exposing the data from object DBs (e.g. MongoDB). JSON stored data allow Node.js to function without the impedance mismatch and data conversion.

For instance, if you’re using Rails, you would convert from JSON to binary models, then expose them back as JSON over the HTTP when the data is consumed by Backbone.js, Angular.js, etc., or even plain jQuery AJAX calls. With Node.js, you can simply expose your JSON objects with a REST API for the client to consume. Additionally, you don’t need to worry about converting between JSON and whatever else when reading or writing from your database (if you’re using MongoDB). In sum, you can avoid the need for multiple conversions by using a uniform data serialization format across the client, server, and database.


If you’re receiving a high amount of concurrent data, your database can become a bottleneck. As depicted above, Node.js can easily handle the concurrent connections themselves. But because database access is a blocking operation (in this case), we run into trouble. The solution is to acknowledge the client’s behavior before the data is truly written to the database.

With that approach, the system maintains its responsiveness under a heavy load, which is particularly useful when the client doesn’t need firm confirmation of a the successful data write. Typical examples include: the logging or writing of user-tracking data, processed in batches and not used until a later time; as well as operations that don’t need to be reflected instantly (like updating a ‘Likes’ count on Facebook) where eventual consistency (so often used in NoSQL world) is acceptable.

Data gets queued through some kind of caching or message queuing infrastructure (e.g., RabbitMQ, ZeroMQ) and digested by a separate database batch-write process, or computation intensive processing backend services, written in a better performing platform for such tasks. Similar behavior can be implemented with other languages/frameworks, but not on the same hardware, with the same high, maintained throughput.

Diagram of a database batch-write in Node.js with message queuing

In short: with Node, you can push the database writes off to the side and deal with them later, proceeding as if they succeeded.


In more traditional web platforms, HTTP requests and responses are treated like isolated event; in fact, they’re actually streams. This observation can be utilized in Node.js to build some cool features. For example, it’s possible to process files while they’re still being uploaded, as the data comes in through a stream and we can process it in an online fashion. This could be done for real-time audio or video encoding, and proxying between different data sources (see next section).


Node.js is easily employed as a server-side proxy where it can handle a large amount of simultaneous connections in a non-blocking manner. It’s especially useful for proxying different services with different response times, or collecting data from multiple source points.

An example: consider a server-side application communicating with third-party resources, pulling in data from different sources, or storing assets like images and videos to third-party cloud services.

Although dedicated proxy servers do exist, using Node instead might be helpful if your proxying infrastructure is non-existent or if you need a solution for local development. By this, I mean that you could build a client-side app with a Node.js development server for assets and proxying/stubbing API requests, while in production you’d handle such interactions with a dedicated proxy service (nginx, HAProxy, etc.).


Let’s get back to the application level. Another example where desktop software dominates, but could be easily replaced with a real-time web solution is brokers’ trading software, used to track stocks prices, perform calculations/technical analysis, and create graphs/charts.

Switching to a real-time web-based solution would allow brokers to easily switch workstations or working places. Soon, we might start seeing them on the beach in Florida.. or Ibiza.. or Bali.


Another common use-case in which Node-with-web-sockets fits perfectly: tracking website visitors and visualizing their interactions in real-time. (If you’re interested, this idea is already being productized by Hummingbird.)

You could be gathering real-time stats from your user, or even moving it to the next level by introducing targeted interactions with your visitors by opening a communication channel when they reach a specific point in your funnel. (If you’re interested, this idea is already being productized by CANDDi.)

Imagine how you could improve your business if you knew what your visitors were doing in real-time—if you could visualize their interactions. With the real-time, two-way sockets of Node.js, now you can.


Now, let’s visit the infrastructure side of things. Imagine, for example, an SaaS provider that wants to offer its users a service-monitoring page (e.g., GitHub’s status page). With the Node.js event-loop, we can create a powerful web-based dashboard that checks the services’ statuses in an asynchronous manner and pushes data to clients using websockets.

Both internal (intra-company) and public services’ statuses can be reported live and in real-time using this technology. Push that idea a little further and try to imagine a Network Operations Center (NOC) monitoring applications in a telecommunications operator, cloud/network/hosting provider, or some financial institution, all run on the open web stack backed by Node.js and websockets instead of Java and/or Java Applets.

Note: Don't try to build hard real-time systems in Node (i.e., systems requiring consistent response times). Erlang is probably a better choice for that class of application.

Where Node.js Can Be Used


Node.js with Express.js can also be used to create classic web applications on the server-side. However, while possible, this request-response paradigm in which Node.js would be carrying around rendered HTML is not the most typical use-case. There are arguments to be made for and against this approach. Here are some facts to consider:


  • If your application doesn’t have any CPU intensive computation, you can build it in Javascript top-to-bottom, even down to the database level if you use JSON storage Object DB like MongoDB. This eases development (including hiring) significantly.
  • Crawlers receive a fully-rendered HTML response, which is far more SEO-friendly than, say, a Single Page Application or a websockets app run on top of Node.js.


  • Any CPU intensive computation will block Node.js responsiveness, so a threaded platform is a better approach. Alternatively, you could try scaling out the computation [*].
  • Using Node.js with a relational database is still quite a pain (see below for more detail). Do yourself a favour and pick up any other environment like Rails, Django, or ASP.Net MVC if you’re trying to perform relational operations.
[*] An alternative to these CPU intensive computations is to create a highly scalable MQ-backed environment with back-end processing to keep Node as a front-facing ‘clerk’ to handle client requests asynchronously.

Where Node.js Shouldn’t Be Used


Comparing Node.js with Express.js against Ruby on Rails, for example, there is a clean decision in favour of the latter when it comes to relational data access.

Relational DB tools for Node.js are still in their early stages; they’re rather immature and not as pleasant to work with. On the other hand, Rails automagically provides data access setup right out of the box together with DB schema migrations support tools and other Gems (pun intended). Rails and its peer frameworks have mature and proven Active Record or Data Mapper data access layer implementations, which you’ll sorely miss if you try to replicate them in pure JavaScript.[*]

Still, if you’re really inclined to remain JS all-the-way (and ready to pull out some of your hair), keep an eye on Sequelize and Node ORM2—both are still immature, but they may eventually catch up.

[*] It’s possible and not uncommon to use Node solely as a front-end, while keeping your Rails back-end and its easy-access to a relational DB.


When it comes to heavy computation, Node.js is not the best platform around. No, you definitely don’t want to build a Fibonacci computation server in Node.js. In general, any CPU intensive operation annuls all the throughput benefits Node offers with its event-driven, non-blocking I/O model because any incoming requests will be blocked while the thread is occupied with your number-crunching.

As stated previously, Node.js is single-threaded and uses only a single CPU core. When it comes to adding concurrency on a multi-core server, there is some work being done by the Node core team in the form of a cluster module [ref:]. You can also run several Node.js server instances pretty easily behind a reverse proxy via nginx.

With clustering, you should still offload all heavy computation to background processes written in a more appropriate environment for that, and having them communicate via a message queue server like RabbitMQ.

Even though your background processing might be run on the same server initially, such an approach has the potential for very high scalability. Those background processing services could be easily distributed out to separate worker servers without the need to configure the loads of front-facing web servers.

Of course, you’d use the same approach on other platforms too, but with Node.js you get that high reqs/sec throughput we’ve talked about, as each request is a small task handled very quickly and efficiently.


We’ve discussed Node.js from theory to practice, beginning with its goals and ambitions, and ending with its sweet spots and pitfalls. When people run into problems with Node, it almost always boils down to the fact that blocking operations are the root of all evil—99% of Node misuses come as a direct consequence.

In Node, blocking operations are the root of all evil—99% of Node misuses come as a direct consequence.

Remember: Node.js was never created to solve the compute scaling problem. It was created to solve the I/O scaling problem, which it does really well.

Why use Node.js? If your use case does not contain CPU intensive operations nor access any blocking resources, you can exploit the benefits of Node.js and enjoy fast and scalable network applications. Welcome to the real-time web.

About the author

Tomislav Capan, Croatia
member since February 12, 2013
Tomislav is a software engineer, technical consultant and architect with over 10 years of experience. He specializes in full-stack, highly scalable, real-time JavaScript and Node.js applications, with past experience in C#, Java, and Ruby. He is an agile Kanban practitioner who loves to collaborate on development projects. [click to continue...]
Hiring? Meet the Top 10 Node.js Developers for Hire in March 2015


Anony Mouse
For relational DBs on Node, I like
Adin Scannell
Awesome article! I definitely agree that node.js has some really perfectly suited use cases. However, I do want to comment on something that is a bit of a pet peeve of mine -- I wish you wouldn't contrast it with a non-existent straw-man "traditional" system in "how it works". 1) No server spawns a thread per request (they use thread pools or process pools). 2) You say "cost of context switching" as if it only applies to OS threads. Userspace frames need to be saved and loaded in the same way. Plus the OS does it with a few instructions, leveraging specialized support from the hardware -- which userspace can't do. 3) Similarly, userspace threads (I.e. frames or closures if you don't want to talk threads) take memory resources in the same way kernel threads do. It's not as if each system thread has it's full stack limit allocated, so that's an unfair analysis. Normal systems regularly have more than 4000 without coming anywhere near where you've pegged it. 4) The BIG problem with single-thread concurrency is the lack of parallelism. Sure, you can handle thousands of requests per second, but only one CPU on your 40 core server is going to doing ANY work. Anyways, all the above is in regard to a pretty minor paragraph in your excellent post. Node isn't really guilty of this, it's just that there's a lot of FUD out there around threads and processes which people often use to justify insane designs (and avoid threads when they are completely the right approach for the majority of situations).
Eric Elliott
All your advice about computation heavy apps could not be more wrong. It's certainly true that attempting heavy computation inline with the request-response cycle, is a bad idea, but the same could be said of threaded environments. If you have CPU bound operations, it's a good idea to handle them with worker processes. JavaScript, and Node in particular are actually very well suited to handle distributed computation - especially with the good support for functional style programming. If you write your algorithms using pure functions and distribute workload to workers, you can easily distribute your workload over networked clusters. Node's great support for networking makes it an ideal environment both for computing and orchestration tasks, and it's orders of magnitude faster than Ruby at both.
jim thomas
Very helpful. Thanks a lot!
You certainly don't want to block any Node.js process that is handling server requests, but that doesn't mean you shouldn't do heavy computations behind a Node.js server. So long as the process doing the heavy computations is spawned asynchronously from your server process. Still you could end up blocking your Node.js process if you overdue it, but that is also true with the traditional threaded server.
Danny Machal
This is going to make me out to be a giant noob but can you give me an example of a "blocking operation" ?
Irné Barnard
Any such hybrid system? I'm thinking: Use Node.js to process a request by simply placing it onto a to-process queue, return a message to the client stating something like "calculating...". Then Node.js is free to continue with the next request. The to-process queue can then be run through using a difference thread (or even multiple threads). As and when these complete, they send their results to Node.js's queue which will then relay it back to the original client? Of course this means some ID key needs to accompany each item in this queue to ensure the correct data is returned to the correct client. Anything like this possible? Or even already implemented?
Great article, thanks :)
Gerd Jungbluth
Tomislav, thanks for this very well written and concise article!!! We 've been using MongoDB and Node.js (in combination with AngularJS for the user facing part) for > 2 years now and couldn't imagine to ever, ever, ever switch back to Flash (after 10 years of experience) or JEE / RDMS. So it boils down to just one programming language (JS), one data format (JSON) and one programming paradigma (Async), wow.
That's by far the best explanation out there about Node.js. I finally understood that it is very useful (in certain scenarios) and not just a hype. Thanks a lot this was very informative!
Node works well with relational databases, just don't use an ORM. SQL isn't that hard to learn. =)
Tomislav Capan
True that, but I thought we as an industry got over the idea of writing all the SQL manually. Tools are good for common operations, tools that just get out of the way when needed to write some specifics manually, otherwise reducing the possibility of errors and security issues (that happens with more junior developers whether we want it or not).
Tomislav Capan
Hi Adin, let me comment back 1) same scenario happens, there's a limitid amount of threads serving limited amount of clients. 2/3) Referenced presentation shows some measurements and numbers, you may be quite right on the internals but the common rough overview still stands as a general comparison of how things work between those two worlds. 4) parallelization options are also discussed within the article - as background worker processes, or several node processes behind a reverse proxy, or with Node clustering API (which is still in Experimental, but will be there eventually). Thanks for the great comments and the quality feedback on the article with that additional info, I appreciate it.
Tomislav Capan
Yes, you can have multiple worker processes, even communicating through Message Queue (MQ). Those workers can be separate Node processes (as node is single-threaded, unless you experiment with clustering API - I haven't tried yet as the API is very early and probably immmature), but can be any other language. I've worked on such a system which ran C# on Mono for background processing in a distributed CQRS architecture.
Tomislav Capan
Any calculation that keeps the CPU busy until the calculation is finished. Imagine some operation that requires 2 seconds to perform the calculation. Hit that with 100 clients - you get a 200-sec delay. Note the article I have referenced, which explains the blocking of the event loop:
Tomislav Capan
Yes, that falls under the idea of having 'backend worker processes' in a distributed system. As the system is distributed, those workers can use any language/platform, including Node.
Tomislav Capan
Thanks for your feedback. I agree on that completely, for worker processes you could use JS when it fits, and that implies Node.js as that's what runs JS on the server, but you can also use other languages that do the particular work at hand fast.
For ORMs in general, I just see them as a tool that can get something done quick for a newbie, but end up really gumming up the works later on. The closest thing I use for an ORM is a PDO wrapper (which I borrowed and rewrote from an old co-worker), that helps with writing PDO statements.
Adin Scannell
Apologies for the wall of text. Excellent discussion! 1) Agreed. But threads and processes are powerful tools. That's why a hybrid of threads/processes and event systems typically does best in the real world. Like the much beloved nginx :) 2/3) Sorry, I may not have been clear. When I said FUD regarding threads and processes, I *meant the referenced presentation*. It's just a bunch of specifically tailored microbenchmarks designed to prove a certain point. (Which is fair, given that it's a lightning fair and can be a bit polemic. In fact, it's a great talk. But these synthetic micro-benchmarks are not the basis for a fair and through comparison.) To say the difference between nginx and apache benchmarks is purely because of context switching is an extreme oversimplification. Nginx is specifically designed to serve HTTP requests really, really quickly in common circumstances (IMO generally by a tight coupling with the latest OS event systems, etc.). You could specifically measure the overhead of context switching, and I would wager it's trivial. 4) But then aren't you at the mercy of the horrible "process overhead" the referenced presentation talks about -- can't have it both ways :) (To be clear, my position using threads/processes or whatever is not in and of itself a problem. There are way more important design factors there, the OS overhead of those entities is pretty trivial. Hence I hate it when people adopt a silly design based on the idea thread-are-bad or processes-are-bad or some other such nonesense).
Tomislav Capan
Everything always needs to be put in the right context. I have presented possible situations, to analyze each one deeply I'd need a book :-) Still, I really appreciate your comments and insights, they are valuable addition to the article. Thank you for those.
Aaron Wang
When use node.js as api server, and the back-end db is the bottleneck, if the clients are the other applications, not user interface, can we just let these client requests hang there waiting for db operation complete(sine node.js can handle massive concurrent connections easily)? Is a MQ necessary in this scenario? In my opinion, node.js is right the queue.
ORM does not exist to make query languages "easier", it's a tool used to encapsulate database concerns, isolating them from the application. There are several benefits, but ultimately, it makes applications easier to test and maintain years down the road. Excuse the tangent, nothing to do with node.
Eric Elliott
Yes, you could, but Ruby would be a poor choice if your aim is performance. =)
thank you for a great article. By using the node.js child process - would you be able to overcome the high computational blocking Fibonacci issue?
nene odonkor
any real life examples?
nene odonkor
What of the Facebook example you used. When a user clicks on the like button there is an immediate acknowledgement but the data is written later. Cant that be an example of node used with relational db? Anyway what makes up the message queue?
Moch Lutfi
Maybe go-lang is alternative choice. :)
Anthony Hildoer
This article is great, except for the part where it says don't use NodeJS for computation because it doesn't have threads. Since when do we need threads? Run child processes. The only advantage to running threads over child processes is shared memory. Last time I checked, any system large enough for this entire debate to be relevant anyway is going to span multiple servers anyway, their by nullifying any benefit of threads. So, get it out of your head that NodeJS can't do CPU intensive work. And, if you can't, contact, and we can fix all the stuff you built wrong with NodeJS.
One application that few people use, but could be really fanastic, is using NodeJS to build a desktop application. There's plenty of packages out there - personally, I favour Node-Webkit
Hi, nice article. However I would like to point one thing, NodeJS is not running in a single thread. The programmer doesn't have to spawn new threads, they are handled by node itself on event basis. NodeJS is evented, each function call per event will run in a separate thread. That approach encourages writing lighter functions. If your function does a lot of computation, reactor it into smaller ones and they all will run in separate threads. Think about the example where you process file while streaming. That is possible thanks to threads.
Juanchi Viotti
Great article! BTW, what software did you use to make the images/wireframes?
Matthew Keas
This is very well written. Thank you for this!
Matti Schneider
> The technique used to avoid exceptions bubbling up to the surface is passing errors back to the caller as callback parameters Excuse me, but that seems misled. In my understanding, [“Node-style callbacks”]( (i.e. the pattern of passing errors as the first param to callbacks) are a side-effect of the event queue (returning control as soon as possible to allow for “concurrency”) itself rather than a design to avoid interrupting flow. The fact that exceptions do not bubble are actually quite often a source of errors, especially to newcomers.
Great Article. Wondering who made the beautiful diagrams :)
Great article, thanks :) BTW, which tool do you use to draw the images?
Matthew Keas
+1 for that
Matthew Keas
For those that are curious, it seems the images were created with Adobe Photoshop CC. I checked this by looking at the EXIF data of one of the images: File Size – 61 kB File Type – PNG MIME Type – image/png Image Width – 624 Image Height – 600 X Resolution – 72 Y Resolution – 72 Color Space – sRGB Color Mode – 3 Compression – Deflate/Inflate Orientation – Horizontal (normal) XMP Toolkit – Adobe XMP Core 5.5-c014 79.151481, 2013/03/13-12:09:15 Creator Tool – Adobe Photoshop CC (Macintosh)
Juan G. Nuño
Also, the fact that javascript is not able to check type compliance introduces dificulty in expontaneous organization of huge number of coders updating the same codebase simultaneously.
Juan G. Nuño
mmmm... disagree, if you use correctly a good ORM (take a look at Mature ORMs) you get also a distributed cache of your Relational Database that allows you more performance for the same bucks and more scalability of your sistem... ORM is not just for easing the life to newies... It is non sense to use a non-blockin sistem such as node.js, if at the end you get blocked at your Database. But using a ORM that way, is not for newbies.
Glad you mention, most people don't mention this.
Richard Ayotte
I'd rather keep Node decoupled from the browser and keep the flexibility of running the frontend on platforms that normally don't run Node like smartphones.
For that matter, since you can do an async shell to a console application, you could easily write your worker in, for instance golang, and then use a generic pool to limit your cpu workers... from there, you can shell out to a more efficient worker. You can also do that for CPU intensive JS as well, I did this for my scrypt-js module (there are binary modules that are more performant, but I wanted one without compiled dependencies). It's not that hard to queue work to other systems, and no reason node can't be used to orchestrate said work.
Could *could* use an intermediate system such as TypeScript, you can also use a linter (jshint) and even require a level of test coverage in order for release. Getting 100% test coverage is generally *very* easy in scripted environments. Would suggest looking into Mocha, Chai, and Proxyquire. If you aren't writing unit tests, type safety really doesn't give you much.
Steve Naidamast
I am beginning to find Node.js quite interesting. However, the paradigm it appears to be promoting is hardly new to IT. In the mainframe communications world we called such capabilities, "re-entrant", where a single process could handle a high level of calls to it. Microsoft implemented similar capabilities with its Singleton object infrastructure and I imagine the Java world has done similar implementations. Oddly enough, the Microsoft recommendation for enhancing scalability across the wires to back-end services was to promote the "Single Call" object structure or one object instance per calling request. Thus, the argument made for Node.js is actually contrary to the Microsoft recommendation; BTW, a recommendation I never quite understood. In any event, as a business ASP.NET developer, I am not sure if I would find any use for a Node.js implementation, though our web designer may. On another note, I would like to add my own opinion on the use of ORMs. ORMs are great tools when faced with an existing database structure against the requirements of a new application as the ORM can handle a lot of the mundane, repetitive coding that is usually found with any database application. However, because ORMs are high-level layers, they are usually not the most efficient options to use against databases whereas direct access through native providers are. In many respects, better to do the repetitive coding for efficiency over applying a heavy-weight interim layer such as an ORM...
Very interesting observation. I'd like someone to elaborate a bit more on that. I would like a more concrete example, like some piece of concrete code calling an async heavy-computational function, and someone explaining what happens if that is run in a multicore equipment. Does the thread that was sercing http requests gets blocked? Or another thread is used for that?
Derrick Simpson
Node is terrible as a web server. Even the creator suggests that this is not what Node is intended for, and that it should be leveraged for it's strengths. JavaScript "Everything", just like worker processes, is ludicrous.
Eric Elliott
This is ridiculous. Node was built with the web as first class, and it excels as a web server. It is rapidly replacing Ruby and PHP in many enterprise organizations because it has demonstrably boosted both application performance (reduced page-load times, etc...) and developer productivity.
You can in fact create multi-threaded servers using Node.js to offer more stable performance but it does take a lot of extra work (see the built-in cluster module and the child_process module). I have created a framework which runs on multiple CPU cores and solves much of the issues discussed in this post. Check it out:
Connor James Leech
does something like mongoose.js solve the node relational database issue?
Rob Tweed
Yes - see the queue/pre-forked worker pool approach adopted by EWD.js: Summarised here:
keith lumanog
yeah, I was wondering about it too. great visual + awesome post.
Erick Ruiz de Chavez
Just to complement what @Tracker1:disqus said on his comment, JavaScript is usually criticized about the type checking (and many other misunderstood features, like "this"), but the truth is that JavaScript is just very different to what most of the developers are used to do, and most of the developers who sadly have bad comments about it are just those who haven't had the interest or the time to understand how it really works. JavaScript development is not only about the language itself but also about the tools you use to work with it, to mention some more you should really take a look at Grunt, Uglify, Yeoman, CoffeScript, etc.
Erick Ruiz de Chavez
I might as well make myself a giant noob, but to put a quick example, any disk I/O operation is considered a blocking operation as it has to perform a physical operation to read some data from the disk. Another blocking operation example is querying a DB, where you basically have to wait for the response before doing anything else. I'd say, any sort of computational operation will be as blocking as the time it takes to complete. In any of the above examples, you usually have your blocking request on line A and line B wont be executed until line A is completed. Node.js instead is asynchronous, so line A is requested and then queued, and line B is executed no matter if line A is completed or not; when line A is complete, you are notified either with a callback or with an event and then you can continue doing whatever you need to do with such result.
Carlos Ballena
Very helpful article!
Jesus Nuñez
npm install felixge/node-mysql. That might be the most useful repository I've seen in ages.
Erick Ruiz de Chavez
I have a small example of mysql and node.js at
How about: "Why the hell would I read an article without an obvious date and time stamp?"
Matthias Lienau
Nice article, indeed. But, @hfuti:disqus, you're wrong in saying "NodeJS is not running in a single thread ... each function call per event will run in a separate thread." As far as I understood, the main NodeJS event loop consuming your JS code in fact runs in a single thread. All potentially blocking and/or long-running tasks like disk I/O is delegated to and executed by libuv as part of the node runtime engine which spawns a *limited* number of threads made available as thread pool. Said this, it's obvious that the main event loop thread is not affected or blocked by other (yet again asynchronous) code execution. So, for example, file I/O with the fs module itself is implemented in a non-blocking manner - in the end as good as the OS/kernel allows non-blocking operations. Of course foreign processes or threads could always be spawned by custom modules or 3rd party services (worker processes). And yes, there are runtime env projects handling more than one node process and their threads on the same machine or cpu cluster. But that's another story. Feel free to correct me if I'm wrong!
This is fantastic.
Jacopo Chiapparino
Nice article, thank you!
I think Django still kicks Node's ass.
Hey Tomislav, I'd love if you could add the above post to the list :)
Victor Lava
Omg, this is amazing.. I have always wanted to learn node.js!
Thanks for providing examples, illustrations and use cases. The detailed explanation and steps in some cases with relevant resources makes it a great read. Where nodejs *should* be used is very useful.
All Node code is thread-bound. It may not run on the same thread at all times (which has nothing to do with Node itself, and instead has to do with the operating system process scheduler), but it is thread bound. In order to take advantage of multiple threads, you need to use something like Cluster:
Agreed! I use Postgres for all sorts of GIS operations in an application I've been working on for about a year, and it works great, and benefits from the same non-blocking I/O that any other database access does. It's just that you have to drop down directly to the SQL. There are a couple ORMs, but nothing that is real mature.
Awesome, thanks a lot for this!
Minor comment: don't confuse Object DBs with Mongo (Document DB). There are 2 completely different things.
i agree, good post.
yes, i agree
Very well written article. You put a lot of thought into it. Quick node/express question I am I am adding rapid data entry, not batch, data entry to my system I have a form (mfntapes) that works great. I have a test form (joe) the prompts for the number of times I want to call the mfntapes form The gist contains the code, fails to work, the after prompting for cnt attempts to call for mfntapes cnt times. The question is how to call form mfntapes x number of times where x is a vairable? See lines 45-55 of
Jesus Bejarano
ORM for real projects are useless hone.
Oncle Tom
Nice article :-) > SERVER-SIDE WEB APPLICATION W/ A RELATIONAL DB BEHIND I wonder why Node is not good for that? You have promise based *SQL libraries (like Knex) which enables non-blocking queries. Node has no opposition with relational databases: it has no interest with blocking I/O drivers only. Relational or not relational.
I wish NodeJS was not (almost) systematicallty presented as THE de facto alternative to the traditional threaded webserver. Async IO is not exclusive to NodeJS! Most major languages out there - including Java and PHP - have async IO frameworks similar to NodeJS. This wiki page lists most of them: I'm not saying NodeJS doesn't have its merit, but I'm sick and tired of seeing people flocking to it as if it's the *only* async IO stack available, and the *only* alternative to the good ol' PHP or Rails stack. To be honest, we may be stuck with Javascript on the browser, and will be for a very long time (except if Javascript becomes just another target platform/language thanks to asm.js), but I can't come up with any good reason to use it on the server side in favor to other available languages. Most of the alternatives are just way better as a language, have better standard libraries, tools and resources. Please stop spreading Javascript on the server, it's creepy :p
Jarle Leopold Moe
How would you upload files? What about Directory integration? (Active Directory, Open Directory) What about communication with external services? All request depending on a response from any of these types of services would block the calls... Node.js is _single-threaded_ it's only applicable for certain types of tasks.
Eric Elliott
These re great examples of why Node is so much better than the competition at web services. None of thee are blocking operations in Node. They're asynchronous. While other servers waste resources spinning off separate threads, Node fires off an event-driven asynchronous operation and keeps taking more requests in the meantime. The practical upshot is that porting web services from PHP or Ruby can deliver between 2x and 10x improvements in simultaneous connections and typically 30% - 60% improvements in average response times. Lots of big companies are doing web Node projects just for these reasons, including Adobe, Paypal, eBay, Walmart, Yahoo!, Groupon, Under, etc...
jenit shah
very nice article and very clear thought regarding node.js where to use and where not
Every major application development platform has already had support for HTML5 for the past several years, including websockets for bi-directional communication. Add to this the strong types, multi-threading and the tons of other stuff that languages such as Java have to offer and I seriously question why anyone would waste their time using this.
Just want to mention that node is not the only server side option for javascript especially since oracle put the nashorn javascript engine on the jdk. Now you can also use all the jvm goodness from javascript we are using vert.x as the async server and nashorn to use javascript. You can see some code samples in this module the project site is
This is an amazing overview ..Thank you
Vishnu Tekale
Very well written. Thanks for sharing.
I'm with you. For trivial application an ORM is fine. You have to remember that most devs really only have experience with trivial applications. So they will argue for an ORM because they can't learn SQL or don't have the time or staff to right stored procs. And they have never heard of Memcached and so think the ORM is a cache...what ever. And the weirdest excuse I hear is about decoupling. The ORMs I have had the misfortune of running across do the opposite. They very much tightly couple the UI to the database. ORM layers are large and buggy. So how do you test it? Yeah, good luck unit testing it (which you have to do because they are buggy).
If you are integrating with AD then you are probably in a Microsoft shop. And if you are uploading files to a web server then your environment isn't very sophisticated. So for you, you probably should just stick with IIS and VB.Net.
Microsoft public recommendations for architecture are a joke. Microsoft is a marketing and licensing company. They are not a tech company primarily
If you have a "huge number of coders updating the same codebase simultaneously" you have larger problems. Dev teams don't scale well. I would run. With too many cooks in the kitchen the broth will spoil. There is going to be no accountability and no responsibility with that many people contributing.
Gleb Bahmutov
Why Node is different - using bar as analogy
<a href="">شركة تنظيف شقق بالمدينة المنورة</a> <a href="">شركة تنظيف فلل بالمدينة المنورة</a> <a href="">مكافحة حشرات بالمدينة المنورة</a> <a href="">شركة تنظيف شقق بالدمام</a> <a href="">تسليك مجاري بالدمام</a> <a href="">شركة تنظيف منازل بالدمام</a> <a href="">نقل اثاث بالمدينة المنورة</a> <a href="">شركة تنظيف شقق بالمدينة المنورة</a> <a href="">شركة كشف تسربات المياه بالمدينة المنورة</a> <a href="">شركة نقل اثاث بالدمام</a> <a href="">شركة مكافحة حشرات بالخبر</a> <a href="">شركة تنظيف منازل بالدمام</a> <a href="">شركة مكافحة حشرات بالدمام</a> <a href="">شركة كشف تسربات المياه بالدمام</a> <a href="">شركة تسليك مجارى بالدمام</a> <a href="">شركة رش مبيدات بالدمام</a> <a href="">شركة تنظيف منازل بالدمام</a> <a href="">شركة تسليك مجارى بالدمام</a> <a href="">شركة تنظيف خزانات بالمدينة المنورة</a> <a href="">شركة كشف تسربات المياه</a> <a href="">مكافحة حشرات بالمدينة المنورة</a> <a href="">شركة تنظيف مسابح بجدة</a> <a href="">شركة تنظيف فلل بجدة</a> <a href="">كشف تسربات المياة بجدة</a> <a href="">شركة تنظيف بجدة</a> <a href="">شركة مكافحة حشرات ورش مبيدات بالقطيف</a> <a href="">شركة تخزين أثاث بالجبيل </a> <a href="">شركة عزل أسطح بالدمام</a> <a href="">هنا</a> <a href="">here</a> <a href="">here</a> <a href="">هنا</a> <a href="">هنا</a>
Just to let you know you have "support support" in How it works under-the-hood is pretty interesting. Compared to traditional web-serving techniques where each connection (request) spawns a new thread, taking up system RAM and eventually maxing-out at the amount of RAM available, Node.js operates on a single-thread, using non-blocking I/O calls, allowing it to support support tens of thousands of concurrent connections (held in the event loop).
Node.js will never replace Rails as the number one web framework.
Alifa Nurani Putri
Hello, Is node a best choice for video streaming and uploading? Is any different performance w/ PHP for that?
Nick Mok
How come PHP isn't mentioned for interacting with relational databases? It's as if PHP isn't used anymore? Why is it being neglected?
Clain Dsilva
Thanks for taking time to explain Node.js. I really had hard time understanding it from their website as well as Wikipedia. Well written post..!! Keep it up.
Cezar Luiz
What about this Nice article! Thanks!
Mona Ali
<a href=""> شركة نقل اثاث بالرياض </a> <a href=""> شركة كشف تسربات المياه بالرياض </a> <a href=""> شركة عزل مائى بالرياض </a> <a href=""> نقل عفش مكة </a> <a href=""> شركة نقل عفش مكة </a> <a href=""> شركة تنظيف بجدة </a> <a href=""> شركات نقل عفش مكة </a> <a href=""> شركة عزل خزانات بجدة </a> <a href=""> شركات مكافحة حشرات بجدة </a> <a href=""> عزل خزانات بالرياض </a> <a href=""> شركات العزل الحراري بالرياض </a> <a href=""> عزل مائي في الرياض </a> <a href=""> دكتور عماد جراح تصغير المعدة بالمنصورة </a> <a href=""> بالون المعدة </a> <a href=""> تدبيس المعدة </a> <a href=""> شركة القمة لابادة الحشرات بالرياض </a> <a href=""> شركة مكافحة البق بالرياض </a> <a href=""> شركة مكافحة النمل الابيض بالرياض </a> <a href=""> شركات نقل اثاث الرياض </a> <a href=""> شركة كشف تسربات بالرياض </a> <a href=""> نقل اثاث </a> <a href=""> نقل اثاث بالمدينة </a> <a href=""> شركة رش مبيدات بالمدينة المنورة </a> <a href=""> مكافحة حشرات بالمدينة المنورة </a> <a href=""> نقل اثاث بجدة </a> <a href=""> كشف تسربات المياة بجدة </a> <a href=""> شركة تنظيف خزانات بجدة </a> <a href=""> تنظيف فلل بالدمام </a> <a href=""> شركة تنظيف بالدمام </a> <a href=""> شركة تنظيف شقق بالدمام </a> <a href=""> نقل عفش بالرياض </a> <a href=""> شركة كشف تسربات بالرياض </a> <a href=""> تنظيف فلل بالرياض </a> <a href=""> شركه عزل خزانات بالمدينه المنوره </a> <a href=""> شركة تنظيف بالقطيف </a> <a href=""> شركة تنظيف بيارات بالأحساء </a> <a href=" /"> nile7seo</a> <a href="">nile7</a> <a href=" /">nile7</a> <a href="">nile7</a>
Marcelo Lima
Thank you for this article! Cleared a lot of questions I had about Node internals.
Awesome Article !
Insane IT Skills 1.Lifetime access to 24 lectures 2.Over 120 mins of high quality content! 2.Join to a community of over 2687 students learning together. 4.Course information and regular updates 5.Learn node.js and mongoDB from scratch by examples. 6.Course information and regular updates. 7.Discussion forum, which we encourage you to make use of -- both to pose questions about the material to the course instructor and to exchange ideas with your classmates. 8.High quality course support.
rahul garg
As per my understanding with article, if you send any request to node server it will actually process on some background thread (libuv.dll). Now I want to post some file through node server, why it block the node server while it will process on background thread ?
Super Article..!!
Isn't it possible to get the date of posting of your article? or all your posts for that matter. It is really disturbing to read technical posts without dates... thanks
You mention Node.js is good for a chat application because it's not CPU intensive. I can't think of too many use cases that don't require much CPU. For example, could Twitter be built with Node? It seems there's a lot of computation required just to generate your feed. Node.js uses certainly can't be so narrow.
Ian Kaplan
Great article. Thanks. There's an old joke: you're not a paranoid if they're really out to get you. That's the attitude that should be taken when it comes to Web application security. One thing that bothers me about Node.js is that I have no insight into how secure it is. When an environment like Grails, where I have Java/Groovy running on Tomcat I have some confidence in Tomcat security, if for no other reason than the fact that Tomcat has been around a long time and has evolved. This isn't true with Node.js. I was also looking at the Node.js libraries. At least for the file access, it appears to be nothing more than a thin layer over the POSIX file system calls. I like the Java or even the C++ file abstractions more. The main argument that I see for Node.js (made in this post) is that it has really lightweight threads and that you can have JavaScrip everywhere. This last issue is an attraction for those who only know JavaScript. As far as the light weight threads, this is not so much a language issue as a platform support issue. It should be possible to support this kind of thread model in another language.
Huge Web
Toptal designer did the design for them.
Great article! Thank you for all the information.
I agree. I guessed it was around "a year ago" because of most of Disqus comments. This is taken from their meta tags anyway: 2013-08-13.
Adnan King
Ethan Garofolo
Node.js isn't a web framework. It's a packed V8 runtime with some core libraries attached. Node is more like mri in the Ruby world than Rails.
yes <a href=""> ارشفة المواقع </a> <a href=""> كشف تسربات </a> <a href=""> عازل حرارى </a> <a href=""> عزل مائى </a> <a href=""> ترميم منازل </a> <a href=""> تنظيف خزانات </a> <a href=""> تنظيف خزانات </a> <a href=""> ترميم منازل </a> <a href=""> كشف تسربات المياه </a> <a href=" %D8%A7%D8%AB-%D8%B1%D8%B4-%D9%85%D8%A8%D9%8A%D8%AF%D8%A7%D8%AA-%D9%86%D8%B8%D8%A7%D9%81%D8%A9-%D8%B9%D8%A7%D9%85%D8%A9-0555126103_creation"> نظافة عامة </a> <a href=""> عزل مائى </a> <a href=""> عازل حرارى بالرياض </a> <a href=""> شركة نقل عفش بالرياض </a> <a href=""> غسيل خزانات بالرياض </a>. <a href=""> نقل اثاث بالرياض </a> <a href=""> ترميم منازل بالرياض </a> <a href=""> كشف تسربات المياه </a> <a href=""> عزل مائى بالرياض </a> <a href=""> نقل اثاث بالرياض </a> <a href=""> تخزين اثاث بالرياض </a> <a href=""> تخزين عفش </a> <a href=""> نقل اثاث بالرياض </a> <a href=""> تخزين اثاث بالرياض </a> <a href=""> نفل عفش بالرياض </a> <a href=""> تخزين اثاث بالرياض </a> <a href=""> كشف تسربات المياه </a> <a href=""> عزل مائى </a> <a href=""> ترميم منازل </a> <a href=""> مكافحة الحشرات </a> <a href=""> نقل عفش بالرياض </a> <a href=""> غسيل خزانات بالرياض </a> <a href=""> رش مبيدات بالرياض </a>
Node.js is like Rack. MRI is just a language implementation.
Lambda Pool
the problem is that mongodb, its too risky using a database who can't be migrated never...
Lambda Pool
well its true, ORM is a bad practice after all.
Lambda Pool
yes but it does in a very non efficiently way.
Lambda Pool
the database engine itself will be ever more sophisticated than any ORM library home made by someone else.
Yaser Elshafey
Thank you Will allow me to put some links to my website
John Bailo
It's ameezing how asynchronous the web still is.
Jayaraj Poroor
I agree - I'm not a fan of ORMs either. ORM is a classic example of leaky abstraction.
Jayaraj Poroor
Regarding using Node.js with relational databases: Shelloid ( is an open source application server for Node.js that we developed to simplify lot of programmer tasks. e.g., You can declare named SQL queries as annotations and a function by that name automatically gets added to the DB object for you to use.
I think you do not understand the reason for or characteristics of ORM's very well. ORM's not only isolate data concerns, they provide testability and greater flexibility than traditional SQL clients. ORM's also provide in memory access in place of inefficient joins, so they can actually be far more efficient than SQL in real world scenarios. Plus, given the choice of performing complex set operations in a limited procedural set language like SQL or complex in memory operations using a far richer, more expressive and maintainable language, the richer language wins if you ever expect to maintain or extend the application.
You don't know what you are talking about. If you are writing a non-trivial applications and not using an ORM than I'm sure there will be many developers both today and in the future that will be cursing your name as they wade through ridiculous rafts of SQL. Testability? I guess that's just for trivial applications. When I see ridiculous comments like this coming from node.js fanboi's it makes me suspect that they'd be singing a different tune if node.js had decent RDBMS capabilities.
Lambda Pool
you just overate ORM such as most OO fanboys does.
Lambda Pool
your comment is ridiculous too, ORM is not a everyone's accepted pattern.
The irony is that lambda's (aka, anonymous methods) are the basis of both javascript and the preferred technique for C#'s multiple implementation of the same callback pattern, albeit with full type safety. In fact node's major characteristics (2-way, lightweight, asynchronous has effectively been implemented in C# as "SignalR", and there are several language features which are both asynchronous and natively multithreaded, (unlike node.js). Now I could understand if your experience with ORM's was limited to Hibernate (absolutely awful, one of the worst implementations of a major concept I've ever had the displeasure to work with) or even EF, which at least is fairly powerful and expressive due to LINQ, if data nanny overkill. But a micro-ORM like Dapper gives you all the flexibility and power of direct SQL with the benefits of rich data manipulation via objects, and is fast, very fast. And I'm sorry, but OOP is a well proven, very effective design strategy if you know what you are doing, i.e., you are a pro. I see three major problems with the node.js approach that no one seems to have a good answer for: So you start with the premise that there are such inefficiencies in waiting for IO that there is a huge potential there. So yeah, you've got great concurrency, right until you get to the first blocking library, a database, a file server, etc, which is practically every major piece of functionality written. So it's just hurry up and wait for 10,000 connections instead of 100, ok that's something, but where does it get you? So then you start rewriting all those services asynchronously, but that's just a snake eating its own tail, because that's hurry up and wait too: Because in the end every database on earth ultimately comes to a magnetic arm skipping across a disk or reading solid state memory, and that's assuming you're on the same machine, as opposed to distributing data across a pool of far slower network connections. Then you have the single threaded issue: There is probably no more misused language than Javascript because the barriers of entry are so low. And while early adopters might understand a bad practice when they see one, most javascript programmers simply have no idea what they are doing. Thirdly, Javascript is not exactly a particularly fast language, so the advice seems to be don't do compute intensive tasks. Where does that get you? So you end up with an elegant solution to one category of issues, but you're trapped there, with no way out of the non-compute intensive, hurry up and wait ghetto.
Wow, that is one seriously ignorant statement. Uploading files to webservers is *THE* stated rational of node.js's inventor for why he wanted a non-blocking library. So when you fanboi's break out of the single threaded, slow dynamic world of cut and paste code with zero type safety, multithreading, and only one trick pony (lambdas) to match .Net's multiple asynchronous capablities, (all so that you can get 10x more users to hurry up and wait for IO), then you can lecture us about "sophistication". The .Net framework has a vastly more advanced feature set than any language you can name, period, and IIS, properly configured, can beat the piss out of Apache and can readily match nginx as a reverse proxy or for static content. In the end you've got several problems which are intractable: 1. Javascript is slow, and your technology of choice is single-threaded, so intensive compute tasks are off the table. 2. Javascript debugging and testing blows in comparison with any typed language. Pro's use extensive testing, not fly by the pants 'hey it works'. 3. The 'everything is modular' approach is not an architecture, it's an invitation to chaos, like Perl or PHP. 4. Concurrency doesn't buy you crap if all you are doing is waiting for some other IO bound process, which is pretty much everything worth doing with computers. 5. The quality and experience of many javascript programmers (not node.js programmers necessarily, but it's popularity will bring them) is remarkably poor, as demonstrated by comments in which fanboi's prove that they have no idea how other systems that actually don't ignore any computing problem they can't solve work.
Lambda Pool
ORM is just a work around for the problem of impedance mismatch, nothing else. Its not big deal, about OO its a cross paradigm like AOP and its not really based in nothing else beyond encapsulation. Without procedural paradigm OO does nothing, every real skilled programmer already knows that.
Impedance mismatch involves all sorts of ramifications, especially in regards to maintainability, portability, extensibility and performance. To quote Ethan above (since my explanation obviously didn't take): "'s a tool used to encapsulate database concerns, isolating them from the application. There are several benefits, but ultimately, it makes applications easier to test and maintain years down the road." "about OO its a cross paradigm like AOP and its not really based in nothing else beyond encapsulation. Without procedural paradigm OO does nothing" Ok, I'll be sure to spread the word that we should stop fooling around with all this esoteric OOP stuff and get back to a language that lets us do everything vis-a-vis encapsulation: VB6. You'd think a Javascript programmer might want to mention inheritance, if not polymorphism, since javascript has a relatively unusual mechanism for it: prototypes.
A singleton is an instantiable (non-static) object with a private constructor so that only a single instance can be created. (Imagine an instance class with a static property exposing an instance of itself that depends upon a private instance constructor). It was actually implemented in Java before .Net existed. Perhaps what you are thinking of is a non-blocking Callback mechanism, which is handled in C# via delegates, events (multicast delegates) and the new async and await keywords that transform standard C# into a lambda to be executed at compile time. It also handles multi-threaded asynchronous operations via it's Parallel extensions, which permit spreading load across multiple threads/cores as long as that work is not serial in nature. Also, I would encourage you to check out a micro-ORM like Dapper. It's far less comprehensive than EF, but it's far more flexible and gets out of the way, plus it's significantly more efficient than Hibernate and EF (about 5x faster for reads)
Yes this article rocked tits. Esp good for a Croat with ESL! ;) #nodeboy
Ty Turner
We are searching for a Node.js developer. Please see for details! Thank you
Edward Roberts
So after reading your article I still havent figured out why Node js want to reinvent the wheel... I still think node js and the likes are crap...
A great introduction to find out what it is JavaScript and once the answer to from <a href="">bagaimana tips mengatasi wanita frigid</a>
Noob questions: Um, isn't the ease with which you can move request data (i.e. untrusted data) into database (where data is assumed to be trusted) a big hazard? How do you ensure that you never forget to inspect every piece of incoming data when it arrives, before you start trusting it? Generally, I would assume something as popular as Node.js would have thought of this, but I remember back when Rails had blanket model update. That changed real quick when Github's use of this "feature" was exploited (fortunately, by a whitehat). Also, of course, just because you add a conversion speed bump does not mean that people won't make mistakes, but at least they're more likely to give it some thought, which probably means they're going to make less mistakes.
I don't understand the angst against using an ORM. Were you in a proper environment where concerns were separated? The ones bashing ORM just sound like they don't know what they're doing or how to engineer proper software. Why on earth would I want to go from writing software in Java/C#/_whatever_ to drop into SQL where it is hard to version, properly test, and can apparently cause severe brain damage? Everything is a double edged sword - an implementation or a convention like using an ORM over raw SQL really doesn't matter. Depending on the situation raw SQL might be best... it might be better to use a NoSQL store... maybe an ORM is fine! Usually, from my experience, I can tell you that an ORM is better for a lot of reasons, and they have been relayed by M. I spent the time to write my own libraries to abstract vendor specific implementations and you need to create your own mappings. You can easily spawn from a certain state or use existing data structures. It took time to write my libraries and it was not easy at all to do it but it was well worth my time to do it since I can now reuse my libraries. Is it the BEST? I don't know... I like it but I certainly won't go around to arbitrary technical articles that have nothing to do about SQL and post something like "Yes this technology is good but stay away from raw SQL!" I just don't see a need to be bashing anything here, especially an ORM when the article is exclusively about JS and NodeJS.
Probably one of the main points of this article, that gives Node is supposed scalability, is the offloading to a Queue or Service Bus that leads to asynchronous processing. That is a well proven architectural pattern, available in many languages, is especially used in CQRS (Command Query Responsibility Segregation) with Event Sourcing, is very well suited to be used by technologies such .Net Reactive Extensions that provide considerably greater functionality and flexibility than Node. Asynchronous programming and handling its pitfalls has been around without Node for years, if you had knowledge of enterprise development. As for the hate against ORMs... you guys crticising it seem to be moving from front-end development into an area where you have no knowledge or expertise in OO, BDD, TDD or any other proven Enterprise level methodology. No concept of integration other than Twitter feeds. No experience of complex Workflow or scalable caching. This is one of the dangers - you know JavaScript, and a bit of SQL. So everything else is superfluous - until you need it, such as the attempts to bring an element of type checking to JavaScript. Seriously, each technology has its place, but there is no one size fits all approach. Appreciate the strengths of each technology, and use them where appropriate.
comments powered by Disqus
Free email updates
Get the latest content first.
Trending articles
Relevant technologies
Toptal Authors
Front-end Developer
Software Engineer
Software Developer
Software Engineer
Android Developer

Hey, , share this post with your friends & we’ll send you $2000 if they become customers or $100 if they become developers.

About the author
JavaScript Developer
Tomislav is a software engineer, technical consultant and architect with over 10 years of experience. He specializes in full-stack, highly scalable, real-time JavaScript and Node.js applications, with past experience in C#, Java, and Ruby. He is an agile Kanban practitioner who loves to collaborate on development projects.