- Make node.js Core Bigger
- Originally written by Mikeal
- The Nuggets translation Project
- Translator: imink
- Proofread by jifaxu FrankXiong
Defend the use of a more powerful Node.js core
Node.js has the smallest standard library compared to other platforms. Combined with powerful ecological tools such as NPM, Node.js has been a huge success.
This success has led to a culture of Node.js development that tends to use smaller reusable modules, larger ecosystems, and smaller core libraries. There have been calls to make node.js’s core library smaller.
Spotlight #6: “Small Core” – Keeping Node Core Small with Sam Roberts and Thomas Watson
Getting people excited about the ecosystem is what Node.js is good at, and the standard specification of Node.js for third-party libraries helps the ecosystem a lot.
As new technologies continue to emerge, the Node.js core needs to establish a standard specification for compatibility so that the Node.js ecosystem can flourish.
Not using require(‘ HTTP ‘) would be a disaster.
When Node.js first emerged, all similar platforms had a canonical way of associating HTTP “servers” with “frameworks.”
CGI (Perl), WSGI (Python), and Rack (Ruby) are essentially the same thing, and programmers build apis through Web frameworks to analyze HTTP. This is especially important for low-concurrency platforms, where programmers can rely on external Web servers (Apache, Nginx, etc) to manage incoming connections while parsing HTTP.
When Node.js started in 2009, CommonJS had already defined a similar specification for JavaScript called JSGI. Service support for the specification already exists on other JS platforms, such as Narwhal, and implementations of node.js versions are coming soon.
Isaacs, an early Node.js contributor and later NPM author, developed a version of JSGI called EJSGI (EVented-JsGi) that is compatible with node.js’s asynchronous concurrency model; But this is not the end of Node.js.
In contrast, Node.js goes further than other platforms. Node.js basically defines the “framework” layer of apis and ties it to the entire server implementation. On the surface, Node.js has a smaller standard library than its contemporaries, but it actually goes further than it did in its early days.
Back in 2009, you could see the problems facing Ruby and Python and many other Web frameworks. Module diversity is beneficial to the ecosystem only if modules are compatible with each other. Most frameworks invent vertical plug-in systems that are compatible with themselves, but those plug-ins end up not being compatible with other frameworks.
Node.js’ decision to define a framework layer reverses the aforementioned trend by forcing modules built on the HTTP layer to be equally compatible with each other. When the framework is finally presented, it actually extends the standard library, rather than inventing an API that only works with itself. This means that most modules serving different frameworks are compatible with each other, and those used to build “standard” HTTP apis are compatible with any framework.
Node.js is getting a lot of attention for having one of the largest ecosystems in the world. The fact that such a large ecosystem can maintain a high degree of compatibility between modules compared to other platforms is even more impressive. This compatibility is actually a result of the standardized specifications defined at the core of Node.js, such as Stream, modularity, error-first callbacks, and lesser-known apis such as require(‘ HTTP ‘).
Standardization is at the core
There is definitely a burden of maintaining reference Implementations of the standard library sample implementation. Node.js’s built-in Stream library is always several versions behind NPM. But that doesn’t mean he’s not part of the core
In order for the library to be truly scalable and reliable in the ecosystem, these standards and specifications must be incorporated into the core. There are many excellent standard libraries out there outside the node.js core library ecosystem, but none of them are being taken for granted.
The Abstract Blob Store is an excellent standard library that I wouldn’t miss. However, many influential Node.js developers feel that it is not yet reliable enough to use in specific projects. Several cloud service providers still don’t have implementations of the library, and it is far from being used by default compared to the standard libraries that have been normalized by the core of Node.js.
The reason we keep many libraries out of the core library is to encourage innovation in the ecosystem. Normalization is a process that does not promote a particular type of innovation. By incorporating these standard specifications into the core of Node.js, we hope to prevent competition between specifications in the ecosystem.
In the future, we will add some new technologies to Node.js, such as THE HTTP/2 API, because we want to add SUPPORT for HTTP/2 like we did for HTTP/1.1 to keep the ecosystem highly compatible.