Node.js is not a perfect product, it has drawbacks (using JS?), Some of them dragged on from an early stage of development due to erroneous decisions made by Ryan Dahl, which were briefly recalled in the article How did the creator of node.js get frustrated in it . As is often the case, in some cases it is difficult or impossible to find an alternative to this system, especially in the enterprise sector. But if you do not need to support a large legacy code, which will supply programmers with work for many years to come, then you can look towards other solutions. You can read about the "Node.js killer" in the article mentioned above, some others will be discussed in this article.
ASP.NET
"An old friend is better than two new ones". ASP.NET has a long history. The Active Server Pages technology, which formed the basis of ASP.NET services, was developed at the end of the last century. Of course, development time is not always a good thing, but the long life of a product speaks volumes. Although ASP.NET has a completely different principle of operation, it is not just an environment for running program code and connecting modules, it is a platform for creating web services; it is often used to solve problems similar to Node.js.
If Node.js is the brainchild of a small team and in its most basic form is an environment for launching JS programs outside the browser with access to I / O, then ASP.NET is a typical product of a huge corporation. It initially contains a large number of default libraries that immediately allow you to start developing. Node develops thanks to the developer community, and therefore the system must first be equipped with all the necessary modules, which are simply incredible. The simplest "Hello world!" on Node will drag several thousand files into the system. Moreover, the quantity does not always grow into quality, sometimes it seems that the developers are even ready to cram “i ++” into a separate module, which will then be downloaded a million times, and a sudden update or removal of this package will cause serious compatibility problems or crash npm.In ASP, security and updates are monitored by the Microsoft ecosystem, libraries written by it and other large companies are carefully checked for errors and compatibility issues ...
Despite many differences, one of the main ones is a different approach to the distribution of computations. In Node.js, everything was done in a single thread, but using asynchronous I / O. ASP originally worked in multithreading and synchronous I / O. The first option shows great performance when the services require very intensive exchange, but at the cost of some complication of the code. In the latest versions of products, these differences are ironed out, in Node.js and ASP.NET, the async \ await pattern is used.
JS has grown a lot during its development, but it still remains a language without strong typing and loses to C #, which was originally developed under the direct influence of C ++, which from the early days had strong typing and OOP. The consequence of this is that C # is more powerful and more consistent, and does not require add-ons like TS. But on the other hand, JS, due to its simplicity, is more in demand when programming microservices, which does not require complex C # capabilities.
In addition to the differences in the programming languages used, these platforms have different ideologies. In ASP.NET, a lot is predefined, it offers everything ready-made, starting with the file structure, while starting to work with Node.js, you have to choose everything yourself, which gives a lot of flexibility, but complicates development. But ASP.NET has powerful debugging, testing, and refactoring tools.
The only thing ASP.NET is seriously inferior to Node.js is ease of deployment. Node only needs an engine and a proxy or Docker. The platform can be configured either by yourself or you can take a ready-made VPS image, which is available from almost any hosting provider. For ASP, despite the cross-platform, everything is not so easy, and ready-made images for servers are available only to the largest players of the Azure level.
Is JavaScript really necessary?
Node.js was created as a runtime for JS, because it is a simple and accessible programming language, with which it was easy to implement the simultaneous execution of multiple scripts for two-way communication of web application data between the browser and the server. ASP.NET was also created for writing web applications, only using other methods. The same Deno consists of several layers above the virtual machine, which directly works with the server resources. But it is not necessary to use complex wrappers from programming languages that do not run directly on the server and require virtual machines.
Go
In 2007, the company's engineers decided that C ++ did not meet the current realities of computer technology. Efficient parallelization tools were required, using the capabilities of multi-core processors and distributed systems, an automatic garbage collector and some simplifications were needed for better code readability and ease of working with types.
The goal of the developers was not to create a “better version of C ++,” but to make the new language clearer based on their programming experience. Go was publicly announced in 2009 and quickly rose to almost the top 10 programming languages (13th in early 2012). Raymond Dahl himself praised it in expressions like: "Why Node.js, if there is such a beautiful language like Go?". But the novelty passed, and the language was almost forgotten until it turned out that its parallelization tools were well-suited for developing microservices in web applications. This returned the language to its former popularity.
Several web frameworks have been written for Go, although it is not necessary to use them, because out of the box it has all the functionality necessary for programming web applications. Deno was originally written in Go.
Ruby
Compared to the same Go, this is not the newest language, it was released in 1995. Unlike Go, it was developed by a lone enthusiast, Yukihiro Matsumoto, who was eager to create an object-oriented, interpreted language that was better than Pyton. The language did not gain popularity immediately, not least because for the first couple of years its documentation was only in Japanese. Books in English were not published until the early 2000s, and recognition came with the release of the Ruby on Rails web framework in 2005, which quickly became popular, especially when Apple announced in 2007 that it would ship with Mac OS X 10.5. ...
As with all interpreted languages, Ruby's speed was relatively slow, which greatly affected the performance of web applications written in Ruby on Rails. Knowing this problem, the author began to develop a version of the language that would lose backward compatibility, but would run much faster, which he did in 2009. The speed has increased significantly and is equal to web applications running under .NET and JVM. Thanks to this, the popularity of the framework has skyrocketed. In 2018, the author of Ruby released version 2.6, which implements dynamic compilation, which further accelerates the performance of applications.
Until now, the Ruby language is closely associated with the Ruby on Rails framework.
Elixir
Erlang is another programming language created by a large corporation. This time the Swedes from Ericsson did their best. In 1986, no one thought about developing web applications, the Internet was still in the project, and the language was created to run systems in real time. For a long time Erlang was practically unknown outside the company, which used it for its internal needs, until in 1998 the management decided to stop supporting its own language and banned its use, obliging developers to switch to Java. This led to the language being released under an open license, and it began to be distributed outside of the company that developed it. For a long time, it was interesting only to a small circle of scientists, until it turned out that its concept is well suited for development for multiprocessor architecture.
In 2012, Jose Walim, one of the Ruby on Rails developers, got the idea to create a programming language for high-load systems and large websites. As a result, Elixir was developed , a functional programming language compiled to bytecode for the Erlang virtual machine (BEAM). Due to the fact that the language is based on Erlang, which was developed for programming communication equipment, Elixir received unique properties: fault tolerance, hot code replacement(changing or rolling back the code of a running program, without restarting it) and the ability to work in real time. These properties allow you to create reliable high-load systems that support both horizontal and vertical scaling, operating 5-10 times faster than similar applications written in interpreted languages (PHP, Ruby, Python). The creator's place of work influenced the fact that the language uses Ruby-like syntax, and it is easy to learn for those who use Ruby on Rails.
Elixir is currently used by well-known companies such as Discord, Square Enix, PepsiCo, and Sketch.
And if, after all, JavaScript?
But if it is impractical to master a new programming language, how to drag the whole Node to the server? You can look at other JS runtimes.
RingoJS is a multi-threaded platform built on the JVM and optimized for running on servers. To interpret JS code, the Mozilla Rhino engine is used, which has an impressive history. It began to be developed in 1997, back in the days of Netscape, later the project was transferred to the Mozilla Foundation and posted in open source.
RingoJS applications can be deployed on any Linux platform, up to the Raspberry Pi, or on top of cloud platforms like Google App Engine. RingoJS is a modular system based on CommonJS, you can even use some modules from Node.js. Also, Ringo engine allows you to integrate libraries written in Java.
PurpleJS is another simple JS framework that runs on the JVM. Nashorn (also a rhino) developed by Oracle is used as the JS engine. This is not to say that this is a full-fledged replacement for Node, because the framework does not use asynchronous mode, and Nashorn does not have CommonJS support, but it is very lightweight and does not require restarting the service after changing the code.
Vert.xIs no longer a framework, but a multilingual set of tools that allows you to create fully asynchronous reactive web applications, microservices and network utilities that run on the JVM. The supported languages are not limited to Java and JS, except for them you can write applications in Groovy, Ruby, Scala and Kotlin, a modular system with a centralized repository is supported, Vert.x is easily expandable and scalable.
It's funny that the project was first called Node.x, then it was renamed to avoid legal problems, because the goals when creating were the same as those of Node.js, and Tim Fox (creator of Vert.x) said that he was inspired by the success of Dali and “I wanted to make Node.js in JVM”.
If the alternatives aren't impressive and node.js remains your love
node.js
