ES2C

This project aims to compile Ecmascript to C. Why? Because, to run a simple javascript piece of code, you need to bundle with it about 20 megabytes worth of an engine, that can do a thousand other things you don't care. By compiling the JS code straight to C, it can statically link to a runtime, and all parts that aren't needed will just be removed from it - you never use symbols? Symbols just won't exist in your final executable.

Another pro is that you can use JS as a systems language - since it is getting compiled straight to C. This means that, without too much overhead (other than the overhead of converting the values), you can get a powerful and extremely efficient FFI.

Finally, you can write mixed JS and C code, which can allow for very expressive (and efficient) code. The core of an application could be written in C (or even C++, if that floats your boats), and the rest could be written in JS.

How do we intend on achieving this?

Since a lot of self-hosted JS parsers exist, one of them could simply be used to compile EcmaNext code to C - it's a (somewhat) simple tree transformation problem. From there on, we just get an off-the-shelf C compiler, and compile the code, linked with a specially-crafted runtime.

The runtime

The provided runtime will consist of two main parts: the garbage collector and the semantics. This is to allow for a better swap-in replacement of the GC, as, to be honest, I do not trust myself to write a decent garbage collector. The runtime's philosophy is for its API to be sane, aka, for a human being to be able to write code that will interoperate with JS using it, without going completely bananas. Another requirement for it is to be dead simple.

What this project is NOT

This project doesn't aim to produce near-C efficiency. I'd be happy if I get down to 5 times slower than C. What this project aims to do is to turn JS into a systems language. Another thing this project is not going to do is to aggressively optimize your code - some simple checks might be performed to not emit retarded code, but we aim to emit code that somewhat closely represents the input JS code. Of course, the runtime might implement some constructs like shapes and inline caches, but we won't go too far in the optimization direction - it just isn't too necessary.