Cover image
Web Front-end
13 minute read

Why the Hell Would I Use Node.js? A Case-by-Case Tutorial

Node.js shines in real-time web apps that employ push technology over WebSocket. Node’s real-time, two-way connections—where the client and server can each initiate communication—enable the freer exchange of data.

Read the Spanishes version of this article translated by Isabella Rolz

Editor’s note: The English version of this article was updated on 10/03/2022 by our editorial team. It has been modified to include recent sources and to align with our current editorial standards.

JavaScript’s popularity has brought with it a lot of changes. The things we do on the web nowadays were hard to imagine just several years ago.

Before we dig into Node.js (“Node”) solutions, consider that applying JavaScript across the stack to unify the language and data format (JSON), would facilitate the optimal reuse developer resources. As this is more a benefit of JavaScript than Node.js specifically, we won’t elaborate further.

With all of its advantages, Node.js plays a critical role in the technology stack of many high-profile companies who depend on its unique benefits. This Node.js tutorial addresses how to realize these advantages and why you might—or might not—use Node.js.

What Is Node.js?

Node.js is composed of Google’s V8 JavaScript engine, the libUV platform abstraction layer, and a core library that is written in JavaScript. Additionally, Node.js is based on the open web stack (HTML, CSS, and JS), and operates over the standard port 80.

Node.js provides developers a comprehensive tool for working in the non-blocking, event-driven I/O paradigm. Ryan Dahl, the creator of Node.js was “inspired by applications like Gmail” and—in creating Node.js—aimed to create real-time websites with push capability.

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.

Why Use Node.js?

Node.js shines in real-time web applications employing push technology over WebSocket. 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 more freely. This is in stark contrast to the typical web response paradigm, where the client always initiates communication.

One might argue that we’ve had this technology for years in the form of Flash and Java Applets. In reality, however, those were just sandboxed environments that used the web as a transport protocol to be delivered to the client. Plus, Flash and Java Applets were run in isolation and often operated over nonstandard ports, which may have required extra permissions.

How Does Node.js Work?

Node really shines in building fast, scalable network applications. This is due to its capability of handling a huge number of simultaneous connections with high throughput.

Node.js uses 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.

Node.js is a platform that fills a particular need, and understanding this is absolutely essential. For example, you wouldn’t use Node.js to perform CPU-intensive operations. Nearly all of Node’s advantages are annulled if it’s used for heavy computation.

Node.js is a platform that fills a particular need. It is not a silver bullet, or a platform that will dominate the web development world.

How Node.js works under the hood is 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 nonblocking I/O calls. This allows Node to support tens of thousands of concurrent connections held in the event loop.

Traditional vs. Node.js Server Thread

Per Michael Abernethy’s 2011 article “Just what is Node.js?”, take a thread with an accompanying 2 MB of memory, running on a system with 8 GB of RAM, and providing a theoretical maximum of 4,000 concurrent connections. Add to this the cost of context-switching between threads, and you get a common scenario in traditional web-serving techniques. Node.js avoids all this, achieving high scalability levels.

There is, of course, the question of sharing a single thread among all client requests, a potential pitfall of writing Node.js applications.

First, heavy computation could choke up Node’s single thread and cause problems for all clients, as incoming requests are blocked until said computation is completed.

Second, developers need to be vigilant and prevent exceptions from bubbling up to the core (top) Node.js event loop, as this would cause the Node.js instance to terminate, effectively crashing the program.

To prevent the flow of exceptions, we pass errors back to the caller as callback parameters (instead of “throwing,” as we do in some other environments). If an unhandled exception manages to surface, we can use the Forever module or external tools such as upstart and monit and just upstart to monitor the Node.js process and perform the necessary recovery of a crashed instance. Note that these tools do not address the recovery of the current state of the user session.

npm: The Node Package Manager

Built-in support for package management using npm is included in every Node.js installation. The idea behind npm modules is similar to that of Ruby Gems: It is a set of publicly available, reusable components, easily installed via an online repository, with version and dependency management.

npm Inc. shares a list of packaged modules that are also accessible via its npm CLI tool. The module ecosystem is open to all to publish their own module, which would be added to the npm repository.

Some useful npm modules include:

express, Express.js, or simply Express

A Sinatra-inspired web development framework for Node.js, and the de facto standard for the majority of Node.js applications.

hapi

A modular and simple-to-use configuration-centric framework for building web and services applications.

connect

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.

socket.io and sockjs

A server-side component of two common WebSocket components.

pug (formerly Jade)

A templating engine inspired by HAML, a default in Express.js.

mongodb and mongojs

MongoDB wrappers to provide the API for MongoDB object databases in Node.js.

redis

The Redis client library.

lodash, underscore, lazy.js

The JavaScript utility belt. Underscore initiated the game but got overthrown by one of its two counterparts, mainly due to lazy.js' better performance and modular implementation.

forever

A 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.

bluebird

A full-featured Promises/A+ implementation with exceptionally good performance.

moment.js

A JavaScript date library for parsing, validating, manipulating, and formatting dates.

Where to Use Node.js

Chat

Chat is a typical real-time, multi-user application—from IRC (back in the day)—to modern implementations in Node.js with WebSocket.

The chat application is lightweight, high traffic, and data intensive (but low processing/computation). It runs across distributed devices and is the sweet-spot example for Node.js.

Simple, yet covering most of the paradigms you’ll ever use in a typical Node.js application, chat is a great use case for learning.

Let’s depict how chat works: Say we have a single chat room where users can exchange messages in one-to-many (actually all) fashion. Let’s also say there are three users connected to our message board.

On the server side, a simple Express.js application implements:

  1. A GET / request handler which serves the webpage containing a message board and a ‘Send’ button to initialize new message input, and
  2. A WebSocket 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:

  1. A handler for the ‘Send’ button click event, which picks up the input message and sends it down the WebSocket.
  2. A handler that listens for new incoming messages on the WebSocket client (i.e., user-originated messages that the server wants the client to display).

When a client posts a message, here’s what happens:

  1. The browser catches the ‘Send’ button click through a JavaScript handler. It 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. The 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 WebSocket client-side component running within the web page. The clients then pick up the message content and update the web page in place, by appending the new message to the board.

Client and Server WebSockets in a Node.js Application

Here is a simple example of real-time chat with NodeJS, Socket.io and ExpressJS.

For a more powerful solution, you might use a simple cache based on the Redis store. Or in an even more advanced solution, use a message queue to handle the routing of messages to clients, and a more robust delivery mechanism. The queue may cover for temporary connection losses or store messages for registered clients while they’re offline.

Regardless of the solution you choose, Node.js operates under the same basic principles: reacting to events, handling many concurrent connections, and maintaining fluidity in the user experience.

API on Top of an Object DB

Node.js is a natural fit for exposing the data from object DBs (e.g., MongoDB). JSON-stored data allows Node.js to function without 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 expose JSON objects with a REST API for the client to consume.

If you are using MongoDB, you needn’t worry about converting between JSON and whatever else when reading or writing from the database. Thus, you can avoid the need for multiple conversions by using a uniform data serialization format across the client, server, and database.

Queued Inputs

Node allows you the flexibility to push database write-offs to the side. But there are even more reasons to use Node.js.

If you’re receiving a large amount of concurrent data, your database can become a bottleneck. Node.js can easily handle the concurrent connections. Because—in this case—database access is a blocking operation, we run into trouble. The solution is to acknowledge the client’s behavior before the data is truly written to the database.

This approach enables the system to maintain responsiveness under a heavy load. It is particularly useful when the client doesn’t require firm confirmation of a successful data write, when logging or writing user-tracking data, processed in batches, to be used at a later time, or for operations that don’t need to be reflected instantly, like updating a Facebook “likes” count.

Data is queued through some kind of caching or message queuing infrastructure like RabbitMQ or ZeroMQ. It is then digested by a separate database batch-write process or computation-intensive processing backend service, written in a better-performing platform for such a task.

Database Batch-write in Node.js With Message Queuing.

In short: With Node you can push the database writes off to the side to deal with later.

Data Streaming

Why not use Node.js in data streaming? In more traditional web platforms, HTTP requests and responses are treated like isolated events—although they’re actually streams. We can use this observation to build some cool Node.js features.

For example, we can process files while they’re still being uploaded. As data comes in through a stream, we can process it in parallel during that upload process. This is true for real-time audio or video encoding and proxying between various data sources.

Proxy

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

As an example, let’s 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.

Using Node in place of a dedicated proxy server 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. In production, you’d handle such interactions with a dedicated proxy service (like nginx or HAProxy).

Brokerage/Stock Trader’s Dashboard

At the application level, brokers’ trading software is another example where desktop software dominates, but could be easily replaced with a real-time web solution. Brokers’ trading software tracks stock prices, performs calculations and technical analysis, and renders graphs and charts.

Why not use Node.js to write a real-time web-based solution for brokers? Then, brokers could easily switch workstations or work locations. We may soon meet our brokers on the beach in Florida or Ibiza or Bali.

Application Monitoring Dashboard

Imagine how you could grow your business if you could see what your visitors were doing in real time. With Node’s real-time, two-way sockets, you can gain this ability.

Node with WebSocket fits perfectly for tracking website visitors and visualizing their interactions in real time.

Reasons to use Node.js for a monitoring dashboard include gathering real-time stats from users, or introducing targeted interactions with your visitors by opening a communication channel at a specific point in your funnel. CANDDi productizes this idea.

System Monitoring Dashboard

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

Both internal (intracompany) and public services’ statuses can be reported live and in real time using this technology. Push a little further and try to imagine a network operations center (NOC) that monitors the applications of a telecommunications operator, cloud/network/hosting provider, or some financial institution. The applications would run on the open web stack backed by Node.js and WebSocket.

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

Where to Use Node.js, but Cautiously

Server-side Web Applications

With Node.js with Express.js, you can create classic web applications on the server side. While possible, this request-response paradigm in which Node.js would carry rendered HTML is not an ideal use case. There are arguments to be made for and against this approach. Here are some facts to consider:

Pros:

  • You can significantly ease the development of an application that does not require CPU-intensive computation, by using Javascript to build it top to bottom, even down to the database level—if you use JSON storage Object DB (e.g., MongoDB).
  • Crawlers receive a fully rendered HTML response, which is far more SEO friendly than, say, a Single Page Application or a WebSocket app that runs on top of Node.js.

Cons:

  • 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 can be painful. If you’re trying to perform relational operations, consider going with an environment such as Rails, Django, or ASP.Net MVC.

An alternative to 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 Not to Use Node.js

There are situations where Node may not be the best tool for the job.

Server-side Web Application With a Relational Database Application

Ruby on Rails was once the clear choice as a tool to access relational databases like PostgreSQL, MySQL, and Microsoft SQL Server. This was because relational DB tools for Node.js were still in their early stages while, in contrast, Rails automatically provided 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.

It’s possible and not uncommon to use Node solely on the front end, while keeping your Rails back end with its easy access to a relational DB.

But things have changed. Sequelize, TypeORM, and Bookshelf have come a long way toward becoming mature ORM solutions. It might also be worth checking out Join Monster if you’re looking to generate SQL from GraphQL queries.

Heavy Server-side Computation and/or Processing

Node.js is not the best platform to handle heavy computation. 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, nonblocking I/O model. This is because incoming requests are blocked while the thread is occupied with your number-crunching—assuming you’re trying to run computations in the same Node instance used to respond to requests.

Since Node.js is single-threaded and uses only a single CPU core, it would require considerable effort to develop a cluster module in order to deliver concurrency on a multicore server. Alternatively, you can 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. Ensure that you use an appropriate environment for the background processes, and that they communicate via a message queue server like RabbitMQ.

While you may run background processes on the main server, this approach may not scale well once the load increases. You may distribute background processing services to separate worker servers without the need to configure the loads of front-facing web servers.

With Node.js—as opposed to most other platforms—you enjoy that high reqs/sec throughput we talked about, as each request is a small task that Node handles quickly and efficiently.

Why Choose Node.js?

We discussed Node.js from theory to practice, beginning with its purpose, and ending with its sweet spots and pitfalls.

Problems with Node almost always originate from the fact that blocking operations are the root of all evil—and 99% of Node misuses are a direct consequence.

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

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

Understanding the basics

Node.js is a server-side, open-source, JavaScript runtime environment. Node uses Google's V8 engine---libUV---to deliver cross-platform compatibility and a core library. Notably, Node.js does not expose a global window object, since it does not run within a browser.

Because Node.js is single-threaded, we use it primarily for non-blocking, event-driven servers. We can also use Node.js for traditional websites and back-end API services, as it was designed with real-time, push-based architectures in mind.

Web frameworks like Angular and React are libraries that help organize and generate the front-end code that runs in a web browser. Web frameworks reuse code for common operations, thereby reducing development time. Some web frameworks are full stack.

No, Node.js is an environment. Back-end frameworks run within Node.js. Popular, compatible frameworks include Express.js (also referred to as Express) for HTTP servers and Socket.IO for WebSocket servers.

Node.js is not a programming language. The ".js" at the end of its name indicates that JavaScript is its associated programming language. Anything that can transpile to JavaScript---like TypeScript, Haxe, or CoffeeScript---can also be used with Node.js.

Aside from its being highly effective, Node.js is popular because of its huge, active, open-source, JavaScript-based ecosystem.

The Node.js runtime environment executes JavaScript code on the server, whereas Angular is a JavaScript framework that is executed on the client (i.e., within a web browser).

Node.js isn't bad. Its technology is widely used for many types of servers. However, because it’s single-threaded, Node.js is not ideal for web servers that double as computational servers---such heavy computation would block the server's responsiveness.

Comments

Anony Mouse
For relational DBs on Node, I like http://bookshelfjs.org/
Anony Mouse
For relational DBs on Node, I like http://bookshelfjs.org/
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).
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.
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!
jim thomas
Very helpful. Thanks a lot!
Roland
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.
Roland
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" ?
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" ?
irneb
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?
irneb
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?
zivkovic_milan
Great article, thanks :)
zivkovic_milan
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.
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.
chad
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!
chad
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!
ellisgl
Node works well with relational databases, just don't use an ORM. SQL isn't that hard to learn. =)
ellisgl
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
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
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
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: http://zef.me/4561/node-js-and-the-case-of-the-blocked-event-loop
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: http://zef.me/4561/node-js-and-the-case-of-the-blocked-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
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.
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.
ellisgl
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. https://github.com/ellisgl/GeekLab-XPDO
ellisgl
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. https://github.com/ellisgl/GeekLab-XPDO
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).
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.
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.
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.
Ethan
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.
Ethan
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. =)
Eric Elliott
Yes, you could, but Ruby would be a poor choice if your aim is performance. =)
Vedran
thank you for a great article. By using the node.js child process http://nodejs.org/api/child_process.html - would you be able to overcome the high computational blocking Fibonacci issue?
Vedran
thank you for a great article. By using the node.js child process http://nodejs.org/api/child_process.html - would you be able to overcome the high computational blocking Fibonacci issue?
nene odonkor
any real life examples?
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?
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. :)
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 BlueRival.com, and we can fix all the stuff you built wrong with NodeJS.
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 BlueRival.com, and we can fix all the stuff you built wrong with NodeJS.
RiggerTheGeek
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 https://github.com/rogerwang/node-webkit.
RiggerTheGeek
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 https://github.com/rogerwang/node-webkit.
hfuti
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.
hfuti
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.
Matthew Keas
This is very well written. Thank you for this!
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”](http://nodeguide.com/style.html#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.
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”](http://nodeguide.com/style.html#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.
kyoukhana
Great Article. Wondering who made the beautiful diagrams :)
kyoukhana
Great Article. Wondering who made the beautiful diagrams :)
TZ
Great article, thanks :) BTW, which tool do you use to draw the images?
TZ
Great article, thanks :) BTW, which tool do you use to draw the images?
Matthew Keas
+1 for that
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: http://exifdata.com/ 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)
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: http://exifdata.com/ 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
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.
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.
geniium
Glad you mention, most people don't mention this.
geniium
Glad you mention, most people don't mention this.
Tracker1
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.
Tracker1
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.
Tracker1
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.
Tracker1
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...
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...
opensas
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?
opensas
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.
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.
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.
jonpress
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: http://nombo.io/
jonpress
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: http://nombo.io/
Connor Leech
does something like mongoose.js solve the node relational database issue? http://mongoosejs.com/
Connor Leech
does something like mongoose.js solve the node relational database issue? http://mongoosejs.com/
Rob Tweed
Yes - see the queue/pre-forked worker pool approach adopted by EWD.js: http://gradvs1.mgateway.com/download/EWDjs.pdf Summarised here: http://gradvs1.mgateway.com/download/EWDjsMechanics.pdf
Rob Tweed
Yes - see the queue/pre-forked worker pool approach adopted by EWD.js: http://gradvs1.mgateway.com/download/EWDjs.pdf Summarised here: http://gradvs1.mgateway.com/download/EWDjsMechanics.pdf
keith
yeah, I was wondering about it too. great visual + awesome post.
keith
yeah, I was wondering about it too. great visual + awesome post.
Carlos Ballena
Very helpful article!
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.
Jesus Nuñez
npm install felixge/node-mysql. That might be the most useful repository I've seen in ages.
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!
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!
josep2
This is fantastic.
josep2
This is fantastic.
Jacopo Chiapparino
Nice article, thank you!
Jacopo Chiapparino
Nice article, thank you!
NoobMovies.com
I think Django still kicks Node's ass.
NoobMovies.com
I think Django still kicks Node's ass.
Alex Writing
Hey Tomislav, http://codecondo.com/7-minimal-node-js-web-frameworks/ I'd love if you could add the above post to the list :)
Alex Writing
Hey Tomislav, http://codecondo.com/7-minimal-node-js-web-frameworks/ 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!
Victor Lava
Omg, this is amazing.. I have always wanted to learn node.js!
ak
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.
ak
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.
crueber
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: http://nodejs.org/api/cluster.html
crueber
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: http://nodejs.org/api/cluster.html
crueber
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.
crueber
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.
elijahca
Awesome, thanks a lot for this!
elijahca
Awesome, thanks a lot for this!
Zmirc
Minor comment: don't confuse Object DBs with Mongo (Document DB). There are 2 completely different things.
Zmirc
Minor comment: don't confuse Object DBs with Mongo (Document DB). There are 2 completely different things.
Gianlucca
i agree, good post.
Gianlucca
i agree, good post.
Gianlucca
yes, i agree
Gianlucca
yes, i agree
Gianlucca
sure....
Gianlucca
sure....
Toulon
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. Error is "ReferenceError: form is not defined" in line 87 of the gist The question is how to call form mfntapes x number of times where x is a vairable? See lines 45-55 of https://gist.github.com/toulon/9571625
Toulon
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. Error is "ReferenceError: form is not defined" in line 87 of the gist The question is how to call form mfntapes x number of times where x is a vairable? See lines 45-55 of https://gist.github.com/toulon/9571625
Jesus Bejarano
ORM for real projects are useless hone.
Jesus Bejarano
ORM for real projects are useless hone.
Thomas
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.
Thomas
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.
Seb
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: http://en.wikipedia.org/wiki/Reactor_pattern 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. Just a personal opinion. Long story short, Node JS is cool, but there certainly is a similar framework written in your favorite language. Please just take 5 minutes to research it before switching to NodeJS.
Seb
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: http://en.wikipedia.org/wiki/Reactor_pattern 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. Just a personal opinion. Long story short, Node JS is cool, but there certainly is a similar framework written in your favorite language. Please just take 5 minutes to research it before switching to NodeJS.
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.
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 are great examples of why Node is so much better than the competition at web services. None of those 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, Uber, etc...
Eric Elliott
These are great examples of why Node is so much better than the competition at web services. None of those 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, Uber, etc...
jenit shah
very nice article and very clear thought regarding node.js where to use and where not
jenit shah
very nice article and very clear thought regarding node.js where to use and where not
CowsRule
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.
CowsRule
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.
robertcooke
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 https://github.com/core9/module-nashorn the project site is core9.io.
robertcooke
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 https://github.com/core9/module-nashorn the project site is core9.io.
Anonymous
This is an amazing overview ..Thank you
Anonymous
This is an amazing overview ..Thank you
Vishnu Tekale
Very well written. Thanks for sharing.
Vishnu Tekale
Very well written. Thanks for sharing.
Gleb Bahmutov
Why Node is different - using bar as analogy http://bahmutov.calepin.co/why-node-is-different.html
Gleb Bahmutov
Why Node is different - using bar as analogy http://bahmutov.calepin.co/why-node-is-different.html
FluckerSputter
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).
FluckerSputter
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).
piloh23
Node.js will never replace Rails as the number one web framework.
piloh23
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?
Alifa Nurani Putri
Hello, Is node a best choice for video streaming and uploading? Is any different performance w/ PHP for that?
SleightDifference
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?
SleightDifference
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.
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 https://github.com/felixge/node-mysql? Nice article! Thanks!
Cezar Luiz
What about this https://github.com/felixge/node-mysql? Nice article! Thanks!
Marcelo Lima
Thank you for this article! Cleared a lot of questions I had about Node internals.
Marcelo Lima
Thank you for this article! Cleared a lot of questions I had about Node internals.
Navid
Awesome Article !
Navid
Awesome Article !
Abdelhakim
https://www.udemy.com/nodejs-tutorial-from-scratch-by-examples/?couponCode=NewOffer 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.
Abdelhakim
https://www.udemy.com/nodejs-tutorial-from-scratch-by-examples/?couponCode=NewOffer 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 actually process on background thread and when done , only response will be returned by node thread ? Kindly suggest if I am missing some thing....
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 actually process on background thread and when done , only response will be returned by node thread ? Kindly suggest if I am missing some thing....
siddesh
Super Article..!!
siddesh
Super Article..!!
Fanck
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
Fanck
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
Namo
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.
Namo
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.
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.
Huge Web
Toptal designer did the design for them.
Scott
Great article! Thank you for all the information.
Scott
Great article! Thank you for all the information.
daimmo
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.
daimmo
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
nice
Adnan King
nice
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.
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.
Guest
Node.js is more like Rack, but not the same. MRI is just a language implementation.
Guest
Node.js is more like Rack, but not the same. 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
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
well its true, ORM is a bad practice after all.
Lambda Pool
yes but it does in a very non efficiently way.
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.
Lambda Pool
the database engine itself will be ever more sophisticated than any ORM library home made by someone else.
John Bailo
It's ameezing how asynchronous the web still is. Indeed, like a telephone answering machine, its utility lies there.
John Bailo
It's ameezing how asynchronous the web still is. Indeed, like a telephone answering machine, its utility lies there.
Jayaraj Poroor
I agree - I'm not a fan of ORMs either. ORM is a classic example of leaky abstraction.
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 (http://shelloid.org) 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.
Jayaraj Poroor
Regarding using Node.js with relational databases: Shelloid (http://shelloid.org) 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.
M.
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.
M.
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.
M.
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.
M.
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
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.
Lambda Pool
your comment is ridiculous too, ORM is not a everyone's accepted pattern.
M.
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.
M.
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.
M.
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.
M.
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.
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.
M.
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): "...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." "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.
M.
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): "...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." "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.
M.
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)
M.
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)
Qalandr
Yes this article rocked tits. Esp good for a Croat with ESL! ;) #nodeboy
Qalandr
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 http://altaits.com/careers/search-jobs/ for details! Thank you
Ty Turner
We are searching for a Node.js developer. Please see http://altaits.com/careers/search-jobs/ for details! Thank you
Vob Bobily
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...
Vob Bobily
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...
cintalauraramarimari
A great introduction to find out what it is JavaScript and once the answer to from <a href="http://goo.gl/cfkytp">bagaimana tips mengatasi wanita frigid</a>
cintalauraramarimari
A great introduction to find out what it is JavaScript and once the answer to from <a href="http://goo.gl/cfkytp">bagaimana tips mengatasi wanita frigid</a>
Daniel
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.
Daniel
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.
Q.
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.
Q.
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.
Michael
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.
Michael
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.
Reo
Great introduction to node.js! Thanks, i samo naprjed!
Reo
Great introduction to node.js! Thanks, i samo naprjed!
Richard Bellantoni
Because they suck for a complex application. Sure if your scenario where you spent all this time trying to make the ORM work the way you need it to, you could have just put that same effort into writing the SQL properly and making sure it's organized etc and you would be further along in the project and have more control over the application. ORM's are great at saving time on a small to medium scale project, but once you delve into more complex and larger applications, you're going to spend either A.) A lot of time coding to make the ORM work the way you need it or B.) Just decide to write the SQL yourself because the time it takes to make the tool work how you need it just isn't worth it.
Richard Bellantoni
Because they suck for a complex application. Sure if your scenario where you spent all this time trying to make the ORM work the way you need it to, you could have just put that same effort into writing the SQL properly and making sure it's organized etc and you would be further along in the project and have more control over the application. ORM's are great at saving time on a small to medium scale project, but once you delve into more complex and larger applications, you're going to spend either A.) A lot of time coding to make the ORM work the way you need it or B.) Just decide to write the SQL yourself because the time it takes to make the tool work how you need it just isn't worth it.
sinta maharani
JavaScript is better than some of the other programming languages. therefore <a href="http://goo.gl/L7tXeO">cara menghilangkan gatal keputihan</a> better fit with JavaScript
sinta maharani
JavaScript is better than some of the other programming languages. therefore <a href="http://goo.gl/L7tXeO">cara menghilangkan gatal keputihan</a> better fit with JavaScript
naseya10
Great, informative article. Thanks for sharing this. <a href="http://www.unlockpwd.com/">Unlockpwd</a>
naseya10
Great, informative article. Thanks for sharing this. <a href="http://www.unlockpwd.com/">Unlockpwd</a>
Eric Elliott
Pot, meet kettle. Those may be intractable problems if any of them were true. None of them are: 1. a) JavaScript is all JIT these days and delivers 1-2x native code performance (faster than any other dynamic language I'm aware of). b) Non-blocking by default can deliver orders-of-magnitude improvements in code efficiency - transparently. 2. Almost all modern editors support type inference for JS. ESLint, Closure Compiler, and a number of other options offer sophisticated static analysis capabilities. TypeScript even offers a nice structural type system. 3. The opposite of modular is a tightly coupled monolith. That's a bad idea in ANY language. 4. "if all you are doing is waiting for some other IO bound process" - Non-blocking by default means you're NEVER waiting for some other IO bound process. That's why Node delivers such huge improvements on resource utilization. 5. 2006 called. They want their language-snob attitude back. The days when serious engineers considered JS to be a toy are long since over. JS powers sophisticated enterprise applications at just about every fortune 500 today. Additional point: JS is the only language with fully native support for isomorphic code (meaning you reuse most of your application on both servers and clients). You can write JS ONCE, and it will power the server, the web browser, and mobile devices including iOS and Android. See React Native. https://leanpub.com/learn-javascript-react-nodejs-es6/
Eric Elliott
Pot, meet kettle. Those may be intractable problems if any of them were true. None of them are: 1. a) JavaScript is all JIT these days and delivers 1-2x native code performance (faster than any other dynamic language I'm aware of). b) Non-blocking by default can deliver orders-of-magnitude improvements in code efficiency - transparently. 2. Almost all modern editors support type inference for JS. ESLint, Closure Compiler, and a number of other options offer sophisticated static analysis capabilities. TypeScript even offers a nice structural type system. 3. The opposite of modular is a tightly coupled monolith. That's a bad idea in ANY language. 4. "if all you are doing is waiting for some other IO bound process" - Non-blocking by default means you're NEVER waiting for some other IO bound process. That's why Node delivers such huge improvements on resource utilization. 5. 2006 called. They want their language-snob attitude back. The days when serious engineers considered JS to be a toy are long since over. JS powers sophisticated enterprise applications at just about every fortune 500 today. Additional point: JS is the only language with fully native support for isomorphic code (meaning you reuse most of your application on both servers and clients). You can write JS ONCE, and it will power the server, the web browser, and mobile devices including iOS and Android. See React Native. https://leanpub.com/learn-javascript-react-nodejs-es6/
M.
1) 1-2x native code performance? Do the electrons run faster on node code? Not a good start. 2) Type inference is mapping variable declarations to types without explicit syntax, i.e., a) it requires actual types, and b) compilers enforce type safety, not editors. And you can dress it up any way you want, but there is no way to enforce sophisticated state analysis with slop-tastic dictionaries of whatever stored in strings & functional delegates. Also, Typescript is not Javascript, it is Javascript with a half-assed type system pasted on top. Even Google is abandoning Js for Typescript in Angular 2.0 Why? Because Google has decided that an untyped system is insufficient for serious work. But is that type system anywhere near as sophisticated as a compiled language? Nope, not even close. 3) You are misunderstanding what I was characterizing as "modular design". The alternative is not monolithic code, but encapsulation, specialization via inheritance (or prototyping), polymorphism, and externalizing dependencies via IoC. The alternative is SOLID, i.e., modern Object Orientation. 4) Your process may not be waiting, but your customers are waiting for the callback. My point is that being able to serve more requests doesn't do you any good if every served request then has to wait on yet another operation. In the end, somewhere somehow, you will eventually be going to a disk or waiting for IO, because that's where the information the customer wants lives. 5) I didn't say that JavaScript was a toy language, I said that most JavaScript developers are well-meaning, cut and paste amateurs, and they will invade the ranks of node.js developers as it becomes more popular. I'll take a strong type system over "full native support" (that's not native) for "isometric" code that can run on clients or servers [you say that like that's a good thing] any day. Wow, Js on android and iOS! I guess the days of Apple adding another strongly typed, native language for iOS are over</sarc> Obviously you've never heard of Mono, the cross platform .Net that compiles and runs on every major OS, produces native runtimes for all three major mobile platforms, and runs on everything from beowulf clusters to wearable devices. This is why we don't respect you. You don't know or understand anything that came before, or anything outside of your javascript bubble. You don't solve any problems that weren't solved before, but yet you're convinced you have all the answers. That seems to be a common theme with anyone whose education system stressed self-esteem over critical thinking.
M.
1) 1-2x native code performance? Do the electrons run faster on node code? Not a good start. 2) Type inference is mapping variable declarations to types without explicit syntax, i.e., a) it requires actual types, and b) compilers enforce type safety, not editors. And you can dress it up any way you want, but there is no way to enforce sophisticated state analysis with slop-tastic dictionaries of whatever stored in strings & functional delegates. Also, Typescript is not Javascript, it is Javascript with a half-assed type system pasted on top. Even Google is abandoning Js for Typescript in Angular 2.0 Why? Because Google has decided that an untyped system is insufficient for serious work. But is that type system anywhere near as sophisticated as a compiled language? Nope, not even close. 3) You are misunderstanding what I was characterizing as "modular design". The alternative is not monolithic code, but encapsulation, specialization via inheritance (or prototyping), polymorphism, and externalizing dependencies via IoC. The alternative is SOLID, i.e., modern Object Orientation. 4) Your process may not be waiting, but your customers are waiting for the callback. My point is that being able to serve more requests doesn't do you any good if every served request then has to wait on yet another operation. In the end, somewhere somehow, you will eventually be going to a disk or waiting for IO, because that's where the information the customer wants lives. 5) I didn't say that JavaScript was a toy language, I said that most JavaScript developers are well-meaning, cut and paste amateurs, and they will invade the ranks of node.js developers as it becomes more popular. I'll take a strong type system over "full native support" (that's not native) for "isometric" code that can run on clients or servers [you say that like that's a good thing] any day. Wow, Js on android and iOS! I guess the days of Apple adding another strongly typed, native language for iOS are over</sarc> Obviously you've never heard of Mono, the cross platform .Net that compiles and runs on every major OS, produces native runtimes for all three major mobile platforms, and runs on everything from beowulf clusters to wearable devices. This is why we don't respect you. You don't know or understand anything that came before, or anything outside of your javascript bubble. You don't solve any problems that weren't solved before, but yet you're convinced you have all the answers. That seems to be a common theme with anyone whose education system stressed self-esteem over critical thinking.
Eric Elliott
This reply just strikes me as willful ignorance. 1. Really? Rather than investigate and learn the truth, you just want to ridicule the answer? I'm not taking the bait. Watch Brendan Eich's Fluent talks if you're interested in actually learning something. 2. I know what types and type inference are, and I know the benefits of static types. I've been in this game since before JavaScript was invented. TypeScript is a superset of JavaScript that compiles to JS & allows for sophisticated static analysis. It's structural type system is better than the type system Java had back when I was coding in Java, and it's much better (as in more reliable and flexible) than C and C++. 3. "encapsulation, specialization via inheritance (or prototyping), polymorphism, and externalizing dependencies via IoC" - these are all forms of modularity, and JavaScript modules provide viable alternatives to all of them - and in the case of class inheritance, it's far superior. See https://medium.com/javascript-scene/the-two-pillars-of-javascript-ee6f3281e7f3 4. "your customers are waiting for the callback." Fortunately, that's where the performance I talked about in point 1 shines. JS provides efficient utilization of I/O resources. In fact, dealing with I/O bottlenecks is the entire reason that Node was invented. I've ported several large production projects from PHP and Ruby to Node, and seen dramatic reductions in response times, both average response times and response time ranges - and since a typical Node app utilizes a small fraction of the memory required for C# applications, your customer I/O competes less with the RAM paging you might experience with a compiled C# application. 5. "you say that like that's a good thing" I've seen objectively measurable increases in team velocity ranging from 40% - 60% improvements. Believe it or not, it's a fact, and being more able to adapt to changing needs and experiment more (particularly in the UI layer) delivers very real business value. Why do you think so many enterprise organizations are adopting Node? It's not because some dev prefers JS. It's because they ran the tests themselves and figured out it's a huge win. "Obviously you've never heard of Mono, the cross platform .Net that compiles and runs on every major OS" Yeah, I have - what I haven't heard of is Mono delivering anywhere near the value that Node delivers in enterprise production. Got a good article on that? 'Cause a quick Google search isn't turning up much... Check out this awesome result in the top 3 of the SERP: http://www.quora.com/Why-isnt-C-with-Mono-popular-for-enterprise-applications-on-Linux-servers ...but a quick Google search for Enterprise Node.js delivers quite a bit. Here are the top 3 search results I see: http://blog.risingstack.com/node-js-is-enterprise-ready/ https://www.joyent.com/nodejs-support https://www.centurylinkcloud.com/blog/post/node-js-is-taking-over-the-enterprise-whether-you-like-it-or-not/ There's really no contest here.
Eric Elliott
This reply just strikes me as willful ignorance. 1. Really? Rather than investigate and learn the truth, you just want to ridicule the answer? I'm not taking the bait. Watch Brendan Eich's Fluent talks if you're interested in actually learning something. 2. I know what types and type inference are, and I know the benefits of static types. I've been in this game since before JavaScript was invented. TypeScript is a superset of JavaScript that compiles to JS & allows for sophisticated static analysis. It's structural type system is better than the type system Java had back when I was coding in Java, and it's much better (as in more reliable and flexible) than C and C++. 3. "encapsulation, specialization via inheritance (or prototyping), polymorphism, and externalizing dependencies via IoC" - these are all forms of modularity, and JavaScript modules provide viable alternatives to all of them - and in the case of class inheritance, it's far superior. See https://medium.com/javascript-scene/the-two-pillars-of-javascript-ee6f3281e7f3 4. "your customers are waiting for the callback." Fortunately, that's where the performance I talked about in point 1 shines. JS provides efficient utilization of I/O resources. In fact, dealing with I/O bottlenecks is the entire reason that Node was invented. I've ported several large production projects from PHP and Ruby to Node, and seen dramatic reductions in response times, both average response times and response time ranges - and since a typical Node app utilizes a small fraction of the memory required for C# applications, your customer I/O competes less with the RAM paging you might experience with a compiled C# application. 5. "you say that like that's a good thing" I've seen objectively measurable increases in team velocity ranging from 40% - 60% improvements. Believe it or not, it's a fact, and being more able to adapt to changing needs and experiment more (particularly in the UI layer) delivers very real business value. Why do you think so many enterprise organizations are adopting Node? It's not because some dev prefers JS. It's because they ran the tests themselves and figured out it's a huge win. "Obviously you've never heard of Mono, the cross platform .Net that compiles and runs on every major OS" Yeah, I have - what I haven't heard of is Mono delivering anywhere near the value that Node delivers in enterprise production. Got a good article on that? 'Cause a quick Google search isn't turning up much... Check out this awesome result in the top 3 of the SERP: http://www.quora.com/Why-isnt-C-with-Mono-popular-for-enterprise-applications-on-Linux-servers ...but a quick Google search for Enterprise Node.js delivers quite a bit. Here are the top 3 search results I see: http://blog.risingstack.com/node-js-is-enterprise-ready/ https://www.joyent.com/nodejs-support https://www.centurylinkcloud.com/blog/post/node-js-is-taking-over-the-enterprise-whether-you-like-it-or-not/ There's really no contest here.
M.
1, yes, I'm mocking your evidently accidental claim that JavaScript makes electrons run faster, or even as fast as native, because it's patent nonsense. Not only is that impossible, it ignores one of node.js' acknowledged weaknesses: It sucks on compute intensive operations, because it's single threaded, which means compute intensive operations block execution... duh! 2. Your knowledge of Java does not qualify you to understand what a competent type system is. Java's generics are a largely useless, johnny come lately me-too feature when compared against to C# generics because they suffer from run-time erasure, in other words, the generic type safety and reflection only works at compile time, because at run time, everything is cast to an object. So when you are going on about static analysis, you are effectively trying to claim it's as good as compile time + run time type reflection, which is very far from the truth. 3. Meh. Chopping up everything into discrete functions is a form of modularity too, but it's vastly inferior to SOLID, which was my point in the first place. And while prototype based inheritance is interesting, it's hardly better than real inheritance, which permits far more flexible arrangements. 4. I don't see how it's impressive to speed up a Ruby app, or refactor some craptastic PHP into something faster. Your memory overhead claims are equally baseless: I can run micro.Net on a watch or on an arduino device. I can write .Net that runs very well on an under-powered phone. Look at the memory chrome consumes for an SPA, or try to run a complex javascript app on a tablet, and then tell me how "lightweight" JavaScript is. 5. The lack of a proper separation of concerns (which is the cause of most maintainability problems) is the number one issue I encounter at enterprise scaled customers, and an impressive team velocity is always how they got there. Why do I think a number of organizations are choosing node? Because typically a mediocre, over-sized team of moderate competence f'd up the previously shiny new thing that was supposed to solve all their problems, so they want to believe the hype that the problem is not them, but their previous technology choices.
M.
1, yes, I'm mocking your evidently accidental claim that JavaScript makes electrons run faster, or even as fast as native, because it's patent nonsense. Not only is that impossible, it ignores one of node.js' acknowledged weaknesses: It sucks on compute intensive operations, because it's single threaded, which means compute intensive operations block execution... duh! 2. Your knowledge of Java does not qualify you to understand what a competent type system is. Java's generics are a largely useless, johnny come lately me-too feature when compared against to C# generics because they suffer from run-time erasure, in other words, the generic type safety and reflection only works at compile time, because at run time, everything is cast to an object. So when you are going on about static analysis, you are effectively trying to claim it's as good as compile time + run time type reflection, which is very far from the truth. 3. Meh. Chopping up everything into discrete functions is a form of modularity too, but it's vastly inferior to SOLID, which was my point in the first place. And while prototype based inheritance is interesting, it's hardly better than real inheritance, which permits far more flexible arrangements. 4. I don't see how it's impressive to speed up a Ruby app, or refactor some craptastic PHP into something faster. Your memory overhead claims are equally baseless: I can run micro.Net on a watch or on an arduino device. I can write .Net that runs very well on an under-powered phone. Look at the memory chrome consumes for an SPA, or try to run a complex javascript app on a tablet, and then tell me how "lightweight" JavaScript is. 5. The lack of a proper separation of concerns (which is the cause of most maintainability problems) is the number one issue I encounter at enterprise scaled customers, and an impressive team velocity is always how they got there. Why do I think a number of organizations are choosing node? Because typically a mediocre, over-sized team of moderate competence f'd up the previously shiny new thing that was supposed to solve all their problems, so they want to believe the hype that the problem is not them, but their previous technology choices.
Eric Elliott
1. I think you misunderstood my meaning. JS runs 1-2x SLOWER than native -- much better perf than any other dynamic language I know of. It's fast enough to run AAA game engines like Unreal Engine and Unity in stunning quality at 60+ fps. 2. I actually think that a good native type tool would be a good addition to JavaScript, but only if they're user-definable structural types. That said, JavaScript does support static analysis via type inference, and there are a number of ways to provide type hints for dev tools. In addition, JavaScript also has an impressive array of runtime analysis tools. 3. "hardly better than real inheritance, which permits far more flexible arrangements..." Wrong. https://medium.com/javascript-scene/the-two-pillars-of-javascript-ee6f3281e7f3 4. My apologies. I was not aware of micro.Net. JavaScript also runs as-is on low-powered devices including Arduino, Tessel, and a number of others. Node works great on most of them. If that's not small enough, you can create a custom Node compile, drop features, even swap out the V8 engine for a different JS engine if you need to. You can also restrict yourself to using tiny JS libraries (of which there are many on npm) to keep your codebase compact. 5. "...they want to believe the hype that the problem is not them, but their previous technology choices." That might explain an experiment or two, but the Node takeover is much more than that. We're rapidly replacing apps in a variety of languages with Node. Having worked at a fortune 500 during the transition to Node, I can tell you our justifications: We did experimental ports to Node, found: 1. that the app was faster and more reliable, delivering huge wins in both average response time, and the number of requests we could serve with the same machine, and 2. The developers were more productive for a variety of reasons, including the fact that JavaScript specialists could more easily work on both sides of the stack without context switching, and a lot of code could be shared in both the server and the client. Those advantages have real, measurable influences on the company's bottom line. That's why Node is taking over at both startups and enterprise companies.
Eric Elliott
1. I think you misunderstood my meaning. JS runs 1-2x SLOWER than native -- much better perf than any other dynamic language I know of. It's fast enough to run AAA game engines like Unreal Engine and Unity in stunning quality at 60+ fps. 2. I actually think that a good native type tool would be a good addition to JavaScript, but only if they're user-definable structural types. That said, JavaScript does support static analysis via type inference, and there are a number of ways to provide type hints for dev tools. In addition, JavaScript also has an impressive array of runtime analysis tools. 3. "hardly better than real inheritance, which permits far more flexible arrangements..." Wrong. https://medium.com/javascript-scene/the-two-pillars-of-javascript-ee6f3281e7f3 4. My apologies. I was not aware of micro.Net. JavaScript also runs as-is on low-powered devices including Arduino, Tessel, and a number of others. Node works great on most of them. If that's not small enough, you can create a custom Node compile, drop features, even swap out the V8 engine for a different JS engine if you need to. You can also restrict yourself to using tiny JS libraries (of which there are many on npm) to keep your codebase compact. 5. "...they want to believe the hype that the problem is not them, but their previous technology choices." That might explain an experiment or two, but the Node takeover is much more than that. We're rapidly replacing apps in a variety of languages with Node. Having worked at a fortune 500 during the transition to Node, I can tell you our justifications: We did experimental ports to Node, found: 1. that the app was faster and more reliable, delivering huge wins in both average response time, and the number of requests we could serve with the same machine, and 2. The developers were more productive for a variety of reasons, including the fact that JavaScript specialists could more easily work on both sides of the stack without context switching, and a lot of code could be shared in both the server and the client. Those advantages have real, measurable influences on the company's bottom line. That's why Node is taking over at both startups and enterprise companies.
Kesava Velugubantla
especially with edge it is really handy !
Kesava Velugubantla
especially with edge it is really handy !
pawan kumar
Thanks Tamisalv I was looking for quick reference read for understanding node.js and why projects might use it. Reading this gave me a better understanding of advantages of this this technology and also when one might use it. Cheers!
pawan kumar
Thanks Tamisalv I was looking for quick reference read for understanding node.js and why projects might use it. Reading this gave me a better understanding of advantages of this this technology and also when one might use it. Cheers!
Jay
"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." As a result we have webpages which take longer to load nowadays when we have Internet speeds in the order of megabytes per second, than back in the day when our speeds were in the order of bytes per second but our webpages were plain simple HTML. Nowadays we have webpages which load halfway and then stop, which crash at the slightest network error i.e. dynamic IP address reassigning, or a momentary lapse in the WiFi signal forcing you to reload the whole page, whereas browsers are designed to gracefully handle those errors or resume once the network connection is restored, buggy Javascript scripts don't handle errors as well.
Jay
"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." As a result we have webpages which take longer to load nowadays when we have Internet speeds in the order of megabytes per second, than back in the day when our speeds were in the order of bytes per second but our webpages were plain simple HTML. Nowadays we have webpages which load halfway and then stop, which crash at the slightest network error i.e. dynamic IP address reassigning, or a momentary lapse in the WiFi signal forcing you to reload the whole page, whereas browsers are designed to gracefully handle those errors or resume once the network connection is restored, buggy Javascript scripts don't handle errors as well.
adroittech
I only have 1 question here with your statement... "It's structural type system is better than the type system Java had back when I was coding in Java, and it's much better (as in more reliable and flexible) than C and C++." I can not take that. How? can you examplify? Some Facts (with obviously answer in no) - Why did Node inventor used V8 engine which was made in C++ to power node, if the js type system was so flexible and much better? - Can nodejs decode vp8 codec video by itself as efficiently as C/C++? - Could you build nodejs on top of pure javascript instead of C++? - Is there any such thing as pure javascript? You really have to understand my friend that it is a type system that can take advantage of underlying hardware and makes your program efficient at CPU and memory. Strongly typed C++ can solve any problem, even build node js. Node shines at non-blocking i/o and that is about it, it can not do anything else. Yes you can chop-off node code and make it work on micro devices but will it be efficient and make sense? Can you make product like node where you have to code in C++, yes you can but it would not make sense as power of C/C++ in not in web, its optimizations and hardware. It not like non-blocking I/O is something new, we have had that in many technologies including java, .Net, basic, python and perl, this is very old. The only reason why this thing is in limelight is it has enabled millions of frontend javascript developers, who do not understand pointers and bash about C++, to write server code, which is simply overwhelming, that's why the buzz. And about "Node in particular are actually very well suited to handle distributed computation", why on earth one would write such a statement? Node is not made for computation. it can not compute as efficiently as C/C++/Java. Period. With all due respect, lets not bring C++ in picture here, there is simply no practical comparison at all, or it will be very touchy.
adroittech
I only have 1 question here with your statement... "It's structural type system is better than the type system Java had back when I was coding in Java, and it's much better (as in more reliable and flexible) than C and C++." I can not take that. How? can you examplify? Some Facts (with obviously answer in no) - Why did Node inventor used V8 engine which was made in C++ to power node, if the js type system was so flexible and much better? - Can nodejs decode vp8 codec video by itself as efficiently as C/C++? - Could you build nodejs on top of pure javascript instead of C++? - Is there any such thing as pure javascript? You really have to understand my friend that it is a type system that can take advantage of underlying hardware and makes your program efficient at CPU and memory. Strongly typed C++ can solve any problem, even build node js. Node shines at non-blocking i/o and that is about it, it can not do anything else. Yes you can chop-off node code and make it work on micro devices but will it be efficient and make sense? Can you make product like node where you have to code in C++, yes you can but it would not make sense as power of C/C++ in not in web, its optimizations and hardware. It not like non-blocking I/O is something new, we have had that in many technologies including java, .Net, basic, python and perl, this is very old. The only reason why this thing is in limelight is it has enabled millions of frontend javascript developers, who do not understand pointers and bash about C++, to write server code, which is simply overwhelming, that's why the buzz. And about "Node in particular are actually very well suited to handle distributed computation", why on earth one would write such a statement? Node is not made for computation. it can not compute as efficiently as C/C++/Java. Period. With all due respect, lets not bring C++ in picture here, there is simply no practical comparison at all, or it will be very touchy.
Eric Elliott
You may be interested in this: https://medium.com/javascript-scene/what-is-webassembly-the-dawn-of-a-new-era-61256ec5a8f6
Eric Elliott
You may be interested in this: https://medium.com/javascript-scene/what-is-webassembly-the-dawn-of-a-new-era-61256ec5a8f6
Ken Kopelson
Actually, Javascript in the V8 server engine is QUITE fast. The statement that Javascript is not fast is outdated. You combine Node with Chrome and you get a very fast environment. If you understand how Node works, it has an event loop that processes all code that is ready to run. So, you call a function that has a blocking database call inside and a callback when finished, it allows the the function to be called, which returns immediately allowing you to get on with other things while the database call is being processed. So you aren't "hurry-up and waiting" as you suppose. You get on with other things, and once the database call finishes, execution will continue to the callback which is invoked after the database call returns. So, you get the same basic abilities as a multi-threaded environment without all the extra overhead incurred by thread-state swapping. Because you don't get "time slicing" you have to be careful that no piece of code takes too long to run, and if it does, you just break it up using packages like "async". I come from a long C, C++, Delphi, Java background, having mastered the multi-threaded paradigm, and I can state assuredly that the Node single-threaded async paradigm is super cool, fast, and highly scalable...IF YOU KNOW WHAT YOU'RE DOING. But that's the same for any of the other technologies as well. None of these technologies are for neophytes.
Ken Kopelson
Actually, Javascript in the V8 server engine is QUITE fast. The statement that Javascript is not fast is outdated. You combine Node with Chrome and you get a very fast environment. If you understand how Node works, it has an event loop that processes all code that is ready to run. So, you call a function that has a blocking database call inside and a callback when finished, it allows the the function to be called, which returns immediately allowing you to get on with other things while the database call is being processed. So you aren't "hurry-up and waiting" as you suppose. You get on with other things, and once the database call finishes, execution will continue to the callback which is invoked after the database call returns. So, you get the same basic abilities as a multi-threaded environment without all the extra overhead incurred by thread-state swapping. Because you don't get "time slicing" you have to be careful that no piece of code takes too long to run, and if it does, you just break it up using packages like "async". I come from a long C, C++, Delphi, Java background, having mastered the multi-threaded paradigm, and I can state assuredly that the Node single-threaded async paradigm is super cool, fast, and highly scalable...IF YOU KNOW WHAT YOU'RE DOING. But that's the same for any of the other technologies as well. None of these technologies are for neophytes.
M.
A complex application is precisely where well tailored Domain objects and properly decoupled subsystems are most necessary. If you are spending all your time trying to get the ORM to work you should either learn that ORM better or get another ORM. I would assume the former goes without saying so if you are still fighting your ORM it's time to choose one that just works.
M.
A complex application is precisely where well tailored Domain objects and properly decoupled subsystems are most necessary. If you are spending all your time trying to get the ORM to work you should either learn that ORM better or get another ORM. I would assume the former goes without saying so if you are still fighting your ORM it's time to choose one that just works.
M.
Excepting your last comment that these technologies are not for neophytes, I think you are ignoring the last two paragraphs you were responding to. Even the founder of node.js says to avoid compute intensive operations. Yes, V8 speeds up javascript, but that doesn't solve the problem of a compute intensive operation or IO dependent operations blocking a single thread. You then respond that node.js is non-blocking and therefore it can be awaited. Great, I got that, sure, but what are you waiting on? Some code that isn't written in node.js apparently, (so much for the claimed benefit of "one true language to rule them all"), because your single threaded node.js process is happily moved on to something else until the callback. So, node.js works great just as long as you can rely on other processes handling the workload that is blocking (like waiting for IO), or another instance of single threaded node.js, that will (if written "correctly") undoubtable kick the can down the road to yet another process. And that's the issue: there are a limited subset of stuff done in programs that can be executed in parallel/out of order, and/or doesn't rely on blocking operations. Multi-threading is more complicated and has some overhead every time there is a context switch, but it means that more cores can be thrown at parallelizable units of work, and even discrete operations can be handled by the different threads. In a "node.js solves everything" world, you are either relying on something not written in node.js or waiting for your single threaded node.js application to finish up all the stuff that must be done, one way or another.
M.
Excepting your last comment that these technologies are not for neophytes, I think you are ignoring the last two paragraphs you were responding to. Even the founder of node.js says to avoid compute intensive operations. Yes, V8 speeds up javascript, but that doesn't solve the problem of a compute intensive operation or IO dependent operations blocking a single thread. You then respond that node.js is non-blocking and therefore it can be awaited. Great, I got that, sure, but what are you waiting on? Some code that isn't written in node.js apparently, (so much for the claimed benefit of "one true language to rule them all"), because your single threaded node.js process is happily moved on to something else until the callback. So, node.js works great just as long as you can rely on other processes handling the workload that is blocking (like waiting for IO), or another instance of single threaded node.js, that will (if written "correctly") undoubtable kick the can down the road to yet another process. And that's the issue: there are a limited subset of stuff done in programs that can be executed in parallel/out of order, and/or doesn't rely on blocking operations. Multi-threading is more complicated and has some overhead every time there is a context switch, but it means that more cores can be thrown at parallelizable units of work, and even discrete operations can be handled by the different threads. In a "node.js solves everything" world, you are either relying on something not written in node.js or waiting for your single threaded node.js application to finish up all the stuff that must be done, one way or another.
Ken Kopelson
You know what? You seem to just like spouting on about something you are clearly not qualified to speak about. You obviously have never built anything serious in Node.js. Well, I have, and I can tell you that it works great if you actually program it correctly. That means you use things like job queues, you use the clustering that Node provides, you make sure you do everything with callbacks and promises, you use "async" and "setImmediate" to properly share the processor between code that is waiting and code can now execute, you make sure UI code has priority over CPU intensive code, etc. For example, I wrote an "async" heap sort algorithm that works great, sorting massive lists while not blocking for any appreciable amount of time. I also have a 5000 line heuristic algorithm that is quite complex that I split up so that the main loops are executed using async constructs. I then have these executed from a job queue called "Kue" that allows for efficient use of all cores, no threads, great UI response time, and complex calculation jobs being executed in the background using all available processor power. This is ALL done in javascript with excellent performance in both CPU intensive tasks and response to front-end data requests. In other words mate, the UI is super responsive, and the background processing (complex heuristic calculation) performed quickly and very responsively. This is all done with a single language for both backend and front end, which is a huge deal when it comes to system architecture.
Ken Kopelson
You know what? You seem to just like spouting on about something you are clearly not qualified to speak about. You obviously have never built anything serious in Node.js. Well, I have, and I can tell you that it works great if you actually program it correctly. That means you use things like job queues, you use the clustering that Node provides, you make sure you do everything with callbacks and promises, you use "async" and "setImmediate" to properly share the processor between code that is waiting and code can now execute, you make sure UI code has priority over CPU intensive code, etc. For example, I wrote an "async" heap sort algorithm that works great, sorting massive lists while not blocking for any appreciable amount of time. I also have a 5000 line heuristic algorithm that is quite complex that I split up so that the main loops are executed using async constructs. I then have these executed from a job queue called "Kue" that allows for efficient use of all cores, no threads, great UI response time, and complex calculation jobs being executed in the background using all available processor power. This is ALL done in javascript with excellent performance in both CPU intensive tasks and response to front-end data requests. In other words mate, the UI is super responsive, and the background processing (complex heuristic calculation) performed quickly and very responsively. This is all done with a single language for both backend and front end, which is a huge deal when it comes to system architecture.
Jacob Ross
Why are they not for "neophytes"? Is it alcoholic?
Jacob Ross
Why are they not for "neophytes"? Is it alcoholic?
Jacob Ross
I agree. Most times that I think an ORM is inadequate for complex queries, I write out raw SQL, later to find out the ORM has an "app for that". I like using an ORM as much as possible, but I won't spend too much time making it work for me, otherwise, as M said, I'll find another ORM.
Jacob Ross
I agree. Most times that I think an ORM is inadequate for complex queries, I write out raw SQL, later to find out the ORM has an "app for that". I like using an ORM as much as possible, but I won't spend too much time making it work for me, otherwise, as M said, I'll find another ORM.
JF80
Sounds like the words from a "Michael" I know. ;) I agree with your last statement.. "each technology has it place". But why do you assume all Node developers are front-end developers with no back-end knowledge? Why is it NOT possible for these developers to make a scalable solution? Like or not Node is being used in Enterprise today and will continue to be adopted.
JF80
Sounds like the words from a "Michael" I know. ;) I agree with your last statement.. "each technology has it place". But why do you assume all Node developers are front-end developers with no back-end knowledge? Why is it NOT possible for these developers to make a scalable solution? Like or not Node is being used in Enterprise today and will continue to be adopted.
TerraT
Javascript is a poor choice of language for enterprise/complex development. It is messy, difficult to read, difficult to organise, doesn't support an entire raft of OO paradigms that save a lot of code repetition and provide readable abstraction, predominantly gives run time errors, no AOP, no by convention, no reflection, no generics/templates, no precision of scope, no rich low level processing, and it is not type safe. We are stuck with it in the browser, and frankly it is only inertia and legacy support that means it is still used there. In all rights it should have gone the way of the dinosaurs 10 years ago. The main driver to move away from scripting languages was that they were a maintenance nightmare and led to ball of mud applications that had constant bugs that couldn't be tracked. It has only been a short 10 years since we breathed a huge sigh of relief when serious development moved off of scripting languages and here we are doing it again unwilling to learn from the past, convinced that this is "new and cutting edge", rather than just old, tired and regurgitated. It will end up the same way as it did last time, being talked about with disgust like classic asp and perl cgi. I can only conclude the developers championing it now were just not around to see the fallout of this last time around. Every new generation of developer is convinced they have discovered "the truth", those of us who have seen this cycle of pain just have to sit back and shake our heads in disbelief. Unfortunately you can't teach experience, it is something you have to learn the hard way. Sure if you are an amateur and know nothing else then by all means, but anyone trying to do a professional job needs to leave this alone and stop making populist technology choices without considering the outcomes. If you can't evaluate the long term limitations of a technology for yourself you shouldn't be working in development. Developers need to stop being so childish, acting like a bunch of deluded fan boys, this is a serious business, not a game.
TerraT
Javascript is a poor choice of language for enterprise/complex development. It is messy, difficult to read, difficult to organise, doesn't support an entire raft of OO paradigms that save a lot of code repetition and provide readable abstraction, predominantly gives run time errors, no AOP, no by convention, no reflection, no generics/templates, no precision of scope, no rich low level processing, and it is not type safe. We are stuck with it in the browser, and frankly it is only inertia and legacy support that means it is still used there. In all rights it should have gone the way of the dinosaurs 10 years ago. The main driver to move away from scripting languages was that they were a maintenance nightmare and led to ball of mud applications that had constant bugs that couldn't be tracked. It has only been a short 10 years since we breathed a huge sigh of relief when serious development moved off of scripting languages and here we are doing it again unwilling to learn from the past, convinced that this is "new and cutting edge", rather than just old, tired and regurgitated. It will end up the same way as it did last time, being talked about with disgust like classic asp and perl cgi. I can only conclude the developers championing it now were just not around to see the fallout of this last time around. Every new generation of developer is convinced they have discovered "the truth", those of us who have seen this cycle of pain just have to sit back and shake our heads in disbelief. Unfortunately you can't teach experience, it is something you have to learn the hard way. Sure if you are an amateur and know nothing else then by all means, but anyone trying to do a professional job needs to leave this alone and stop making populist technology choices without considering the outcomes. If you can't evaluate the long term limitations of a technology for yourself you shouldn't be working in development. Developers need to stop being so childish, acting like a bunch of deluded fan boys, this is a serious business, not a game.
adroittech
OMG. Eric ! Are you for real? Do you even know how Nodejs works? Did you even try to look at backbone of Nodejs? Just download yourself a source-code and checkout. IT IS IN PLAIN C/C++. http_parcer is C++ lib. libuv is another and single most important C++ library in nodejs backbone which makes nodejs async, event driven and non blocking. Javascript by itself is body without a soul and life. JAVASCRIPT is just a script that you use to script your logic. One day if smeoene ports lua with this libs, he will not need Javascript to code. same for python etc. But the basic fact remains the same. IT IS C++ code that makes what nodejs is, not that javascript is too fast. in fact javascript is slowest in all of the scripting language. So don't flatter yourself in believing that just java-script is great and other things are shit. And do not insult C/C++ if you have no knowledge of it. So, again, i urge you to take back your words: "Javascript type system is better then C++". (Javascript has no type system. and if you still believe that it has one, you are in a very wrong field, go build some scaffolding) Also, these companies are not choosing nodejs for the reason you mentioned. This is possible in almost all languages. The reason why companies are choosing nodejs is that, they get ready made javascript coders, which are in millions and can not do c++/java code, to do server side because it is cheaper. Another reason -> its ecosystem. Yet another reason -> Its lot easier to conduct load tests in nodejs than other scripts. The link you mentioned is work that is intended to be started. Why do not you suggest them that please write this web-assembly compiler in nodejs rather than c/c++/assembly because according to you that is superior. C'Mon man, how can you compare Nodejs (A technology) with a C++ (language) they are not in the same league. C++ makes node possible, its not visa versa.
adroittech
OMG. Eric ! Are you for real? Do you even know how Nodejs works? Did you even try to look at backbone of Nodejs? Just download yourself a source-code and checkout. IT IS IN PLAIN C/C++. http_parcer is C++ lib. libuv is another and single most important C++ library in nodejs backbone which makes nodejs async, event driven and non blocking. Javascript by itself is body without a soul and life. JAVASCRIPT is just a script that you use to script your logic. One day if smeoene ports lua with this libs, he will not need Javascript to code. same for python etc. But the basic fact remains the same. IT IS C++ code that makes what nodejs is, not that javascript is too fast. in fact javascript is slowest in all of the scripting language. So don't flatter yourself in believing that just java-script is great and other things are shit. And do not insult C/C++ if you have no knowledge of it. So, again, i urge you to take back your words: "Javascript type system is better then C++". (Javascript has no type system. and if you still believe that it has one, you are in a very wrong field, go build some scaffolding) Also, these companies are not choosing nodejs for the reason you mentioned. This is possible in almost all languages. The reason why companies are choosing nodejs is that, they get ready made javascript coders, which are in millions and can not do c++/java code, to do server side because it is cheaper. Another reason -> its ecosystem. Yet another reason -> Its lot easier to conduct load tests in nodejs than other scripts. The link you mentioned is work that is intended to be started. Why do not you suggest them that please write this web-assembly compiler in nodejs rather than c/c++/assembly because according to you that is superior. C'Mon man, how can you compare Nodejs (A technology) with a C++ (language) they are not in the same league. C++ makes node possible, its not visa versa.
oberona
"The main driver to move away from scripting languages was that they were a maintenance nightmare and led to ball of mud applications" -- could you clarify what you mean by scripting languages, and what replacements "serious developers" migrated to over the past ten years? I was pleased to see a reference to Django in the article and have not run across maintainability issues caused by the use of Python, SQL, or ORMs in general. On the contrary, Python is my go-to language precisely for its maintainability. Your criticisms of js are spot on, but I can't see how they apply across the entire universe of scripting languages.
oberona
"The main driver to move away from scripting languages was that they were a maintenance nightmare and led to ball of mud applications" -- could you clarify what you mean by scripting languages, and what replacements "serious developers" migrated to over the past ten years? I was pleased to see a reference to Django in the article and have not run across maintainability issues caused by the use of Python, SQL, or ORMs in general. On the contrary, Python is my go-to language precisely for its maintainability. Your criticisms of js are spot on, but I can't see how they apply across the entire universe of scripting languages.
TerraT
Well I define scripting languages as runtime compilation languages, but there is a lot of overlap these days. I prefer the reassurance of compile time verification of at least coding accuracy but that is not the only factor. The depth of invasion into the inner workings of the compiler that tend to be exposed by compiled languages these days allow for a whole range of design constructs and patterns that allow programming to be more "intelligent", I just don't find this level of sophistication in the scripting languages I have used. It is a severe limitation for serious enterprise development. ORMs are an ugly approach to data access on relational databases, but you would probably have to be a database developer to realise why. Data design and Program design have different constraints, ORMs do either an injustice or have to be modified so much that they provide no productivity. There are many issues such as security, isolation, atomic operations that ORMs break, and remember a database is a living system and may require changes in between code releases as a matter of course. ORMs are a blunt tool if you want real performance from your database and want high concurrency without locking. Its a detailed subject I could probably write a book on it, so sorry if this isn't conclusive enough for you. Can't say much about Python other than I have heard good things in general. I'm the other end of the market on .Net, I crucify the open source guys next door in productivity and my defect level is about 1% of theirs. I think you need a large system before it makes significant differences, as you need to invest in framework and substrate to get the main benefits back, its "mass coding" that is the enemy here. When you have over a 100,000 code files you need a higher level of maintainability as it is simply beyond human capability to do it file by file (and certainly beyond maintenance budgets). By making core services that consume code as content you can achieve a high level of quality while keeping everything granular and ensuring release are small and targeted rather than entire system drops. Each to their own, but if you are an IT pro you must have seen the millions of script based systems festering away in businesses because no one can find anything or understand how it works. It's such a common complaint I should think it doesn't need justifying.
TerraT
Well I define scripting languages as runtime compilation languages, but there is a lot of overlap these days. I prefer the reassurance of compile time verification of at least coding accuracy but that is not the only factor. The depth of invasion into the inner workings of the compiler that tend to be exposed by compiled languages these days allow for a whole range of design constructs and patterns that allow programming to be more "intelligent", I just don't find this level of sophistication in the scripting languages I have used. It is a severe limitation for serious enterprise development. ORMs are an ugly approach to data access on relational databases, but you would probably have to be a database developer to realise why. Data design and Program design have different constraints, ORMs do either an injustice or have to be modified so much that they provide no productivity. There are many issues such as security, isolation, atomic operations that ORMs break, and remember a database is a living system and may require changes in between code releases as a matter of course. ORMs are a blunt tool if you want real performance from your database and want high concurrency without locking. Its a detailed subject I could probably write a book on it, so sorry if this isn't conclusive enough for you. Can't say much about Python other than I have heard good things in general. I'm the other end of the market on .Net, I crucify the open source guys next door in productivity and my defect level is about 1% of theirs. I think you need a large system before it makes significant differences, as you need to invest in framework and substrate to get the main benefits back, its "mass coding" that is the enemy here. When you have over a 100,000 code files you need a higher level of maintainability as it is simply beyond human capability to do it file by file (and certainly beyond maintenance budgets). By making core services that consume code as content you can achieve a high level of quality while keeping everything granular and ensuring release are small and targeted rather than entire system drops. Each to their own, but if you are an IT pro you must have seen the millions of script based systems festering away in businesses because no one can find anything or understand how it works. It's such a common complaint I should think it doesn't need justifying.
TerraT
P.S. I think "serious developers" have migrated to either Java, C# or back to C++ (along with their associated web techs etc). I wasn't really intending to be derogatory but these three probably account for 90% of all commercial development atm. C# wins out on the commercial front for me solely on Microsoft's considerable ongoing investment and new found modernist approach. C++ is not very productive and Java is really starting to look a little dated. Still I work in all three and they get the job done, each have their place.
TerraT
P.S. I think "serious developers" have migrated to either Java, C# or back to C++ (along with their associated web techs etc). I wasn't really intending to be derogatory but these three probably account for 90% of all commercial development atm. C# wins out on the commercial front for me solely on Microsoft's considerable ongoing investment and new found modernist approach. C++ is not very productive and Java is really starting to look a little dated. Still I work in all three and they get the job done, each have their place.
TerraT
P.P.S. "Python is my go-to language precisely for its maintainability"... What do you consider maintainability? It is often not what people think it is (or is not as simple as they think). It encompasses the cost of change and that is the primary cost on the business for a living project. Example: I have a service with 1000 public methods and the business asks me to de-prioritise all calls that take over 2 seconds. If I have to modify any of the code in those 1000 calls then my code has seriously poor maintainability. What I should be making is one code change in my service substrate pipeline. I should not even be modifying the substrate I should be probably writing a statistics module and a de-prioritise module for that substrate loaded in a separate dll that can be loaded dynamically. Now my testing is isolated to just this dll (reverse harness testing) and when ready for release I can add this dll and maybe make one small config change, that's it, no regression testing and no risk to existing code, so no production bugs in the service methods. So many typical code bases would require all 1000 methods to be altered or at least marked for an AOP operation. Enterprise design requires upfront anticipation of future "crazy" business requests. I find with most scripting languages and even with Java that finding insertion angles later on is nearly impossible. Even if I have a complete mare in C# I can emit the code directly into the methods using reflection, I have never seen this level of access on a scripting language and even if it was there it would be dangerous code to emit into runtime compiled operations (because I am literally changing the operations content so I would need to test the result of each). This is just one example I could probably come up with 100s... I'm a technical architect (framework and substrate) so it is my place to "save" my devs from backing themselves into a corner. If I do a good job I can reduce the coding and testing effort to 1% of a "mass coded" system. There is a whole other level of development that most devs will never see or appreciate, this means they are never equipped to make the most appropriate technology choices.
TerraT
P.P.S. "Python is my go-to language precisely for its maintainability"... What do you consider maintainability? It is often not what people think it is (or is not as simple as they think). It encompasses the cost of change and that is the primary cost on the business for a living project. Example: I have a service with 1000 public methods and the business asks me to de-prioritise all calls that take over 2 seconds. If I have to modify any of the code in those 1000 calls then my code has seriously poor maintainability. What I should be making is one code change in my service substrate pipeline. I should not even be modifying the substrate I should be probably writing a statistics module and a de-prioritise module for that substrate loaded in a separate dll that can be loaded dynamically. Now my testing is isolated to just this dll (reverse harness testing) and when ready for release I can add this dll and maybe make one small config change, that's it, no regression testing and no risk to existing code, so no production bugs in the service methods. So many typical code bases would require all 1000 methods to be altered or at least marked for an AOP operation. Enterprise design requires upfront anticipation of future "crazy" business requests. I find with most scripting languages and even with Java that finding insertion angles later on is nearly impossible. Even if I have a complete mare in C# I can emit the code directly into the methods using reflection, I have never seen this level of access on a scripting language and even if it was there it would be dangerous code to emit into runtime compiled operations (because I am literally changing the operations content so I would need to test the result of each). This is just one example I could probably come up with 100s... I'm a technical architect (framework and substrate) so it is my place to "save" my devs from backing themselves into a corner. If I do a good job I can reduce the coding and testing effort to 1% of a "mass coded" system. There is a whole other level of development that most devs will never see or appreciate, this means they are never equipped to make the most appropriate technology choices.
Josh Morgan
Interesting article, I've got quite a bit of experience in other realms but I'm somewhat new to Node.js. There's a few things I'd like to clear up: Flash was always async as well, it merely emulated threads much like it sounds like node does by using an event queue. However, I believe it is technical ignorance to claim that trusting thread management to a 3rd or 4th generation language would be better than trusting a well-tuned JRE or operating system optimized for it's multi-core chipset. How exactly do you think threads work in the lower levels anyway? It isn't some "magic", the only way to get true simultaneous code execution is via multiple processors, something you simply can't accomplish with a single thread. It's also a mistake to say that a new "event" does not add memory or clock cycles taken to a stack just because said events are managed by an interpreted scripting language rather than optimized, compiled C++. I'd bet my lunch that a well-written multi-threaded web application written in C or C++ will blow away any node.js app performance-wise, and that's even without getting into servers and their current multi-core processor architecture. If you've got a quad or 8-core server running a single node thread... you're only firing on one piston (quite ironic that Google calls their engine "V8" when considering such a fact). Another thing to realize is that while Flash (or even Java applets) ran in their own runtimes, so does node -- it's just hidden to the user. That is nothing more than "good" (perhaps hostile?) business moves on Google's part. Lets be honest here, if all browsers came with Flash automatically installed on them, and Apple actually supported Flash on their mobile devices, node probably wouldn't even exist today. I have other concerns about security. What kind of protection does it have against cross-site scripting and other attacks? Earlier today I stumbled across a TOR/Bittorrent client that ran in my browser window, and after opening it my computer wouldn't shut down nicely (it scares me to think what it could have been seeding!). No warnings about security or what types of connections my browser window was opening up, just went along with it's P2P business... the hacker side of me could have a real hay day with those kind of "features". I doubt that kind of stuff has been tested much either which means there's a lot of room for bugs, and where there's a lot of room for bugs there's a lot of room for vulnerabilities. But hey, at least your entire stack is all in the same language! Means you can hire less experienced developers for less money, right? ;)
Josh Morgan
Interesting article, I've got quite a bit of experience in other realms but I'm somewhat new to Node.js. There's a few things I'd like to clear up: Flash was always async as well, it merely emulated threads much like it sounds like node does by using an event queue. However, I believe it is technical ignorance to claim that trusting thread management to a 3rd or 4th generation language would be better than trusting a well-tuned JRE or operating system optimized for it's multi-core chipset. How exactly do you think threads work in the lower levels anyway? It isn't some "magic", the only way to get true simultaneous code execution is via multiple processors, something you simply can't accomplish with a single thread. It's also a mistake to say that a new "event" does not add memory or clock cycles taken to a stack just because said events are managed by an interpreted scripting language rather than optimized, compiled C++. I'd bet my lunch that a well-written multi-threaded web application written in C or C++ will blow away any node.js app performance-wise, and that's even without getting into servers and their current multi-core processor architecture. If you've got a quad or 8-core server running a single node thread... you're only firing on one piston (quite ironic that Google calls their engine "V8" when considering such a fact). Another thing to realize is that while Flash (or even Java applets) ran in their own runtimes, so does node -- it's just hidden to the user. That is nothing more than "good" (perhaps hostile?) business moves on Google's part. Lets be honest here, if all browsers came with Flash automatically installed on them, and Apple actually supported Flash on their mobile devices, node probably wouldn't even exist today. I have other concerns about security. What kind of protection does it have against cross-site scripting and other attacks? Earlier today I stumbled across a TOR/Bittorrent client that ran in my browser window, and after opening it my computer wouldn't shut down nicely (it scares me to think what it could have been seeding!). No warnings about security or what types of connections my browser window was opening up, just went along with it's P2P business... the hacker side of me could have a real hay day with those kind of "features". I doubt that kind of stuff has been tested much either which means there's a lot of room for bugs, and where there's a lot of room for bugs there's a lot of room for vulnerabilities. But hey, at least your entire stack is all in the same language! Means you can hire less experienced developers for less money, right? ;)
iwebworld
Good Article for Node JS, you can learn Node JS online in http://iwebworld.info or send a email iwebworldinfo@gmail.com
iwebworld
Good Article for Node JS, you can learn Node JS online in http://iwebworld.info or send a email iwebworldinfo@gmail.com
Avinash Shah
You could remove all the pitfalls of JS by using the its superset aka TypeScript.
Avinash Shah
You could remove all the pitfalls of JS by using the its superset aka TypeScript.
evanplaice
Tl;dr Use node for IO-heavy processing and delegating CPU-intensive processing to a cluster of specialized worker nodes (ex database, media processing, etc). This isn't exactly new information. I covered this topic back in '12: http://programmers.stackexchange.com/a/179499/1256 Ideally, the HTTP and API servers should be mostly stateless (excl session management) and disposable. They're just a functional pipeline that translates the raw data into consumable representations. That way, the servers are easy to provision/destroy dynamically to meet the spikey nature of demand. I'm not sure why so many of the commenters are vehemently arguing in favor of multi-purpose vertically-scalable server architectures. By nature, vertical scaling will always have an upper limit predicated by hardware capacity. No matter how efficient the code is. The writing is on the wall... You can spend a fortune on hardware and lose sleep questioning the validity of your risk assessment (aka WAG). At the end of the day, bare metal is a fixed asset. Best case, it meets expected demand and justifies the cost. Worst case, it either costs more than it's worth or lacks the capacity to meet demand. Alternatively, you can embrace distributive computing and automate the infrastructure to grow/contract relative to demand. For the people fighting religious wars over which language is best, node | C# | java. Who cares. All 3 allow 'functional-style' programming. All 3, support async processing (natively or through extensions). All 3 can be managed via provisioning. All 3 are perfectly valid for building distributive infrastructure. Choosing which one to use depends on the quality of the tools, whether or not it will be used to extend existing infrastructure, and the perception of the client. Build whatever you're good at building. If you're really good; build whatever is easiest to implement, support, and generate the most profit (or save the most on cost). BTW, kudos to the author. It's nice to see somebody do a comprehensive (and mostly objective) writeup on this topic.
evanplaice
Tl;dr Use node for IO-heavy processing and delegating CPU-intensive processing to a cluster of specialized worker nodes (ex database, media processing, etc). This isn't exactly new information. I covered this topic back in '12: http://programmers.stackexchange.com/a/179499/1256 Ideally, the HTTP and API servers should be mostly stateless (excl session management) and disposable. They're just a functional pipeline that translates the raw data into consumable representations. That way, the servers are easy to provision/destroy dynamically to meet the spikey nature of demand. I'm not sure why so many of the commenters are vehemently arguing in favor of multi-purpose vertically-scalable server architectures. By nature, vertical scaling will always have an upper limit predicated by hardware capacity. No matter how efficient the code is. The writing is on the wall... You can spend a fortune on hardware and lose sleep questioning the validity of your risk assessment (aka WAG). At the end of the day, bare metal is a fixed asset. Best case, it meets expected demand and justifies the cost. Worst case, it either costs more than it's worth or lacks the capacity to meet demand. Alternatively, you can embrace distributive computing and automate the infrastructure to grow/contract relative to demand. For the people fighting religious wars over which language is best, node | C# | java. Who cares. All 3 allow 'functional-style' programming. All 3, support async processing (natively or through extensions). All 3 can be managed via provisioning. All 3 are perfectly valid for building distributive infrastructure. Choosing which one to use depends on the quality of the tools, whether or not it will be used to extend existing infrastructure, and the perception of the client. Build whatever you're good at building. If you're really good; build whatever is easiest to implement, support, and generate the most profit (or save the most on cost). BTW, kudos to the author. It's nice to see somebody do a comprehensive (and mostly objective) writeup on this topic.
evanplaice
Yes, both languages support horizontal scaling with asynchronous message management infrastructure. CQRS is nothing but an API implementation pattern. CRUD is the typical use case (as it should be) but Node doesn't automagically scaffold 1:1 mappings between DB and CRUD (see rails/laravel/django for that). Node isn't a framework at all, it's just a HTTP server. You can leverage frameworks (ex Express) to make life easier by providing sane defaults and better structure but you still have to manually specify your API routes. .Net Reactive Extensions have been ported to JS: https://www.npmjs.com/package/rx In fact, even LINQ has been ported to JS (yes, seriously). http://linqjs.codeplex.com/ "Any application that can be written in Javascript, will be written in Javascript" - Atwood's Law ORMs are only an issue because they require an additional layer of abstraction from the underlying data. If (read when) the data models need to change to adapt to business demands, both the ORM and the database schema will need to be updated and tested to reflect the changes. Which is not really a big deal if there's a good update strategy in place. As for the rest of your comment, you'd do well if you stepped out of your comfort zone once in a while to see how JS development really works. 1. JS classes are currently supported now via ES6 (also, available client-side via polyfills). Prototypes really aren't much different than classes in terms of encapsulation (except they're a lot more flexible). Compile-time static type checking is even supported via TypeScript/Dart if that's what floats your boat, it's just not the default. 2. TDD/BDD isn't a feature exclusive to statically typed languages. There are a lot of great testing frameworks available in JS (both server/client-side). Choose your flavor, unit testing (Mocha), behavior driven unit testing (Chai), api testing (SuperTest), and continuous integration testing (TravisCI, and many others) are all used extensively throughout the community. JSUnit (the JS equivalent of JUnit/NUnit) is even available if you miss unit testing in Java/.NET. If anything, testing is a basic requirement of any non-trivial JS app that goes into production because you don't have a compile-time type checker to hold your hand. 3. Complex workflow? Seriously? So, you've never heard of NPM scripting, grunt, gulp? Automating any-and-everything in JS is pretty easy. Style enforcement, linting, documentation generation, scaffolding, one-click-deployment, language transpilation, bundling, distribution building, package/dependency management, release management, etc... 4. :cringe: if you rely on the compile-time static type checking system alone to validate user input, you're doing it wrong... Building a data layer in any language requires constraints above-and-beyond what the default types provide. So, either way you'll have to extend your data models with custom validation checks. The cool part about handling validation in JS is you can use the same routines to check user input on both the client/server-side. Less duplication of effort FTW. Contrary to what you think. Javascript really is a 'one size fits all' approach if you prefer to use it as such. Seriously, you can even compile C/C++ directly to javascript using asm.js. Does that mean you have to use it? Of course not. Any developer with a speck of sense wouldn't fault you for choosing C#, it's a great language. I have experience writing code in many languages, including building non-trivial desktop applications in C#. Given a choice, I'd prefer to use Javascript. The mix of, looser constraints and functional/imperative/prototype styles allow for a level of creativity I haven't experienced in any other language. The tools are great, the module system is amazing, and the language itself is getting substantially better with each update.
evanplaice
Yes, both languages support horizontal scaling with asynchronous message management infrastructure. CQRS is nothing but an API implementation pattern. CRUD is the typical use case (as it should be) but Node doesn't automagically scaffold 1:1 mappings between DB and CRUD (see rails/laravel/django for that). Node isn't a framework at all, it's just a HTTP server. You can leverage frameworks (ex Express) to make life easier by providing sane defaults and better structure but you still have to manually specify your API routes. .Net Reactive Extensions have been ported to JS: https://www.npmjs.com/package/rx In fact, even LINQ has been ported to JS (yes, seriously). http://linqjs.codeplex.com/ "Any application that can be written in Javascript, will be written in Javascript" - Atwood's Law ORMs are only an issue because they require an additional layer of abstraction from the underlying data. If (read when) the data models need to change to adapt to business demands, both the ORM and the database schema will need to be updated and tested to reflect the changes. Which is not really a big deal if there's a good update strategy in place. As for the rest of your comment, you'd do well if you stepped out of your comfort zone once in a while to see how JS development really works. 1. JS classes are currently supported now via ES6 (also, available client-side via polyfills). Prototypes really aren't much different than classes in terms of encapsulation (except they're a lot more flexible). Compile-time static type checking is even supported via TypeScript/Dart if that's what floats your boat, it's just not the default. 2. TDD/BDD isn't a feature exclusive to statically typed languages. There are a lot of great testing frameworks available in JS (both server/client-side). Choose your flavor, unit testing (Mocha), behavior driven unit testing (Chai), api testing (SuperTest), and continuous integration testing (TravisCI, and many others) are all used extensively throughout the community. JSUnit (the JS equivalent of JUnit/NUnit) is even available if you miss unit testing in Java/.NET. If anything, testing is a basic requirement of any non-trivial JS app that goes into production because you don't have a compile-time type checker to hold your hand. 3. Complex workflow? Seriously? So, you've never heard of NPM scripting, grunt, gulp? Automating any-and-everything in JS is pretty easy. Style enforcement, linting, documentation generation, scaffolding, one-click-deployment, language transpilation, bundling, distribution building, package/dependency management, release management, etc... 4. :cringe: if you rely on the compile-time static type checking system alone to validate user input, you're doing it wrong... Building a data layer in any language requires constraints above-and-beyond what the default types provide. So, either way you'll have to extend your data models with custom validation checks. The cool part about handling validation in JS is you can use the same routines to check user input on both the client/server-side. Less duplication of effort FTW. Contrary to what you think. Javascript really is a 'one size fits all' approach if you prefer to use it as such. Seriously, you can even compile C/C++ directly to javascript using asm.js. Does that mean you have to use it? Of course not. Any developer with a speck of sense wouldn't fault you for choosing C#, it's a great language. I have experience writing code in many languages, including building non-trivial desktop applications in C#. Given a choice, I'd prefer to use Javascript. The mix of, looser constraints and functional/imperative/prototype styles allow for a level of creativity I haven't experienced in any other language. The tools are great, the module system is amazing, and the language itself is getting substantially better with each update.
evanplaice
Upload Files: http://howtonode.org/really-simple-file-uploads "All the I/O operations is handled by Node.js is using multiple threads internally; it's the programming interface to that I/O functionality that's single threaded, event-based, and asynchronous." http://stackoverflow.com/a/22981768/290340 Libuv uses a thread-pool to handle I/O operations (files, sockets, etc) in an asynchronous manner. Where most languages block by default during CPU-heavy I/O operations, Node doesn't. It simply fires an event when the I/O operation completes on the worker thread. Active Directory: https://github.com/gheeres/node-activedirectory https://github.com/auth0/passport-windowsauth
evanplaice
Upload Files: http://howtonode.org/really-simple-file-uploads "All the I/O operations is handled by Node.js is using multiple threads internally; it's the programming interface to that I/O functionality that's single threaded, event-based, and asynchronous." http://stackoverflow.com/a/22981768/290340 Libuv uses a thread-pool to handle I/O operations (files, sockets, etc) in an asynchronous manner. Where most languages block by default during CPU-heavy I/O operations, Node doesn't. It simply fires an event when the I/O operation completes on the worker thread. Active Directory: https://github.com/gheeres/node-activedirectory https://github.com/auth0/passport-windowsauth
evanplaice
The distinction is that Node is async by default So, the number of developers doing async programming in other languages are the minority so they're not as well represented. "I can't come up with any good reason to use it on the server side in favor to other available languages." Not gonna lie, using Node at first was... Challenging to say the least. Getting used to async-by-default is not an easy transition. The nice part Node is, the primary focus of the platform is building servers/clients so the ecosystem has a lot of powerful tools to do anything dealing with web development. "...have better standard libraries, tools and resources." I'm not sure what gave you that impression. It doesn't use the monolithic-everything-and-the-kitchen-sink base class library approach. The core itself is very small but that's a benefit as it's much lighter to deploy. It also includes a very powerful, full-featured package manager by default so you're expected to add the dependencies your project needs. NPM (Node Package Manager) has over 200K packages and counting. Since the majority of the modules are developed independently from the core, they iterate and improve much faster than the equivalent core libraries in other languages. Dependencies are managed locally on a per-project basis in the package.json file. Typically, it's bad form for a module author to require that their package be installed globally. Installing packages locally prevents version conflicts at the global level and guarantees that -- when you install a package -- everything required to use the module is included. It may seem inefficient at first glance because many dependencies may have copies of the same sub-dependencies (or sub-subdeps, etc) but compared to the cost of including a massive standard library, the storage space is insignificant. The workflow to setup a project is: - clone the source - run 'npm install' NPM will automatically download and install all of the dependencies (incl sub-deps, sub-sub-deps, etc). Since the dependencies (and their specific versions) are explicitly defined in the config, you don't need to check them into source control. In addition, with ES6 (incl the new ES6-module-loader) about to be released, a new JSPM (Javascript Package Manager) has been created to manage client-side javascript dependencies. Module imports in the browser have finally been formalized in the language spec, so Bower and the variety of module-loading pseudo-standards (ex AMD, CommonJS, UMD) will go away.
evanplaice
The distinction is that Node is async by default So, the number of developers doing async programming in other languages are the minority so they're not as well represented. "I can't come up with any good reason to use it on the server side in favor to other available languages." Not gonna lie, using Node at first was... Challenging to say the least. Getting used to async-by-default is not an easy transition. The nice part Node is, the primary focus of the platform is building servers/clients so the ecosystem has a lot of powerful tools to do anything dealing with web development. "...have better standard libraries, tools and resources." I'm not sure what gave you that impression. It doesn't use the monolithic-everything-and-the-kitchen-sink base class library approach. The core itself is very small but that's a benefit as it's much lighter to deploy. It also includes a very powerful, full-featured package manager by default so you're expected to add the dependencies your project needs. NPM (Node Package Manager) has over 200K packages and counting. Since the majority of the modules are developed independently from the core, they iterate and improve much faster than the equivalent core libraries in other languages. Dependencies are managed locally on a per-project basis in the package.json file. Typically, it's bad form for a module author to require that their package be installed globally. Installing packages locally prevents version conflicts at the global level and guarantees that -- when you install a package -- everything required to use the module is included. It may seem inefficient at first glance because many dependencies may have copies of the same sub-dependencies (or sub-subdeps, etc) but compared to the cost of including a massive standard library, the storage space is insignificant. The workflow to setup a project is: - clone the source - run 'npm install' NPM will automatically download and install all of the dependencies (incl sub-deps, sub-sub-deps, etc). Since the dependencies (and their specific versions) are explicitly defined in the config, you don't need to check them into source control. In addition, with ES6 (incl the new ES6-module-loader) about to be released, a new JSPM (Javascript Package Manager) has been created to manage client-side javascript dependencies. Module imports in the browser have finally been formalized in the language spec, so Bower and the variety of module-loading pseudo-standards (ex AMD, CommonJS, UMD) will go away.
TerraT
As said above modern OO languages have a vast array of options to formalize and control your code and solutions that are lacking in scripting languages. That's just the plain truth, no amount of griping is going to change that. My point is there are a lot of developers choosing technology by popularity rather than suitability, that's what makes them fan boys. Right tool for the right job, applies in every trade apart from software development apparently. But that is probably because most developers aren't true "Tradesman", more glorified "DIY'ers". The industry is full of amateurs who don't even know enough to know that they know nothing! They think because they can write an if statement and a while loop they are pros. Techno-weenies...
TerraT
As said above modern OO languages have a vast array of options to formalize and control your code and solutions that are lacking in scripting languages. That's just the plain truth, no amount of griping is going to change that. My point is there are a lot of developers choosing technology by popularity rather than suitability, that's what makes them fan boys. Right tool for the right job, applies in every trade apart from software development apparently. But that is probably because most developers aren't true "Tradesman", more glorified "DIY'ers". The industry is full of amateurs who don't even know enough to know that they know nothing! They think because they can write an if statement and a while loop they are pros. Techno-weenies...
evanplaice
System level I/O operations (such as files, sockets) in Node are handled by libuv which does use a background thread pool. The difference is, the main thread can fire and forget the task to a background thread and the background thread will notify the main thread (via firing an event) when the operation is completed. Even with background thread processing, doing lots of I/O operations doesn't scale very well. For long-running CPU-heavy tasks (ex image/movie encoding) offloading the tasks to worker nodes is still preferable. In most languages, I/O operations are handled in a synchronous manner so if they requests are made on the main thread, they'll block execution until completed. The reason you don't see a noticeable pause in the UI when this happens is because the UI is asynchronous/event-based and runs on a thread separate from the main context.
evanplaice
System level I/O operations (such as files, sockets) in Node are handled by libuv which does use a background thread pool. The difference is, the main thread can fire and forget the task to a background thread and the background thread will notify the main thread (via firing an event) when the operation is completed. Even with background thread processing, doing lots of I/O operations doesn't scale very well. For long-running CPU-heavy tasks (ex image/movie encoding) offloading the tasks to worker nodes is still preferable. In most languages, I/O operations are handled in a synchronous manner so if they requests are made on the main thread, they'll block execution until completed. The reason you don't see a noticeable pause in the UI when this happens is because the UI is asynchronous/event-based and runs on a thread separate from the main context.
evanplaice
There's nothing stopping you from exposing the API as a microservice. WebKit just allows you to run a native JS client. I may be wrong but from what I understand, unlike the browser a webkit client isn't as strictly sandboxed so you can make system calls (ex to open/save files without user input).
evanplaice
There's nothing stopping you from exposing the API as a microservice. WebKit just allows you to run a native JS client. I may be wrong but from what I understand, unlike the browser a webkit client isn't as strictly sandboxed so you can make system calls (ex to open/save files without user input).
TerraT
I think you made my point for me, frothing unthinking, emotional nonsense, with very little in the way of fact, from a mind so fanatic about one thing it can't even see its failings. You seem to have made a fair few assumptions about what I do and don't know, I have been doing Javascript for 20 years, I know its short comings, I can work effectively in probably 30+ languages, I use what is appropriate, I never indicated otherwise. You need to grow up or find a new industry to work in. People like you are the problem with Software Development, know nothing nobodies who can't even make a case for a technology, let alone use one. Please stay away from the keyboard and do the rest of us a favour.
TerraT
I think you made my point for me, frothing unthinking, emotional nonsense, with very little in the way of fact, from a mind so fanatic about one thing it can't even see its failings. You seem to have made a fair few assumptions about what I do and don't know, I have been doing Javascript for 20 years, I know its short comings, I can work effectively in probably 30+ languages, I use what is appropriate, I never indicated otherwise. You need to grow up or find a new industry to work in. People like you are the problem with Software Development, know nothing nobodies who can't even make a case for a technology, let alone use one. Please stay away from the keyboard and do the rest of us a favour.
evanplaice
Do you use version control with a standard workflow (ex Gitflow workflow) where developers make changes on feature branches and code is peer reviewed before being merged? I've been messing around with trying to build an Angular2 website lately and the Angular2 project is still in early alpha so breaking changes are a regular (albeit unfortunate) occurrence. All of the available examples online are pretty-much broken so I've been monitoring the project development on Github. The rate that the core developers are thrashing on the codebase is truly remarkable. What's even more amazing is that every PR is unit tested and continuous integration tested well enough that every release is guaranteed to be fully functional (as far as they've implemented it so far).
evanplaice
Do you use version control with a standard workflow (ex Gitflow workflow) where developers make changes on feature branches and code is peer reviewed before being merged? I've been messing around with trying to build an Angular2 website lately and the Angular2 project is still in early alpha so breaking changes are a regular (albeit unfortunate) occurrence. All of the available examples online are pretty-much broken so I've been monitoring the project development on Github. The rate that the core developers are thrashing on the codebase is truly remarkable. What's even more amazing is that every PR is unit tested and continuous integration tested well enough that every release is guaranteed to be fully functional (as far as they've implemented it so far).
evanplaice
Following what Tracker1 is saying. Linting is the equivalent of compile-time checking in JS. I even use a Sublime extension that shows linter errors directly in the gutter of the editor as I'm writing code. If you want stricter checking you can add a style checker such as 'semistandard' which guarantees code styling on a project-wide basis. That means, spaces-not-tabs, indent 2 spaces, consistent functions, curly braces, etc... Type checking is good for superficial bugs (ex uninitialized variables, dead branches, invalid values) but eventually you'll have to verify the code doesn't have logic bugs through unit testing, continuous integration testing, api testing.
evanplaice
Following what Tracker1 is saying. Linting is the equivalent of compile-time checking in JS. I even use a Sublime extension that shows linter errors directly in the gutter of the editor as I'm writing code. If you want stricter checking you can add a style checker such as 'semistandard' which guarantees code styling on a project-wide basis. That means, spaces-not-tabs, indent 2 spaces, consistent functions, curly braces, etc... Type checking is good for superficial bugs (ex uninitialized variables, dead branches, invalid values) but eventually you'll have to verify the code doesn't have logic bugs through unit testing, continuous integration testing, api testing.
evanplaice
Node uses async event-based I/O via libuv (incl a thread pool reserved for I/O requests). The main thread absolutely does not block during I/O operations. It works the same way cluster would except it's built into Node. Check out one of the presentations on libuv for more details.
evanplaice
Node uses async event-based I/O via libuv (incl a thread pool reserved for I/O requests). The main thread absolutely does not block during I/O operations. It works the same way cluster would except it's built into Node. Check out one of the presentations on libuv for more details.
evanplaice
Performance wise, PayPal seems to think good things about Node http://dongnotes.blogspot.com/2013/12/paypals-nodejs-versus-java-benchmark.html For security, the 'cors' module is pluggable to Express and can be used for all the usual CORS control stuff. The 'helmet' module -- also pluggable to Express -- exposes a small suite of features to protect against malicious users including additional cross site scripting protection. I'm not sure if I'd call a Fullstack JS dev 'inexperienced'. Having a solid understanding of multiple domains in a development ecosystem that is constantly evolving is maddening... ya know, "10 years of experience vs 1 year of experience 10 times".
evanplaice
Performance wise, PayPal seems to think good things about Node http://dongnotes.blogspot.com/2013/12/paypals-nodejs-versus-java-benchmark.html For security, the 'cors' module is pluggable to Express and can be used for all the usual CORS control stuff. The 'helmet' module -- also pluggable to Express -- exposes a small suite of features to protect against malicious users including additional cross site scripting protection. I'm not sure if I'd call a Fullstack JS dev 'inexperienced'. Having a solid understanding of multiple domains in a development ecosystem that is constantly evolving is maddening... ya know, "10 years of experience vs 1 year of experience 10 times".
Josh Morgan
Node.js hasn't even been around for 10 years (which is funny considering I have seen job postings actually asking for 10 years experience with it). I understand that following evolving technology is a challenge, and after 20 years I can tell you that by the time you get completely comfortable with any "full stack" it will be less relevant because technology is always advancing. Nothing will change that, it's just how things work. However, you can't really have your cake and eat it too there. Newer technology is less tested and therefore less secure, but older technology does not have as many features. There's always a trade-off there. Anybody who claims otherwise is selling you something.
Josh Morgan
Node.js hasn't even been around for 10 years (which is funny considering I have seen job postings actually asking for 10 years experience with it). I understand that following evolving technology is a challenge, and after 20 years I can tell you that by the time you get completely comfortable with any "full stack" it will be less relevant because technology is always advancing. Nothing will change that, it's just how things work. However, you can't really have your cake and eat it too there. Newer technology is less tested and therefore less secure, but older technology does not have as many features. There's always a trade-off there. Anybody who claims otherwise is selling you something.
Anil Verma
I am sold on Node.JS (if your application is into building high scalability networking applications), Node.JS is the way to go in 2015. No wonder why so many startups and large corporations are adopting it. C++, Java, Ruby and Python havew their place in their respective domains. New companies and products will be getting built on wide variety of languages. I predict ROR adoption would still be high in coming years for building web applications (simply because ROR developers are easily available and time to market is so small). Excellent article though Tomislav.
Anil Verma
I am sold on Node.JS (if your application is into building high scalability networking applications), Node.JS is the way to go in 2015. No wonder why so many startups and large corporations are adopting it. C++, Java, Ruby and Python havew their place in their respective domains. New companies and products will be getting built on wide variety of languages. I predict ROR adoption would still be high in coming years for building web applications (simply because ROR developers are easily available and time to market is so small). Excellent article though Tomislav.
Daniel Jawna
So true! My job is the maintainance of legacy apps usually SQL Server dB's + ms access or php fronteds. These were usually made by "the grandson who is good with computers" Kind of guy. No foreign keys, but custom date + time functions. Your post is my sentiment exactly!
Daniel Jawna
So true! My job is the maintainance of legacy apps usually SQL Server dB's + ms access or php fronteds. These were usually made by "the grandson who is good with computers" Kind of guy. No foreign keys, but custom date + time functions. Your post is my sentiment exactly!
JPoet
I find Java very unproductive and very expensive for a lot of low level tedious work. C++ is for programmers who can handle memory access/pointers. Most corporate programmers cannot. Back in the day you had PL/1 and C for software engineers and COBOL for information technology programmers.
JPoet
I find Java very unproductive and very expensive for a lot of low level tedious work. C++ is for programmers who can handle memory access/pointers. Most corporate programmers cannot. Back in the day you had PL/1 and C for software engineers and COBOL for information technology programmers.
joselie castañeda
thanks!!!.. this is so helpful as i am going to make a heavy-computation enterprise application.. i think i'll try node.js on other application.. for now, i'll use ruby on rails
joselie castañeda
thanks!!!.. this is so helpful as i am going to make a heavy-computation enterprise application.. i think i'll try node.js on other application.. for now, i'll use ruby on rails
Túlio Spuri
When this article was written ?
Túlio Spuri
When this article was written ?
armandoali
Great article
armandoali
Great article
Olivier
Thanks for this article I think than the argument of same langage for front and dev is the worst I can liste or read. Organized à good coding with js is the more horrible things append in a team. I work since last year on backend project and where this should be coded in some times with mature framework like django it took too much time understand hundreds bugs. Where mongodb feels cool ? Never. I realy thinks than nodejs is a big joke and not So cool. The package manager give us some cool package to patch and hide the bad side of node but there is nothing to do about the callback hell. Finally the code looks like a big sand box than i hatte to open a file for debug or add some lines of code. So my conclusion is than for small app why not but for big and evolutive project not use nor nodejs and mongodb. Regards
Olivier
Thanks for this article I think than the argument of same langage for front and dev is the worst I can liste or read. Organized à good coding with js is the more horrible things append in a team. I work since last year on backend project and where this should be coded in some times with mature framework like django it took too much time understand hundreds bugs. Where mongodb feels cool ? Never. I realy thinks than nodejs is a big joke and not So cool. The package manager give us some cool package to patch and hide the bad side of node but there is nothing to do about the callback hell. Finally the code looks like a big sand box than i hatte to open a file for debug or add some lines of code. So my conclusion is than for small app why not but for big and evolutive project not use nor nodejs and mongodb. Regards
buffonomics
This is a fairly ill-informed comment as ES6 was alive and well as at a year ago. Besides the OO from ES6, there is also TypeScript which adds even more enterprise-level OO and enforcable static-typing to JavaScript. Like .NET is compiled to raw clr, TypeScript may also be "transpiled" to raw Javascript. NodeJS allows for pretty much all of this now with an even still better utilization of server resources and no OS lock-in. Think cutting your infrastructure costs by over 2000% because you really don't need to scale too vertically or pay for those .NET licenses per node of scale. Even if you were going the Mono route, lol...I'll let you research how that compares on your own. Fintech companies like Paypal that know a thing or 2 about load are happily doing great things with node as well so I highly doubt this comment of yours comes from a place of knowledge about what the NodeJS eco-system truly has to offer the enterprising product built in "this era", with a focus in micro-services (in the true-est sense of the word) and not "monolithic services" as you might be more used to. Also no matter what personal opinions you may have regarding ORMs, the logical fact of it all is that ORMS use more memory resources than is needed to run a backend. They also hit your datasources more than they should. You also said something regarding caching and ORMs to which I'm guessing you are referring to ORM-level caching (e.g. L1/2 Cache in Hibernate). I hope you understand that you don't actually NEED ORMs to do your caching for you. You can do this using efficient and beautifully-decoupled tools...and at that more flexibly. It's important to keep in mind that, even now, someone out there is still defending Fortran as the one true tool to building software. Things move quite fast in this industry. The pride is understandable, but my recommendation to you is to get involved in at least 1 new technoverse every couple years at most. You'll stay relevant and thank me later.
buffonomics
This is a fairly ill-informed comment as ES6 was alive and well as at a year ago. Besides the OO from ES6, there is also TypeScript which adds even more enterprise-level OO and enforcable static-typing to JavaScript. Like .NET is compiled to raw clr, TypeScript may also be "transpiled" to raw Javascript. NodeJS allows for pretty much all of this now with an even still better utilization of server resources and no OS lock-in. Think cutting your infrastructure costs by over 2000% because you really don't need to scale too vertically or pay for those .NET licenses per node of scale. Even if you were going the Mono route, lol...I'll let you research how that compares on your own. Fintech companies like Paypal that know a thing or 2 about load are happily doing great things with node as well so I highly doubt this comment of yours comes from a place of knowledge about what the NodeJS eco-system truly has to offer the enterprising product built in "this era", with a focus in micro-services (in the true-est sense of the word) and not "monolithic services" as you might be more used to. Also no matter what personal opinions you may have regarding ORMs, the logical fact of it all is that ORMS use more memory resources than is needed to run a backend. They also hit your datasources more than they should. You also said something regarding caching and ORMs to which I'm guessing you are referring to ORM-level caching (e.g. L1/2 Cache in Hibernate). I hope you understand that you don't actually NEED ORMs to do your caching for you. You can do this using efficient and beautifully-decoupled tools...and at that more flexibly. It's important to keep in mind that, even now, someone out there is still defending Fortran as the one true tool to building software. Things move quite fast in this industry. The pride is understandable, but my recommendation to you is to get involved in at least 1 new technoverse every couple years at most. You'll stay relevant and thank me later.
Ed
I really wanna be able to try out Node.js but it's such a pain in the effing ass to get something running. Installing a "simple" app always turns in to a list of things you need to do, install shit globally (which is NOT always possible), edit files, try to figure out what the damn devs mean in their scant instructions. It quickly goes to shit if you do the slightest thing wrong. If it's so great why hasn't anyone figured out a way to make simple installers with this thing?
Ed
I really wanna be able to try out Node.js but it's such a pain in the effing ass to get something running. Installing a "simple" app always turns in to a list of things you need to do, install shit globally (which is NOT always possible), edit files, try to figure out what the damn devs mean in their scant instructions. It quickly goes to shit if you do the slightest thing wrong. If it's so great why hasn't anyone figured out a way to make simple installers with this thing?
Alexis Menest
Ghost blogging platform https://github.com/TryGhost/Ghost/blob/master/package.json
Alexis Menest
Ghost blogging platform https://github.com/TryGhost/Ghost/blob/master/package.json
David
Yeah it would be nice with a date. I assume they don't show it because they know how biased people are towards new information — but it doesn't make much sense to hide it in an article about a fast growing technology.
David
Yeah it would be nice with a date. I assume they don't show it because they know how biased people are towards new information — but it doesn't make much sense to hide it in an article about a fast growing technology.
Samuel_Ogden
Would node be a bad idea for something like 9gag.com then? Would you need to do any image manipulation on a different server to prevent blocking?
Samuel_Ogden
Would node be a bad idea for something like 9gag.com then? Would you need to do any image manipulation on a different server to prevent blocking?
chaitanya
Hey Tomislav, Great article! I wanted to know that if suppose I want to get external hardware output in my app, e.g, scanner or e-signature (if user is doing e-signature or getting scanned copy from scanner), then can i get directly in my app? it will be like an api call as we do in Java.
chaitanya
Hey Tomislav, Great article! I wanted to know that if suppose I want to get external hardware output in my app, e.g, scanner or e-signature (if user is doing e-signature or getting scanned copy from scanner), then can i get directly in my app? it will be like an api call as we do in Java.
Misha R
TypeScript is syntactic sugar wrapper on top of standard JavaScript and compiles into standard JavaScript. It is invented to make the code maintainable and allows it to be used more like a real programming language. Given that you have to use JS where appropriate it makes writing it more familiar to real programmers and makes it maintainable. That said, anything JS and Node is appropriate for thin, lightweight web apps that need to be put together quickly and efficiently, for which things like ASP.NET, JSP, Ruby etc are a bit of overkill. Believing that one can not use the new magic Node for everything just because one guy can write front and back end is amateurish.
Misha R
TypeScript is syntactic sugar wrapper on top of standard JavaScript and compiles into standard JavaScript. It is invented to make the code maintainable and allows it to be used more like a real programming language. Given that you have to use JS where appropriate it makes writing it more familiar to real programmers and makes it maintainable. That said, anything JS and Node is appropriate for thin, lightweight web apps that need to be put together quickly and efficiently, for which things like ASP.NET, JSP, Ruby etc are a bit of overkill. Believing that one can not use the new magic Node for everything just because one guy can write front and back end is amateurish.
ellisgl
Encapsulating a language with another language, which you have to translate will add overhead. Also there are things that don't translate, just in real life translating between language, you loose something. In this case you loose speed (having to translate from one to the other), and optimization, because of reason one. ORM's don't do it all. In the beginning, I was for ORMs, then I dove deep into it and you end up with "How do I do this?", "Oh you can't easily, you have to do 10 other queries", or you end up with stuff that just seems like it should work well, but you end up wrecking the performance. ORMs are for simple "Select blah blah from table where x = y"... The only small redeeming factor of some ORMs are that they will convert their language to which ever DB. But if you are paid to work on a enterprise level application, you are only dealing with 1 - 3 databases, which are for used for separate things. If you have 500 employees and 10,000 customers, the ORM might be bottle neck.
ellisgl
Encapsulating a language with another language, which you have to translate will add overhead. Also there are things that don't translate, just in real life translating between language, you loose something. In this case you loose speed (having to translate from one to the other), and optimization, because of reason one. ORM's don't do it all. In the beginning, I was for ORMs, then I dove deep into it and you end up with "How do I do this?", "Oh you can't easily, you have to do 10 other queries", or you end up with stuff that just seems like it should work well, but you end up wrecking the performance. ORMs are for simple "Select blah blah from table where x = y"... The only small redeeming factor of some ORMs are that they will convert their language to which ever DB. But if you are paid to work on a enterprise level application, you are only dealing with 1 - 3 databases, which are for used for separate things. If you have 500 employees and 10,000 customers, the ORM might be bottle neck.
Nils Orbat
Hey, is there a library/tool you used to creste the graphics ?
Nils Orbat
Hey, is there a library/tool you used to creste the graphics ?
Praveen kumar Pamani
Thank you for this article , I would suggest this article if people want to know what is node and what can we do with nodejs.
Praveen kumar Pamani
Thank you for this article , I would suggest this article if people want to know what is node and what can we do with nodejs.
dohkoo
Great article, thanks for the overview! http://www.steshadoku.com
dohkoo
Great article, thanks for the overview! http://www.steshadoku.com
subkuchsell.com
thanks for great article really very helpful to understand the node.js subkuchsell.com
subkuchsell.com
thanks for great article really very helpful to understand the node.js subkuchsell.com
Tomislav Capan
Yes, this is true, article was authored and published in August 2013. (sorry for such a late confirmation, haven't seen this earlier)
Tomislav Capan
Yes, this is true, article was authored and published in August 2013. (sorry for such a late confirmation, haven't seen this earlier)
golfman484
In what universe can Mongo DB be referred to as an Object DB? It doesn't support inheritance. It's a Document Oriented DB not an Object Oriented DB. I just don't want any of the kiddies to get confused.
golfman484
In what universe can Mongo DB be referred to as an Object DB? It doesn't support inheritance. It's a Document Oriented DB not an Object Oriented DB. I just don't want any of the kiddies to get confused.
golfman484
We switched to one language for backend and UI but we decided to keep the language that runs lightning bolt fast at runtime and has type safety and supports standard ORMs with lazy loading etc., We didn't want to throw all those things away, which is what you have to do when you go with a JS solution on your backend. Java on the backend is a no brainer (so long as you don't over engineer and over complicate your app with memory and CPU sapping Spring). The key to using Java for the UI is use a Java framework that does all the JS for you - so you can live in a world devoid of having to deal with JS and stick with compiled, typesafe, enterprise suitable code. This solution is also scalable - J2SE has supported clustering for nearly two decades now. One such Java UI framework that covers all our JS needs and gives us all the 'partial updates' goodness with an AJAX event driven model with websockets option is Wicket.
golfman484
We switched to one language for backend and UI but we decided to keep the language that runs lightning bolt fast at runtime and has type safety and supports standard ORMs with lazy loading etc., We didn't want to throw all those things away, which is what you have to do when you go with a JS solution on your backend. Java on the backend is a no brainer (so long as you don't over engineer and over complicate your app with memory and CPU sapping Spring). The key to using Java for the UI is use a Java framework that does all the JS for you - so you can live in a world devoid of having to deal with JS and stick with compiled, typesafe, enterprise suitable code. This solution is also scalable - J2SE has supported clustering for nearly two decades now. One such Java UI framework that covers all our JS needs and gives us all the 'partial updates' goodness with an AJAX event driven model with websockets option is Wicket.
Rumana Amin
Hi Tomislav, your article is really nice and informative. It helped me a lot to understand Node.js and it's uses.
Rumana Amin
Hi Tomislav, your article is really nice and informative. It helped me a lot to understand Node.js and it's uses.
WarrEagle
The simple answer is do not use Node.js for that. What part of that are you missing? You want to serve GEO data coordinates to 500K connected clients?...easy. Do a massive JOIN statement across a million rows on a RDBS? You're screwed. Surgeons do not work with chainsaws. Neither should programmers.
WarrEagle
The simple answer is do not use Node.js for that. What part of that are you missing? You want to serve GEO data coordinates to 500K connected clients?...easy. Do a massive JOIN statement across a million rows on a RDBS? You're screwed. Surgeons do not work with chainsaws. Neither should programmers.
golfman484
You underate ORM as most of the people who have never built an OO system with a decent highly performant ORM that rocks do (and by 'decent' ORM I'm NOT referring to the ORM most people think of using, Hibernate!)
golfman484
You underate ORM as most of the people who have never built an OO system with a decent highly performant ORM that rocks do (and by 'decent' ORM I'm NOT referring to the ORM most people think of using, Hibernate!)
golfman484
I agree - this article and associated comments by the JS fan boys confirms my fears that most JavaScript apps must have anemic domain models (https://martinfowler.com/bliki/AnemicDomainModel.html) that are quite trivial and virtually expression less - all the work will be done in disassociated (not encapsulated and definitely not polymorphic) business logic.
golfman484
I agree - this article and associated comments by the JS fan boys confirms my fears that most JavaScript apps must have anemic domain models (https://martinfowler.com/bliki/AnemicDomainModel.html) that are quite trivial and virtually expression less - all the work will be done in disassociated (not encapsulated and definitely not polymorphic) business logic.
golfman484
I'm guessing your experience with 'ORMs' is limited to Hibernate. I had a similar experience until I thought there must be better ORMs out there - look around - others exist.
golfman484
I'm guessing your experience with 'ORMs' is limited to Hibernate. I had a similar experience until I thought there must be better ORMs out there - look around - others exist.
golfman484
Good points Adin - I was about to make the same ones. In regard to the article's claim that traditional frameworks "spawn a new thread for each connection (request)": So, so wrong. Must have made more than a few people livid to see such an error which either a) the author knows is clearly wrong and persists with the view or b) has never used any other backend framework and so doesn't realize that he is so wrong. The conflation of connection with request is also interesting. Does his knowledge not extend to understand the concept of connection "keep alives". A connection does not have a one to one relationship to requests as he suggests. This kind of skewed, twisted view of how intelligent, mature, highly evolved frameworks (eg., Java/Tomcat and I'm sure .net/ASP) handle requests makes me feel like this article is tainted and not representing the truth about alternatives. In regard to moving away from the Request/Response mentality - many existing frameworks have done this also and created a component oriented architecture that supports asynchronous model based updates. eg., Java Wicket or Angular JS. It's almost like running JS (a type unsafe, non OO language - if you're a believer that manual, self assembly 'prototype' inheritance is in the true OO spirit) on the server is not a concept that has enough merit without twisting the truth about how traditional server side frameworks work. It's like that or maybe it is that.
golfman484
Good points Adin - I was about to make the same ones. In regard to the article's claim that traditional frameworks "spawn a new thread for each connection (request)": So, so wrong. Must have made more than a few people livid to see such an error which either a) the author knows is clearly wrong and persists with the view or b) has never used any other backend framework and so doesn't realize that he is so wrong. The conflation of connection with request is also interesting. Does his knowledge not extend to understand the concept of connection "keep alives". A connection does not have a one to one relationship to requests as he suggests. This kind of skewed, twisted view of how intelligent, mature, highly evolved frameworks (eg., Java/Tomcat and I'm sure .net/ASP) handle requests makes me feel like this article is tainted and not representing the truth about alternatives. In regard to moving away from the Request/Response mentality - many existing frameworks have done this also and created a component oriented architecture that supports asynchronous model based updates. eg., Java Wicket or Angular JS. It's almost like running JS (a type unsafe, non OO language - if you're a believer that manual, self assembly 'prototype' inheritance is in the true OO spirit) on the server is not a concept that has enough merit without twisting the truth about how traditional server side frameworks work. It's like that or maybe it is that.
golfman484
Not every client who has an active session needs to be allocated their own thread - threads are shared and each user only needs a thread to service requests. Requests come in in short bursts and don't need to tie up a thread for very long if the back end code is executing in a highly optimized, compiled language and a fast database. For this reason you can't say "System A can support 10,000 threads therefore it can only support 10,000 clients". The number of clients supported is orders of magnitude greater than the number of threads available because of diversity. Most UI's, if well written, only 'phone home' to the server when absolutely necessary - not "all the time".
golfman484
Not every client who has an active session needs to be allocated their own thread - threads are shared and each user only needs a thread to service requests. Requests come in in short bursts and don't need to tie up a thread for very long if the back end code is executing in a highly optimized, compiled language and a fast database. For this reason you can't say "System A can support 10,000 threads therefore it can only support 10,000 clients". The number of clients supported is orders of magnitude greater than the number of threads available because of diversity. Most UI's, if well written, only 'phone home' to the server when absolutely necessary - not "all the time".
golfman484
It sounds like the node.js people think that JS is the only language that supports concurrency (although they promote a single threaded web server solution -WTF?) and non blocking I/O - of course it's not that case but you seem so excited about such things that I can only assume you have just discovered concepts that have existed in other languages for 2 decades or more
golfman484
It sounds like the node.js people think that JS is the only language that supports concurrency (although they promote a single threaded web server solution -WTF?) and non blocking I/O - of course it's not that case but you seem so excited about such things that I can only assume you have just discovered concepts that have existed in other languages for 2 decades or more
Tomislav Capan
Of course, you understand this is an illustration. In practice, it's a thread pool, which is limited by memory available, and is magnitudes of order less than what an event look can support. Thanks for the comment, though
Tomislav Capan
Of course, you understand this is an illustration. In practice, it's a thread pool, which is limited by memory available, and is magnitudes of order less than what an event look can support. Thanks for the comment, though
Dean Radcliffe
Damn, this is an oldie but goodie. I give talks just like this, and may borrow your slides. In light of these original intentions of node to do awesome things like queued db writes, and server-push, it's surprising how most node apps today are still built on the request/response model and synchronously (but non-blockingly) waiting on db writes.
Dean Radcliffe
Damn, this is an oldie but goodie. I give talks just like this, and may borrow your slides. In light of these original intentions of node to do awesome things like queued db writes, and server-push, it's surprising how most node apps today are still built on the request/response model and synchronously (but non-blockingly) waiting on db writes.
Ulyana
Great insides, thanks for the article. Node.js do has plenty of advantages: it's lightweight, efficient, and gives an ability to use Javascript on both front-end and backend opens new possibilities. However, it also has drawbacks you should keep in mind. We have tried to describe some in the article https://www.netguru.co/blog/pros-cons-use-node.js-backend Your opinion would be appreciated a lot.
Ulyana
Great insides, thanks for the article. Node.js do has plenty of advantages: it's lightweight, efficient, and gives an ability to use Javascript on both front-end and backend opens new possibilities. However, it also has drawbacks you should keep in mind. We have tried to describe some in the article https://www.netguru.co/blog/pros-cons-use-node.js-backend Your opinion would be appreciated a lot.
Maq Said
Amazing Article. MongoDB I have never explored. Can you tell more about it and why does it go well with Node.Js
Maq Said
Amazing Article. MongoDB I have never explored. Can you tell more about it and why does it go well with Node.Js
Misha Kov
This is exactly the article I was looking for, Examples where Node.js can be used! Thanks!
Misha Kov
This is exactly the article I was looking for, Examples where Node.js can be used! Thanks!
Jessica Barnes
Node.js has the concept of asynchronous execution of Input-output based events through a thread pool. And it concentrates in execution and topping well for low-CPU, highly I/O-bound operations. Just starting to work on Node.js will allow a <a href="https://hirenodejsdeveloper.com ">developers</a> to analyze how to exploit it for maximum performance.
Jessica Barnes
Node.js has the concept of asynchronous execution of Input-output based events through a thread pool. And it concentrates in execution and topping well for low-CPU, highly I/O-bound operations. Just starting to work on Node.js will allow a <a href="https://hirenodejsdeveloper.com ">developers</a> to analyze how to exploit it for maximum performance.
Janguk James Lee
This is a pretty good article motives me to take on Node.js
Janguk James Lee
This is a pretty good article motives me to take on Node.js
Magdalena Mbn
if they ca'tn learn how to handle pointers they can't program
Magdalena Mbn
if they ca'tn learn how to handle pointers they can't program
Orderama Web
TwaT - can you tell me which pub/bar you visit so I can avoid you. I wouldn't be surprised if you OrgASM when you read back your comments.
Orderama Web
TwaT - can you tell me which pub/bar you visit so I can avoid you. I wouldn't be surprised if you OrgASM when you read back your comments.
philippe
I'd rather have more Java to the client side than more Javascript on the server side. Refactoring Javascript is a nightmare. Whoever work on software with 4000 - 10000 classes like i did knows what i am talking about. I see the threading management as a plus ( if you target to run a site like Facebook otherwise you dont care. Your static content will use cloud flare are 4000 connections AT THE SAME TIME is just insane traffic so i would not compromise maintenance VS scalability ) Not valid from intranet applications at least. I curious if future version of Tomcat will use the reactor pattern, Java itself does provides support for this. You can deal with static content using Nginx which has the reactor pattern implemented https://www.pascaldimassimo.com/2011/02/10/java-and-the-reactor-pattern Still for dynamic pages i haven't found any clues. A thread does not hold the session context so i am really skeptical about having 2Mb in there.Unless poorly coded.
philippe
I'd rather have more Java to the client side than more Javascript on the server side. Refactoring Javascript is a nightmare. Whoever work on software with 4000 - 10000 classes like i did knows what i am talking about. I see the threading management as a plus ( if you target to run a site like Facebook otherwise you dont care. Your static content will use cloud flare are 4000 connections AT THE SAME TIME is just insane traffic so i would not compromise maintenance VS scalability ) Not valid from intranet applications at least. I curious if future version of Tomcat will use the reactor pattern, Java itself does provides support for this. You can deal with static content using Nginx which has the reactor pattern implemented https://www.pascaldimassimo.com/2011/02/10/java-and-the-reactor-pattern Still for dynamic pages i haven't found any clues. A thread does not hold the session context so i am really skeptical about having 2Mb in there.Unless poorly coded.
Cody Donelson
Event though the article is a few years old it brings up some great points about Node.js. Reading through the comments I've seen some posts about how Node.js is a wonderful thing, and others about how the leading languages are C#, Java, or Ruby. We know that JavaScript is going to offer some complexities as it relates to Object Oriented Programming, Object Relational Mapping, relational databases, and more. I think most developers/project managers are losing sight of what makes JavaScript and Node.js (as well as AngularJS) so wonderful. We were able to implement a client side language on the server side and make it do the exact same thing as any other server side language. I personally love using Node.js, although it was difficult to wrap my head around being fully immersed in a type-less language. Once I grasped the fact that the sky was the limit when it came to my objects and that I didn't have to map my objects from one type to another (like you would in C# or Java) my ability to write a code that performed quickly and effectively grew. I've recently been teaching a couple PC techs at the company I work for the ins and outs of programming. My boss is very adamant that Node.js is the way of the future (especially the deprecation of Java plug-ins within the coming years) I would tend to agree. It's lost on me as to why there's such an argument as far as objects are concerned in Node.js/JavaScript. I find it easier to use objects and I can use them more dynamically BECAUSE of JavaScript. Very soon I'll be implementing HTML properties within objects for my Express 4 applications. I've found that PUG (formerly Jade) is extremely capable of handling objects and arrays, thus, making it easier for someone to dynamically change a type, a value, or a tag, based on the object that gets sent through a GET or POST request. I believe once everyone gets on board with understanding the way Node.js operates, how you can effectively implement standards that are usually enforced in typed languages, and over the fact that Node.js has some quirks about it, will we truly be able to move forward and make this language as powerful as the languages that came before it. Lastly, I'll add that the ability to utilize Node.js virtually anywhere makes it that much better. Whether its an Express application deployed on a Linux server, an Electron application that's deployed on a terminal server, Node.js is practically a perfect fit for whatever amount of work that needs to be done.
Cody Donelson
Event though the article is a few years old it brings up some great points about Node.js. Reading through the comments I've seen some posts about how Node.js is a wonderful thing, and others about how the leading languages are C#, Java, or Ruby. We know that JavaScript is going to offer some complexities as it relates to Object Oriented Programming, Object Relational Mapping, relational databases, and more. I think most developers/project managers are losing sight of what makes JavaScript and Node.js (as well as AngularJS) so wonderful. We were able to implement a client side language on the server side and make it do the exact same thing as any other server side language. I personally love using Node.js, although it was difficult to wrap my head around being fully immersed in a type-less language. Once I grasped the fact that the sky was the limit when it came to my objects and that I didn't have to map my objects from one type to another (like you would in C# or Java) my ability to write a code that performed quickly and effectively grew. I've recently been teaching a couple PC techs at the company I work for the ins and outs of programming. My boss is very adamant that Node.js is the way of the future (especially the deprecation of Java plug-ins within the coming years) I would tend to agree. It's lost on me as to why there's such an argument as far as objects are concerned in Node.js/JavaScript. I find it easier to use objects and I can use them more dynamically BECAUSE of JavaScript. Very soon I'll be implementing HTML properties within objects for my Express 4 applications. I've found that PUG (formerly Jade) is extremely capable of handling objects and arrays, thus, making it easier for someone to dynamically change a type, a value, or a tag, based on the object that gets sent through a GET or POST request. I believe once everyone gets on board with understanding the way Node.js operates, how you can effectively implement standards that are usually enforced in typed languages, and over the fact that Node.js has some quirks about it, will we truly be able to move forward and make this language as powerful as the languages that came before it. Lastly, I'll add that the ability to utilize Node.js virtually anywhere makes it that much better. Whether its an Express application deployed on a Linux server, an Electron application that's deployed on a terminal server, Node.js is practically a perfect fit for whatever amount of work that needs to be done.
Gage Poon
Lightening fast, lightweight, smoother development and better performance these are some of the revolutionary changes brought by Node js in the web development field. Node js offers the freedom to creativity, abundant resources like NPM (Node Package Manager), which is a shared library of modules and tools. Additionally, web applications developed using this web development framework are more scalable. This JavaScript framework is very popular among the startups. However, big names like Netflix, Paypal, eBay, Microsoft, Uber, DivBox.in etc. are also using this feature-rich web development framework.
Gage Poon
Lightening fast, lightweight, smoother development and better performance these are some of the revolutionary changes brought by Node js in the web development field. Node js offers the freedom to creativity, abundant resources like NPM (Node Package Manager), which is a shared library of modules and tools. Additionally, web applications developed using this web development framework are more scalable. This JavaScript framework is very popular among the startups. However, big names like Netflix, Paypal, eBay, Microsoft, Uber, DivBox.in etc. are also using this feature-rich web development framework.
rajivkumar bonam
what is node js how to write code in node js
rajivkumar bonam
what is node js how to write code in node js
Minarchism Leads To Freedom
Great article, thanks.
Minarchism Leads To Freedom
Great article, thanks.
csps1343
Nice <a href="https://www.cspsprotocol.com/category/node-js/">node.js tutorials</a>, thanks for sharing.
csps1343
Nice <a href="https://www.cspsprotocol.com/category/node-js/">node.js tutorials</a>, thanks for sharing.
Rahul Raut
thank you so much.. learn node <a href="#">https://monkelite.com/what-is-node-js-learn-step-by-step/</a>
Rahul Raut
thank you so much.. learn node <a href="#">https://monkelite.com/what-is-node-js-learn-step-by-step/</a>
Chapter247- Software Dev
"Why The Hell Would I Use Node.js? A Case-by-Case Tutorial". Every beginner must required to read this article. It's so easy to understand main Node.Js concept and programming overviews. <a href="https://www.chapter247.com/nodejs-development-services/">Hire Node js development company</a>
Sam Watt
Wow, this is a very detailed and insightful article based on cases. I loved reading it, and hoping to see more such articles. Thank you.
ThinkStart Pvt Ltd
Useful post. Thanks you for sharing this wonderful information.
w3villa
Hi, I like to read your informative blog! Thanks for sharing!
Marie adams
I made several successful investments with this broker before losing 40% of my savings to the trading scam. It cost me so much money and pain to invest in an investment that was not even real. I was able to recover the majority of the funds, and we are still attempting to recover the rest. I highly recommend SECURE TO INVEST WELL for anyone involved in an online trading scam Trading scam $350,000 recovered BELOW IS THEIR CONTACT: secure2investwell@gmail.comcall/whatsapp: +14638887391
Marie adams
.................. I made several successful investments with this broker before losing 40% of my savings to the trading scam. It cost me so much money and pain to invest in an investment that was not even real. I was able to recover the majority of the funds, and we are still attempting to recover the rest. I highly recommend SECURE TO INVEST WELL for anyone involved in an online trading scam Trading scam $350,000 recovered BELOW IS THEIR CONTACT: secure2investwell@gmail.comcall/whatsapp: +14638887391
Joshua Flynn
Very well written but you could do the same thing using a regular lamp stack with JQuery via AJAX calls like all instant messengers in the past have done with no complications? Even after reading this article I still believe that a Lamp stack with JavaScript and AJAX calls could do the job just as easily but without the complications of understanding the overly complex ecosystem that Node has become. I have read hundreds of articles around the web about why someone should use node but they all cover something that could be done with technology we had back in the 90s. so what is so special about node that I should learn it verses staying with 30 year old technology that has powered the same types of applications that you mentioned in this article 15 years before node came about and back when dial-up was fast. So if it was fast enough to do the same thing over a dial up connection what has node done too improve the ecosystem of the internet.
Cybertron Technologies
Thanks for the great information. I learned a lot from your article.
comments powered by Disqus