News for hackers. Stuff that matters.
Re:JavaScript performance, WebAssembly, and Shared Memory in... by sangnoir on Friday April 21, 2017 @04:53AM (#14163997)
> There's zero lock-in unless you want to use Hangouts. Or Google Earth. Or Inbox.

That's not really Chrome's fault - it's the fault of the respective (Hangouts, Earth, Inbox) product teams. We didn't blame Microsoft for "lock-in" back in the IE-only website days, I think it would be fair to give Google that latitude unless you are ascribing nefarious motives above and beyond what lazy/resource-constrained web devs used to do with IE6-only web sites/apps.

Re:JavaScript performance, WebAssembly, and Shared Memory in... by pdkl95 on Friday April 21, 2017 @07:07AM (#14164492)
> We didn't blame Microsoft for "lock-in" back in the IE-only website days

Yes, we did. Very loudly and very frequently. So loudly and frequently that the company was charged with violating the Sherman Antitrust Act.

The expression "embrace, extend, extinguish"[1] was first used to describe Microsoft's attempt to "lock-in" the WWW. Introducing incompatibilities into IE and proprietary extensions (ActiveX, which Google is copying with NaCL) allowed make a show of embracing open standards as bait for the lock-in. This isn't theoretical - in Bill Gates's own words[2]:

>> "One thing we have got to change in our strategy--allowing Office documents to be rendered very well by other peoples [sic] browsers is one of the most destructive things we could do to the company. We have to stop putting any effort into this and make sure that Office documents very well depends on PROPRIETARY IE capabilities. Anything else is suicide for our platform."

[1] https://en.wikipedia.org/wiki/Embrace,_extend_and_extinguish

[2] (pdf) http://antitrust.slated.org/www.iowaconsumercase.org/011607/...

Re:JavaScript performance, WebAssembly, and Shared Memory in... by sangnoir on Friday April 21, 2017 @10:09AM (#14165736)
>> We didn't blame Microsoft for "lock-in" back in the IE-only website days

>Yes, we did.

My phrasing wasn't as clear as I thought - what I meant to say "We didn't blame Microsoft for 'lock-in' due to 3rd parties creating IE-only websites, we blamed the 3rd parties." Implementing non-standard extensions was par for the course during the browser wars (Netscape did the same), and I doubt there was a real expectation of achieving lock-in via the browser by either party: Windows achieved lock-in via Windows, Office and legal threats. Not IE.

Re:JavaScript performance, WebAssembly, and Shared Memory in... by bzbarsky on Saturday April 22, 2017 @12:36AM (#14171139)
In South Korea, Windows achieved lock-in via legislation requiring IE (or more precisely ActiveX). See https://www.washingtonpost.com/world/asia_pacific/due-to-sec... for a decent summary.

And yes, there was very much expectation of achieving lock-in via ActiveX. And it worked in some cases.

Re:JavaScript performance, WebAssembly, and Shared Memory in... by bzbarsky on Saturday April 22, 2017 @12:33AM (#14171132)
> That's not really Chrome's fault

It's Chrome's fault that it's shipping non-standard things. Not like any browser is blameless here, but let's not pretend they're innocent either.

It's _Google's_ fault that it's shipping non-standard things in its browser and then using them in its other products to lock out other browsers.

> We didn't blame Microsoft for "lock-in" back in the IE-only website days

We sure did. And it wasn't even Microsoft creating the IE-only websites!

Re:JavaScript performance, WebAssembly, and Shared Memory in... by sangnoir on Sunday April 23, 2017 @12:10PM (#14178729)
> It's Chrome's fault that it's shipping non-standard things.

I challenge you to name one non-niche browser that didn't ship "non-standard things"

Re:JavaScript performance, WebAssembly, and Shared Memory in... by pcwalton on Sunday April 23, 2017 @01:16PM (#14179105)
The norms have been different in the past few years than during the first browser war. All browser manufacturers have effectively pledged to not ship things without consensus.

In the case of NaCl, Google got around their own pledge by declaring NaCl "not part of Blink" and therefore not subject to the Blink rules, which was a cop-out if I've ever seen one.

Re:JavaScript performance, WebAssembly, and Shared Memory in... by bzbarsky on Monday April 24, 2017 @02:48PM (#14186888)
I explicitly said other browsers have done it too.

Chrome has done a lot more promotion of its non-standard things and of course Google as a whole has been using Chrome's non-standard things quite a bit, which is a large part of the problem.

Re:JavaScript performance, WebAssembly, and Shared Memory in... by yesbabyyes on Friday April 21, 2017 @07:06AM (#14164489)
wat