5 ms·

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 envir

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.

damnyou 7y ago
Because monocultures are bad.
- The_rationalist 7y ago
  Is linux bad? Is git bad? Your argument needs a little more development.
  - damnyou 7y ago
    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?
  - PeCaN 7y ago
    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
the_duke 7y ago
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.
- devwastaken 7y ago
  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.
  - hk__2 7y ago
    > 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.
    - devwastaken 7y ago
      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.
- why_only_15 7y ago
  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/ https://www.pdftron.com/benchmarks/pnacl-vs-wasm/.
jandem 7y ago
> 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?
joaobeno 7y ago
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...
- skybrian 7y ago
  It's a JavaScript interpreter. What privacy features did you have in mind?
  - joaobeno 7y ago
    For example, closing subtle interpreter patterns or behavior differences that may be used to fingerprinting...
    - skybrian 7y ago
      I guess that could be an issue after all the non-subtle ways to fingerprint are fixed.
      - joaobeno 7y ago
        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 ?
        skybrian 7y ago
        Where did you learn that? My understanding is that they like cookies and don't like fingerprinting.
        stjohnswarts 7y ago
        You just repeated that dude's last comment. I think you need to read it again.
olliej 7y ago
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.
skrebbel 7y ago
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?
- olliej 7y ago
  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 :-/
  - floatboth 7y ago
    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
    - olliej 7y ago
      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.
feanaro 7y ago
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.

damnyou 7y ago

Because monocultures are bad.

The_rationalist 7y ago
Is linux bad? Is git bad? Your argument needs a little more development.
- damnyou 7y ago
  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?
- PeCaN 7y ago
  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

the_duke 7y ago

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.

devwastaken 7y ago
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.
- hk__2 7y ago
  > 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.
  - devwastaken 7y ago
    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.
why_only_15 7y ago
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/ https://www.pdftron.com/benchmarks/pnacl-vs-wasm/.

jandem 7y ago

> 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?

joaobeno 7y ago

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...

skybrian 7y ago
It's a JavaScript interpreter. What privacy features did you have in mind?
- joaobeno 7y ago
  For example, closing subtle interpreter patterns or behavior differences that may be used to fingerprinting...
  - skybrian 7y ago
    I guess that could be an issue after all the non-subtle ways to fingerprint are fixed.
    - joaobeno 7y ago
      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 ?
      - skybrian 7y ago
        Where did you learn that? My understanding is that they like cookies and don't like fingerprinting.
        stjohnswarts 7y ago
        You just repeated that dude's last comment. I think you need to read it again.

olliej 7y ago

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.

skrebbel 7y ago

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?

olliej 7y ago
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 :-/
- floatboth 7y ago
  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
  - olliej 7y ago
    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.

feanaro 7y ago

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.