News for hackers. Stuff that matters.
Re:JavaScript performance, WebAssembly, and Shared Memory in... by derefr on Thursday April 20, 2017 @07:09PM (#14161714)
I don't think it matters what the particular engine everyone gets stuck with is. The argument is more that forcing everyone to use it, means that everyone now has an incentive to refactor it into something nice.

Consider where OpenGL would be right now, if DirectX never came into existence, and so all the people who would have been off contributing happily to DirectX, had instead been banging the OpenGL standard into better shape.

When we have "enclaves" like DirectX, we have developers who are perfectly content because their little corner of the ecosystem works for them, for their use-case—even if, somewhere else, a ton of people who can't (for whatever reason) work inside that enclave are suffering, for reasons that person could totally help with if they cared about what happens outside of the enclave.

Merging everyone's efforts into one big project, wouldn't mean that the project would be good (at least at the beginning.) It would just mean that everyone would be forced to take all their corner-case solutions for their use-cases from their enclaves, and bring them out into the open where everyone can benefit from them.

Re:JavaScript performance, WebAssembly, and Shared Memory in... by pcwalton on Thursday April 20, 2017 @07:14PM (#14161736)
OpenGL is a standard, not an implementation! Imagine if were all stuck with SGI's implementation of GL instead of having it be a standard that the industry could create unique hardware implementations of. Would SGI have willingly collaborated with 3dfx on the Voodoo? Not likely--instead, 3dfx implemented a subset of the de facto GL standard, called it Glide, and created the entire PC GPU market in one fell swoop.

OpenGL is actually a great argument for the importance of multiple implementations--thanks for suggesting it :)

> everyone now has an incentive to refactor it into something nice.

My proposal to "refactor" Blink would be to completely redesign the layout system from the ground up to be parallel and to write as much as possible in Rust and JS in order to improve security. After working in this space for years, I've become increasingly convinced that this is what is needed in order for the Web to steal the performance crown from native, while simultaneously driving security forward.

Do you honestly think Google would be likely to collaborate on that?

Re:JavaScript performance, WebAssembly, and Shared Memory in... by derefr on Thursday April 20, 2017 @07:19PM (#14161766)
I don't see it. My point doesn't change between talking about "a standard", and talking about "a FOSS project with open committee-based maintainership" (like e.g. ASF projects are.) It's stone soup: you'd start off with a worthless project—but if that pile of crap has to "feed the whole town", people are going to turn it into something worthwhile.

Eventually, in such an effort, there would probably be zero lines of code from the original project left. That's okay! It was there to bootstrap the project and inspire contributions, not to be good code.

> My proposal to "refactor" Blink would be to completely redesign the layout system from the ground up to be parallel and to write as much as possible in Rust in order to improve security. Do you think Google would be likely to collaborate on that?

Keep in mind that, if there really was just one impl that everyone used, there'd be more than one megacorp influencing it; Google would have no more say than anyone else, and would probably be "at arms' length" from the maintainership in the same way e.g. Apple is with Webkit. If Google didn't like an idea, but some other corp (e.g. Mozilla) did, sponsorship would still happen, code would still get written, and things would still change.

See: the Linux kernel.

Re:JavaScript performance, WebAssembly, and Shared Memory in... by pcwalton on Thursday April 20, 2017 @07:48PM (#14161909)
> Eventually, in such an effort, there would probably be zero lines of code from the original project left. That's okay! It was there to bootstrap the project and inspire contributions, not to be good code.

The Web doesn't need "bootstrapping" and "inspiring contributions". It's 20 years old!

> Keep in mind that, if there really was just one impl that everyone used, there'd be more than one megacorp influencing it; Google would have no more say than anyone else, and would probably be "at arms' length" from the maintainership in the same way e.g. Apple is with Webkit. If Google didn't like an idea, but some other corp (e.g. Mozilla) did, sponsorship would still happen, code would still get written, and things would still change.

No, the organization that didn't like the change would fork the project. This already happened with WebKit!

> See: the Linux kernel.

Linux gets forked over and over and over again, every time some organization wants to ship a device running it.

Re:JavaScript performance, WebAssembly, and Shared Memory in... by derefr on Thursday April 20, 2017 @08:28PM (#14162114)
> No, the organization that didn't like the change would fork the project. This already happened with WebKit!

Er, this whole thought exercise is about what would happen if it was literally impossible to fork the project. If everyone was forced to work on one implementation, full-stop, no takesie-backsies. (I'm imagining aliens from the Culture holding guns to our heads.)

It's a very implausible thought-exercise, yes, but if you're playing along, you can't challenge the axioms. (It's like one of those "how would a One World Government work" discussions: saying "there could never be one" is beside the point.)

Re:JavaScript performance, WebAssembly, and Shared Memory in... by fetbaffe on Friday April 21, 2017 @02:31AM (#14163506)
No, forcing everyone to use the same engine does not give the incentive to refactor it into something nice.

It gives the incentive to create a black market.

Re:JavaScript performance, WebAssembly, and Shared Memory in... by johncolanduoni on Friday April 21, 2017 @03:40AM (#14163734)
A black market is based on circumventing some prohibition. What prohibition is one circumventing to fight the Chrome monoculture? Google's success in creating a monoculture is based on making Chrome attractive and reducing friction with their services compared to alternatives. Independent of whether you think that's something they should do given their prominent position in some related markets, who or what is the black market going to be hiding from?
Re:JavaScript performance, WebAssembly, and Shared Memory in... by fetbaffe on Friday April 21, 2017 @04:03AM (#14163823)
Not every person thinks the same or have the same moral believes. Only because you think that Chrome monoculture is a good thing with rational arguments, you can't assume that everyone agrees with that.

Just the fact that not everyone uses the Chrome engine today is a good indicator to that. Or that we are having this argument.

What will happen is that people not agreeing on Chrome monoculture will go else where. So even if you have the same engine, others have the possibility to create a total different web system. Now you have two different webs. To what gain?

Also an engine monoculture will eventually be treated as the de facto standard and the real standard will be ignored, i.e. implantation details will trump good design.

Re:JavaScript performance, WebAssembly, and Shared Memory in... by johncolanduoni on Friday April 21, 2017 @05:10AM (#14164062)
I'm not arguing in favor of a Chrome monoculture, since I don't want one. I just don't see how Chrome monoculture => black market happens. It wouldn't even had made sense as a response to the old IE monoculture.

Also the fact that this is even an issue is a product of HTML5, etc. leaving a lot of room for undefined behavior and being easy to misinterpret/misimplement. You don't even have to purposely bend the standard to try and create a monoculture; hard to predict implementation differences happen organically.

Re:JavaScript performance, WebAssembly, and Shared Memory in... by fetbaffe on Friday April 21, 2017 @05:24AM (#14164119)
Black market is what happens who there is no choice.

For the old IE, Firefox happened (and other as well).

Re:JavaScript performance, WebAssembly, and Shared Memory in... by johncolanduoni on Friday April 21, 2017 @05:33AM (#14164146)
Okay, but what does Firefox's ascendance have to do with a black market? It wasn't even breaking some hard to enforce Microsoft EULA provision. IE got lazy, and Firefox offered a dramatically better experience. Whenever a new product overtakes a more established competitor because it's better, is there a black market involved?

My purpose isn't (just) pedantic. You claimed "No, forcing everyone to use the same engine does not give the incentive to refactor it into something nice. It gives the incentive to create a black market.", but then your example shows an incentive to make a superior product. It starts making a lot less sense in Blink's case if you change it to the more accurate "No, forcing everyone to use the same engine does not give the incentive to refactor it into something nice. It gives the incentive to create a superior product." Why not a superior product that starts with a Blink fork?

Re:JavaScript performance, WebAssembly, and Shared Memory in... by fetbaffe on Friday April 21, 2017 @05:48AM (#14164205)
Okay, I get your point, however my focus is the word force. For me it means a gun pointing at your head, no choice.

IE did not force anyone doing anything, even if it had a de facto monopoly, therefore Firefox was created, because people chose to.

In this scenario I'm discussing it would not be allowed to create a Firefox, because everyone was forced to use Chrome, hence a black market is created.