Hacker News Reader

Comment by devwastaken | Hacker News Reader

I can't help but think that regardless what different browser vendors do there's no competition with v8. Like any language there is a standard library, or environment around it. V8 is to JavaScript what CPython is to python.

At least in python you can use other versions and it's a very similiar environment. But if you want to use mozillas spidermonkey without Firefox, it's hoops and bounds worse experience. I'd argue that v8 is far less of a lock in by comparison.

Given all that, why are we still creating entirely separate engines that are made differently, yet do the same.

View on HN

Diversity and multiple implementations are essential for the web IMO.

V8/Blink/Chromium are not independent community projects, but firmly in the hands of Google. Chromium being the only viable implementation would put too much control in the hands of a single company (regardless of which company that is, Firefox being the only implementation would be just as bad).

It's redundant effort, but it also enforces consensus building and exchange of ideas.

EG Google would have happily stuck with PNacl, but (afaik) Mozilla pretty much forced their hand - with the result being Webassembly, a much better design.

If that diversity doesn't lead to better results then it isn't necessary. I wouldn't consider the oligarchs of Js engines to be diversity, nor inherently innovative. In the past there has no doubt been innovation, but currently it has significantly stagnated.

Wasm was not what was promised. Mozilla and the other vendors just translated the wasm bytecode to js bytecode. All it did was skip a few steps. Yet the actual requirements for performance, simd, was ignored in its proposal. It has been a significant under delivery overall.

> If that diversity doesn't lead to better results then it isn't necessary.

It does, so it’s necessary. Performance is not the only one result we care about.

If they were innovating then spidermonkey would be comparable or better than v8. It isn't. It's effectively proprietary to Firefox. Id call that the opposite of diversity.

Also a much slower one - on PDFTron's benchmark, WASM is half as fast as PNacl for me: https://www.pdftron.com/benchmarks/pnacl-vs-wasm/.

Their very own blog post goes into plenty of detail about this: https://www.pdftron.com/blog/wasm/wasm-vs-pnacl/

It's nothing fundamental about WASM; in fact they state that the actual computations are slightly faster.

This meme of "why are we building more than exactly one thing for a certain purpose" needs to die. Alternatives need to exist and they are beneficial for innovation and cross-pollination of ideas, resilience, finding alternative approaches to problems and last, but certainly not least, not ceasing control of everything to a single company. For inspiration for this idea, see: natural selection and evolution.

> Given all that, why are we still creating entirely separate engines that are made differently, yet do the same.

To name one reason: would we have asm.js/Wasm instead of (P)NaCl without Mozilla's work on asm.js optimizations in SpiderMonkey?

About a decade ago I needed an embedded scripting language in a c++ project and chose JS. Embedding SpiderMonkey was a matter of copying all files in the `js` subfolder of the Firefox sources into my project, and calling into it was peanuts. The classes were well named, easy to use and easy to learn.

Did this somehow change?

Nope.

JSC is even better in that regard - it’s API and ABI stable so you can just link to the[1] system install and use it [2].

[1] on Linux there are multiple (although technically it could be made to have a single lib for qt,gtk,wx...

[2] ok, actually using the C API is very very clunky :-/

There are often multiple installs of spidermonkey too (IIRC recently there was an effort in FreeBSD Ports to consolidate everything onto the latest couple versions)

The most (in)famous consumer of that is polkit :) but also GJS

The problem for JSC I suspect is how you manage gtk/qt/wx bridges without need either all three or alternatively creating dependency hell due to the bindings directly interacting with internal (eg totally unstable) interfaces and structs.

Eg you’d ideally have

* libjavascriptcore - the actual engine, runtim, and c-api, etc

* libjavascriptcore-qt (only the bindings, it would link the root jsc lib)

* libjavascriptcore-gtk (same)

* etc

The problem is that because they talk directly to internal interfaces they need to update in lockstep.

On Mac the only frameworks that do that are the core webkit frameworks. Nothing else on the system can talk to the internals (Mac and iOS have fairly comprehensive support for distinct internal/project/public APIs). But the system webkit, webcore, jsc, etc all have to update and build in lockstep.

In an ideal world all the alternate language bindings would be built on top of the stable C API, but alas (as I said before) the C API is fairly clunky and also out of date wrt to modern JS features. Also there are fun performance things a given binding can achieve if it doesn’t need to go through some layer of abi stability limitations.

Why would a JSC on its own depend on the UI toolkit? Spidermonkey doesn't.

It doesn’t, but the major webkit ports all have bridging APIs to make interfacing from a <gtk,qt,wx,corefoundation,cocoa> cleaner, and potentially lower cost.

I recall there being a desire to make it easier for bindings to be done entirely through the API, but as said elsewhere the API is somewhat clunky. Of course any level of abstraction adds costs - for example by being tied to the innards of JSC the various bridges are able to directly bludgeon the tag bits in JSString (the jsc raw string type) so there’s zero copying.

It also theoretically means you can do automatic object bridging (see the objc bindings).

So it’s not “JSC has to have UI bindings” as much as “JSC can be built with bridging APIs for major embedding frameworks”.

There is a trade off to be made, and long term I’m sure everyone in the JSC team at Apple would rather they could pull the bridges out of core build, but API design is very hard when you are having to think about long term support, coupled with continued support for the existing APIs.

Uhhh what? JSC beats v8 across a wide variety of code, and has stable ABI so you don’t have to have N different copies of the entire implementation across every app.

Because monocultures are bad.

Is linux bad? Is git bad? Your argument needs a little more development.

Linux is only a monoculture on the server. Server-side applications will sometimes use Linux -specific features but generally are written to be ported to other POSIX systems with little work.

Of course the git monoculture is bad. Have you seen how many people complain about git on Twitter?

linux isn't a monoculture at all

assuming you know about Windows and OS X and are just talking about servers, there's still the BSDs and Solaris and AIX. a good deal of software is written to just assume a reasonably POSIX-compliant environment, precisely because linux is not the only server OS.

unix-like operating systems are something of a monoculture and that IS very bad, because OS design is basically stuck in 1973

>Is git bad?

yes and anyone who says otherwise is numb to the pain

Yea, because Google surely will implement and fast track new privacy measures on V8, instead of fill any initiative on this regard in a lot of red tape...

It's a JavaScript interpreter. What privacy features did you have in mind?

For example, closing subtle interpreter patterns or behavior differences that may be used to fingerprinting...

I guess that could be an issue after all the non-subtle ways to fingerprint are fixed.

You mean the ones google is fighting to keep, while trying to convince everyone that allowing more tracking would incentive bad actors to drop fingerprinting ?

Where did you learn that? My understanding is that they like cookies and don't like fingerprinting.

You just repeated that dude's last comment. I think you need to read it again.

Reply on news.ycombinator.com