Hacker News new | past | comments | ask | show | jobs | submit login
How V8 handles JavaScript properties internally (v8project.blogspot.com)
122 points by ingve on Aug 30, 2017 | hide | past | favorite | 41 comments

I know there are JS haters here on HN, but (as an old OS/compiler guy from the '70's and '80's), it's truly marvelous to see what you can do with dynamic languages by pouring hundreds man-years into optimized language implementations like V8.

I think the worst part about JS is not really performance but the language itself.

I wish I could just write that I'm expecting to receive a User object in a function without having to resort to TypeScript. It would make code so much more readable.

JavaScript is fractally bad: you can find mistakes at every levels, as you zoom in or out.

On the zoomed-in scale we see things like tricky semantics for regexp or Math.round(), which major implementations still get wrong.

On the zoomed-out scale, we see things like property iteration order. This touches on array semantics and hidden classes. Why does v8 permit two objects to have the same properties but different hidden classes? Because JS requires that properties be enumerated in their definitional order - something no other language requires, and which puts serious constraints on implementations.

TypeScript can layer types on top, but can't make arrays sane or fix the other deep language issues.

JS used to not require that iteration order match definition order. Iteration order was explicitly unspecified.

But initial implementations just stored properties in a flat list, so in practice all had iteration order matching definition order. And then websites were created depending on that behavior.

So now you had a spec saying "the order can be anything" but real-world compat constraints meant that in any implementation shipping in a web browser the order had to be definition order. At some point this compat constraint was simply documented in the spec, so there wouldn't be a gotcha lurking for a new implementation.

So it's hard to blame this problem on JS, really. It's more like Postel's Law (or a failure thereof, depending on who you're talking to, but I feel like in this case the output is the iteration order, and having it be fixed corresponds to being conservative in what you do. The pages that failed on different iteration orders correspond to _not_ being liberal in what you accept from others...

Can you expand on your hatred of JS arrays? I don't understand how iteration semantics really affect anything with them since the spec gaurantees that numerical properties come first, in order, regardless.

The biggest issue is precisely concerning the definition of "numerical properties". Here are some "numerical properties:"

But these are not "numerical properties:"

Which means that, when setting a property on an array, you must attempt to parse the object in a very peculiar way so that you can make a decision about iteration order, and whether to adjust the length property.

> JavaScript is fractally bad

This made my morning. :)

I will quote you on this.

I'd be curious how LuaJIT stacks up today, last time I looked it was still a fair bit faster than V8.

Of course it helps that Lua has much simpler semantics.

Much simpler semantics with much more powerful features, should we add. Because simpler here doesn't mean "dumber" in any way.

And just think how much easier it would be if it wasn't a dynamic language!

Which is why the engineer behind the original V8 went on to create Dart, one of the reasons behind it being that it's much easier to optimize.

The original V8, created by one man, was already pretty amazing.

No it wasn't a one man job.

I'm not sure it's completely fair to equate JavaScript hate with perceptions of dynamic languages in general, but there is a lot more work spent on optimizing JavaScript than pretty much any other dynamic language, so I'd agree that on a technical level the work done on JS engines is pretty impressive.

It may not be completely fair but the critics do themselves no favors by using the same tired arguments from that camp over and over.

I think there are a number things fairly unique to JavaScript (i.e. not present in other dynamic languages) that garner a certain amount of criticism even from fans of other dynamic languages. Type-independent equality (`==` rather then `===`), prototypical rather than class-based OO, and context-based meaning of `this`, among other things, get a decent amount of criticism, and you wouldn't run into the same issues in Python or Ruby, for instance. (Not trying a make a value judgment here about those aspects of JavaScript, just making a point that some of the criticism of JavaScript is specific to the language itself and not to dynamic languages in general).

Identity vs Equality isn’t unique to JS. It’s particular syntax isn’t even unique either (though less common).

Protypical inheritance goes back to the damn Actor pattern and modern versions (like JS) derive from Smalltalk.

The particular implementation of this in JS is idiosyncratic to JS but not conceptually unique. They improved it a LOT with strict mode too.

I swear, most JS criticism on HN seems to sound like developers who only know C++/Java/Ruby/Python critiquing stuff that comes from the Lisp/ALGOL/Smalltalk idioms and not understanding that the way they are used to isn’t the One True way.

I think framing JavaScript's equality semantics as merely "identity vs. equality" glosses over the issue people have with it, namely that the semantics of equality themselves are somewhat inconsistent (e.g. `3 == "3" => true, `3 == "3 "` => true, `"3" == "3 "` => false, or `null > 0` => false, `null == 0` => false, `null >= 0` => true). This isn't to say that these semantics are objectively wrong (although the lack of transitivity in the former does stretch the definition of "equality"), but I don't think it's really that surprising that some programmers aren't fond of them.

As for things like prototypical inheritance, `this`, and other language features not being distinct to JS, I'll concede that point. However, I still think my main point stands, namely that criticisms of JS aren't just blanket criticisms of "interpreted languages".

As a new school developer with an interest in languages, compilers and runtimes, I'm impressed as hell by what they've achieved with JavaScript performance. Doesn't make me dislike JavaScript any less though.

So much energy is spent making a shitty language perform better. It is really sad.

We should only let people have one release of anything. That way there are no extra man hours spent on anything that some random guy on HN thinks is shitty.

The only way to prove something is not shitty is to release a monopoly and let other players show themselves in a fair competition. We'll wait for cross-platform assembler to be supported on every toster and see how long js can stand his 'beauty'.

Would you rather have that "shitty language" waste your time because it performs poorly?

I think there are only historical reason to only having bad languages in browsers. Having good languages in WASM proves it.

EDIT - Good from a performance perspective, things like static typing and symbolically executable and pre-compiled.

What "good" languages does WASM enable?

All those other dynamic scripting languages? They're DOA because nobody's going to download the entire VM every time.

What about all those nice functional languages? Very problematic because the toolchain relies on LLVM-like semantics which don't like good garbage collectors or functional programming in general.

We then get down to C-like languages, Rust, and more esoteric languages (and promptly discard the esoteric ones for lack of a decent ecosystem).

Who in their right mind wants to write a front-end in C++ or Rust? By the time you get anything done, the web has changed and you're stuck with a pile of dated code that takes too much time and costs too much money to update.

The web had a shot at a decent language with Dart (it was/is even an ECMA standard). It didn't die because of other browsers. It died because of poor web dev adoption rates.

If only Eich had been allowed to implement scheme then none of this would have been an issue.

> All those other dynamic scripting languages? They're DOA because nobody's going to download the entire VM every time.

Hosted on a CDN in compact form, it'll be feasible; application can just link against it, it does not have to be recompiled on the user's machine.

> Very problematic because the toolchain relies on LLVM-like semantics which don't like good garbage collectors or functional programming in general.

That will indeed be a problem. The design restrictions imposed by the environment (continuous heap, emulated concurrency) will bite us in the ass hard. Instead of layering a lot of very leaky, performance killing "security" features over other half assed features, a better way would be to step back and use a tiny hypervisor. That way you have hardware accelerated memory safety, but it would require the application to be able to run in a microkernel; recent IncludeOS + ukvm has a boot time of 11 ms. (Great, now I want to write a plugin that embeds qemu in Chromium and uses a virtual device to communicate with the host.)

> Who in their right mind wants to write a front-end in C++ or Rust? By the time you get anything done, the web has changed and you're stuck with a pile of dated code that takes too much time and costs too much money to update.

This has been repeated again and again, but the proof that you are programming faster in JS than in Rust (or whatever language you want) is very lacking. At least, if you want to use your code longer than two days, because that's the time many of those "I just write it and it will work!" JS programs stop being readable. But even then I have my doubts. Sure, if you've never used a language before you will be slower, but that doesn't make the "JS can be programmed faster" assumption correct.

> Who in their right mind wants to write a front-end in C++ or Rust?

Every AAA Game Dev.

Java is also enabled by WASM and plenty of large applications are made in that. Things like Google Docs are made in Java and cross compiled to javascript as it is. Someone thought static typing and sane language semantics were worthwhile.

There are already ongoing efforts to port JVM and .NET environments into WASM, although currently it is more of a proof of concept.

When WASM gets mature, expect the return of the plugins, maybe even a Flash to WASM compiler.

I don't believe the answer to JS is downloading, and compiling the entire JVM.

As I mentioned, It is already happening.




In two to three years time, Flash will be back.

I think you are adding extra steps that are not needed. The programming model requires the JVM there are a few tools that compile Java directly to native code. There are tools that compile it to java script, and there are beta quality tools that compile it to WASM.

You say "rather" as if there are only two possible alternatives, flavours of the same thing.

I'm not sure. Back when javascript performance sucked, there was a great deal less of it and websites seemed to work fine. You know, back when the text content was in the HTML. Now with everything rendered client side, there's more opportunity for things to go wrong. I would estimate I waste more time now.

You appear to be referring to the late 90s then? Maybe?

Because as soon as advertising kicked off JS usage did too. Even before then the DHTML movement had successfully moved JS into spaces people didn’t know it could be on the web.

You’re romanticizing an era I lived and worked through: it wasn’t really like that.

It was exactly like that, man. Dirt cheap hardware of these days could view web easily. The same is not true for today. Maybe you worked through specific areas or simply was tired to death and now deromanticizing it, because I clearly remember when things went downhill in general.

Anything like this published for the firefox side of things?

All serious JavaScript engines use the same idea of hidden classes.

I found [0] a few months ago which was a nice starting point.

[0] https://github.com/a0viedo/demystifying-js-engines

Search for the spidermonkey papers.

Hidden classes are born in self language

Applications are open for YC Winter 2021

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact