The experience of creating my own JavaScript runtime - 2

The experience of creating my own JavaScript runtime - #1

The first steps

Creating a JavaScript runtime overnight is not a relatively simple job, but it sure is a lot of fun and requires an absurd amount of knowledge about how the entire technology ecosystem works.

This doesn't mean that I already started knowing, in fact, at the beginning I was just a very lay person in relation to these deeper questions about the development of internal technologies - that having spent 5 years working mostly with tooling, libraries and support of projects.

I created this runtime and now I'm trying to turn it into a fast and scalable open source solution for everyone.

As I said in the last article, first it was all just an idea, a hobby, I was looking for things to recreate from scratch, test my current technical situation - regardless of language. That's when I got the idea: "Why not create a Node from scratch? We have Jint for that!".

The way people utilize technologies these days, as well as the super population of average developers makes me want to compare the existence of this inner "underworld" to Plato's allegory of the cave - people using only what comes ready for them, without exploring what really exists behind so much technology, the outside world.

Understanding Jint and creating a console

Jint is a JS interpreter with an integrated engine built in C#, like V8, he is responsible for all the base code execution as well as EcmaScript implementations such as default constructors, syntax, Promises... I studied its features in depth to start and it was a bit hard (in the beginning).

After struggling to find a good way to use external JavaScript bindings with Jint, it was time to choose where to start: and why not the infamous console, father of all debugs? I implemented it as a bind to Console.WriteLine + extras (like serialization with Netwonsoft.Json).

Creating the basic and implementing Ts-By-Default

Recreating all the basics of a runtime is tiring, very tiring, but it's a relatively easy job: libraries std, application, environment, all were relatively simple bindings but complex to build.

TypeScript is life, so in the projects generated by my runtime it is a fundamental part. To do the implementation it generates an NPM pseudo-project and implements Webpack and Babel behind the scenes, creating a final bundle that will be executed.

Implementing Docker support

It wasn't easy - although the final solution turned out to be completely simple and it always crossed my eyes. Melon (my runtime) is based on both .NET and an NPX command, so I needed to find a way to concatenate the two technologies in order to run it inside Docker - and I managed to synthesize all of that into a Dockerfile.

What now?

I don't have big plans, this is a project that is giving a huge boost to all my development knowledge, devops, bundlers, asts and many other things, besides being completely Open Source. I'm occasionally posting new stuff about it on my twitter profile and soon I'll bring more technical articles about it here.

Repository

https://github.com/MelonRuntime/Melon