←back to thread

Show HN: Nova JavaScript Engine

(github.com)
268 points aapoalas | 4 comments | 17 Nov 24 23:07 UTC | HN request time: 2.287s | source

We're building a different kind of JavaScript engine, based on data-oriented design and willingness to try something quite out of left field. This is most concretely visible in our major architectural choices:

1. All data allocated on the JavaScript heap is placed into a type-specific vector. Numbers go into the numbers vector, strings into the strings vector, and so on.

2. All heap references are type-discriminated indexes: A heap number is identified by its discriminant value and the index to which it points to in the numbers vector.

3. Objects are also split up into object kind -specific vectors. Ordinary objects go into one vector, Arrays go into another, DataViews into yet another, and so on.

4. Unordinary objects' heap data does not contain ordinary object data but instead they contain an optional index to the ordinary objects vector.

5. Objects are aggressively split into parts to avoid common use-cases having to reading parts that are known to be unused.

If this sounds interesting, I've written a few blog posts on the internals of Nova over in our blog, you can jump into that here: https://trynova.dev/blog/what-is-the-nova-javascript-engine

1. aapoalas ◴[18 Nov 24 14:29 UTC] No.42172547[source]▶
There is a hidden agenda here: The engine is somewhat up to the gills with feature flags, and I'm planning on adding more. Say, for instance, array indexes being individually definable and the existence of holes? That whole can of worms makes JS Arrays a pain to implement in a performant fashion. Worse yet, it's a feature that is basically never used: No one wants holes in their Array and no one wants getters or setters in them either.

So, say you have a nice flag to turn the feature off: You turn it off and test your code; nothing breaks and the engine thanks you by running faster. Nice! So you leave it off. A few years down the line you start to wonder: Why didn't we do this from the get go? And maybe, just maybe, this will push the ecosystem and the language itself towards sanity. We cannot break the Internet, but we sure as hell can break a bunch of old NPM libraries that no one uses anymore.

Be the change you want to see, and all that. Though, if the change you want to see is for JavaScript to die then... Well, then this definitely isn't the revolution for you :D

2. liontwist ◴[18 Nov 24 15:20 UTC] No.42173126[source]▶
Please share your plan for how to make millions of existing web pages better.
replies(1): >>42173710 #
3. dankobgd ◴[18 Nov 24 16:06 UTC] No.42173710[source]▶
Why not make future pages better instead of old existing pages better? Why not improve the browsers or web assembly or dom or anything that hasn't changed in 20 years?
replies(1): >>42175663 #
4. liontwist ◴[18 Nov 24 18:56 UTC] No.42175663{3}[source]▶
> Why not make future pages better instead of old existing pages better?

Existing pages already exist and people use them.

Changing them puts the cost on thousands of other organizations over which you have no control, and likely very little influence.