Design nucleus.

[creationix]

The basic goal of this project is to implement a tiny core runtime that contains libuv, javascript and some essential C libraries (like openssl) needed to re-implement node.js in userland as modules.

If possible this will be backend agnostic and allow multiple JS engines.

See also nodejs/node#7098

[creationix]

I think a first step would be to define an interface which all backend implementations should adhere to. One of the goals here is to avoid C/C++ addons so we don't need to worry about a public facing C or C++ API for addons initially.

Since it's a royal pain to try and get all JS engines to conform to a least-common-denominator interface, let's instead have independent implementations for each engine that all match some JS interface spec. Then modules written for one runtime will work for all so long as they don't use language features unique to a particular runtime (V8 and Chakra for example have most/all of ES6 while duktape is mostly ES5, but has lua style coroutines).

Once he have a common interface, we can start implementing the C parts for the various runtimes. I humbly suggest the I/O parts be directly designed to match libuv.

[Fishrock123]

I think this will also be greatly simplified if we use things such as @mscdex's work to make the dns resolver be pure-js and not use c-ares nodejs/node#1843, and the http-parser: nodejs/node#1457

[Fishrock123]

I think a first step would be to define an interface which all backend implementations should adhere to.

Sounds like @trevnorris's original API WG goals.

[trevnorris]

:-) I've had a long-standing goal to create an API for node that serves as a strict entry point into C++, which basically all code in lib/ would use. Alas, time constraints.

[mscdex]

As I mentioned in the linked DNS PR, it is difficult to get even close to matching the performance of c-ares/libc, even when using node's C++ UDP bindings directly. That pretty much rules out any performance issues in js land, so the C++ layer would have to be improved (if possible) to be able to compete with c-ares and/or the system resolver.

Regarding http, I haven't compared benchmarks since @indutny incorporated the JS stream stuff that bypasses js land when doing http parsing, so I'm not sure how the pure js http parser fares anymore.

[creationix]

As far as DNS resolving, in luvit we have two paths. One is pure lua on top of libuv's UDP primitives and is used for advanced queries. For basic resolving domain names to ip addresses, we use libuv's getaddrname and getaddrinfo which uses the system library on a thread-pool I believe. We have had no performance issues with this. Both are pure script on top of what libuv provides natively which will be provided in the the C core.

[creationix]

Let's not get too tripped up on edge performance issues. The goal here isn't to win synthetic benchmarks with the vanilla flavor of the minimal core. We will have options where people can build different flavors of the core with various libraries included (like openssl, cares, http_parser, etc). If you're deploying a large enough system where these performance issues are actually a problem, then you don't mind compiling a little C code. But for most projects and development workflows, this is not critical.

In luvi, there are two main flavors known as "tiny" and "regular" with the biggest difference being that regular includes openssl and a couple lesser used C addons in it's core. For many cases, http servers don't need openssl since they are running behind a reverse proxy anyway that handles the TLS termination. Things like MD5, SHA1, etc can usually be handled just fine (and sometimes even faster) in pure script.

[indutny]

Wow, I really like this proposal. I was working on something similar recently:

• https://github.com/indutny/uv_link_t
• https://github.com/indutny/uv_ssl_t
• https://github.com/indutny/uv_http_t

It is a modular C stream implementation. Not sure how useful it is, but it could be a good enough interface for interactions between C addons.

[creationix]

@indutny I saw those. I've always said libuv should have an extension community where things are written in C and can be used by all runtimes that consume libuv. Those could be included as well in the core if they are tiny (which I expect) and in optional addons if not.

If they are only to be consumed by other C code and it doesn't make sense to expose them to JS, that's fine. It will still be useful for addons to core that can use them.

[creationix]

I started a new issue for designing the libuv -> js mapping interface that all implementations must adhere to. #2

[indutny]

uv_link_t by itself is very small. uv_ssl_t is a bit bigger.

[creationix]

So I think we could say a nucleus implementation contains:

1. A JS runtime engine
2. libuv
3. Bindings to libuv for said engine (exposing the standard interface)
4. Glue to make applications.
5. Other optional C modules.

I think for part 4, we should follow the pattern in luvi. This means including minimal code for reading zip files. I have a modified version of miniz that I've bugfixed and added missing features that works great for this and is super tiny.

This will expose a bundle API that allows scripts to read in the virtual filesystem that can either be a zip file (standalone or appended to nicleus) or a folder on disk.

We will also have some minimal hooks that makes bootstrapping a require system in userland less painful. For example, it can look for a file bundle:deps/require.js or something and auto-run it if it exists before running bundle:main.js.

[mmicko]

Do not wish to disappoint you but there is already something similar in works https://github.com/saghul/sjs

Have to say I am interested in this kind of projects, since I think those can replace LUA with JavaScript (that more people are common with) to be used for scripting their software. Also there is large library of nodejs compatible javscript modules, making it possible to be used from application itself would be a great plus.

My suggestion would be to to go for C++11/14 support, and not just plain C. Exposing API and enabling user to expose their classes into JavaScript is very useful. There is LuaBridge project done for LUA that enables you to expose your classes and objects to a LUA engine. Doing similar out-of-box solution would make integration with user code even easier.

Note that Lua and duktape are quite similar in design so similar patterns can be used.

If you go this or similar way "you have my axe" :)

[dlmanning]

Am also super into this.

Plain C makes for easier interop with whatever other language one might be interested in calling from, (e.g. rust).

[creationix]

@mmicko I'm not disappointed, I know about sjs and even linked to it in the parent conversation in the nodejs issue. From my initial browsing however, sjs is much higher-level and opinionated than this project is aiming to accomplish.