I wonder if a new implementation of JavaScript was needed. My first hunch would have been to try Fabrice Bellard's QuickJS: https://bellard.org/quickjs/

It definitely wasn't needed, but it goes against what I think makes SerenityOS so special.

That being that everything in SerenityOS and its several related projects is made from scratch.

> If you wish to make an apple pie from scratch, you must first invent the universe.

They are using Qt and C++. They have chosen where to draw a line, which is fine, and that line happens to be on the other side of "Javascript Engine".

They are not using Qt in Serenity, only on Linux in order to hook up painting and events.

Also, they are making a new programming language (Jakt) to replace a lot of the C++

To be fair Qt is just to create the window on Linux, but all the browser internals are their own.

It's also being used for networking.

For now…

Everything is from scratch on SerenityOS. Ladybird takes as much of that as it can but the is not afraid to use existing tech for the bits of Serenity that cannot currently be used on Linux ( the GUi framework and networking ).

I think they'll replace Qt with their own GUI lib eventually - and they're already building their own language to replace C++ (for their uses I mean)...

> they're already building their own language to replace C++

Of course, every respectable software project sooner or later invents its own language!

I guess a precise defition of the line would be something like "no third party code dependencies"

Qt is not third party?

for their operating system (serenityOS) they're not using any dependencies, they have their own windowing framework. for the cross platform version of the browser, they use Qt instead. but on serenity itself the browser does not use it.

fair enough

Well... not if you're using KDE as your window manager?

Evidently the line is a curve and did not include a third party JS engine, since the project doesn't include a third party JS engine.

I know. I think you did not understand my comment.

This actually makes a lot of sense, especially when you consider that WASM is now a thing.

It's worth noting, as I'm sure you already noticed, that they are supporting WASM in addition to JS. So maybe the right answer for "your simple, secure bytecode JS interpreter is too slow" really is "Just precompile that slow part to WASM".