search

reactiverse / es4x

🚀 fast JavaScript 4 Eclipse Vert.x
https://reactiverse.io/es4x/
Apache License 2.0
882 stars 75 forks source link

Not supporting native node modules is such a deal breaker! #479

Closed techsin closed 3 years ago

techsin commented 3 years ago

If I'm gonna abandon much of npm packages then i might as well just use different language that is faster like Rust or Go.

pmlopes commented 3 years ago

The reasons are simple, es4x runs on graaljs, not v8, so the native node modules are not present. This project isn't unique in this approach, others such as deno also do not support native node modules.

It is a design choice that has its pros and cons. It suits well for server side applications and has been shown to perform better than many node frameworks (or Go for the sake of it) https://www.techempower.com/blog/2020/05/28/framework-benchmarks-round-19/ At the cost of using a different set of modules.

techsin commented 3 years ago

would it be possible to keep the api same, port over those modules.. technically?

pmlopes commented 3 years ago

Technically yes, but it would be a very long task to accomplish. For example, the net module. This module is very tighly coupled to libuv which is also not present in es4x or even graaljs. Graaljs is purely a JavaScript runtime has no modules. In es4x My goal was to exploit performance, so after measuring, the combo netty + graalvm this was giving me more thoughput/less latency than node. However netty is quite low level so there comes vert.x. Vert.x has an API that resembles node APIs and builds on netty. It also has been built with polyglot in mind, so the public APIs are annotated to allow codegen tools to generate bindings easily.

If you see the project code, it's quite small: https://repo1.maven.org/maven2/io/reactiverse/es4x/0.14.0/ the main jar file is just 70kb. What is happening is that the supporting tools use vert.x codegen framework to generate the typescript definition files for the public vert.x APIs so it gets simple to use them from js.

So building the net module is totally possible but you need either map all it's API to netty (for example) or vert.x if you want a easier to use api, or take the hard task of porting libuv which is even more complex and benchmarks show that it will not be as fast.

techsin commented 3 years ago

Thanks I didn't know that.