JavaScript performance, WebAssembly, and Shared Memory in Microsoft Edge

Re:JavaScript performance, WebAssembly, and Shared Memory in... by fooey on Thursday April 20, 2017 @03:50PM (#14160197)

To be fair, IE was awful and held back the industry. Likely, it was awful and held by the industry by design.

To this day, the versions of IE in use by actual people are awful. MS finally has Edge, which isn't awful, but absolutely no one uses it.

If I tell an end user to get Chrome or Firefox, that's the end of the problem, whatever system they have it will work. If I try to tell someone to update their IE or to get Edge, I'm stepping into a black hole of trying to divine which version of Windows they're on and how recent their updates are. None of my mac loving coworkers can easily test against IE or Edge and headless unit testing against IE isn't a thing.

[ Parent | on HN ]

Re:JavaScript performance, WebAssembly, and Shared Memory in... by WorldMaker on Thursday April 20, 2017 @04:52PM (#14160740)

IE invented nice things like AJAX (XMLHttpRequest) and the "modern" border-box sizing model that has become almost a CSS boilerplate requirement (* { box-sizing: border-box; }), which was how IE originally interpreted the CSS spec.

IE wasn't awful at the time it was built. It was ahead of its time in some areas. It became awful because of tech debt: people building for it and only it. Companies having key line of business apps built solely for IE that locked everyone into a compatibility nightmare.

It is the same thing with the "Just install Chrome" crowd. If all anyone uses is Chrome, then no one else can move forward without first guaranteeing "Chrome compatibility" rather than spec compatibility. How soon until even Chrome has to maintain compatibility with ancient Chrome bugs because some Fortune 500 company relies on that specific bug for LOB software, willing to throw money at dumb bugs? (That Fortune 500 company could even be Google at this point, because they very much seem to have invested in an internal monoculture.)

(Your Mac coworkers can find free Edge testing VMs from Microsoft. There's also "headless" tools like BrowserStack.)

[ Parent | on HN ]

Re:JavaScript performance, WebAssembly, and Shared Memory in... by pcwalton on Thursday April 20, 2017 @05:00PM (#14160841)

> How soon until even Chrome has to maintain compatibility with ancient Chrome bugs because some Fortune 500 company relies on that specific bug for LOB software, willing to throw money at dumb bugs?

Too late. This has already been happening for years in the mobile space. It's why WebKit refuses to remove -webkit prefixes, and other browsers are now forced to implement them.

[ Parent | on HN ]

Re:JavaScript performance, WebAssembly, and Shared Memory in... by WorldMaker on Thursday April 20, 2017 @05:16PM (#14161000)

Thanks, I meant to include that. I was thinking about big bugs on the order of having to preserve NaCl or Chrome Apps the way ActiveX ruled the roost for a while in LOB apps, but yes Firefox and Edge both now pay attention to -webkit prefixed things because how many websites rely only on the prefixed versions in their CSS.

[ Parent | on HN ]

Re:JavaScript performance, WebAssembly, and Shared Memory in... by sangnoir on Friday April 21, 2017 @05:07AM (#14164050)

> Too late. This has already been happening for years in the mobile space.

I don't think this has much to do with Chrome - I suspect the iPhone's dominance of the mobile browser share is a big factor.

[ Parent | on HN ]

Re:JavaScript performance, WebAssembly, and Shared Memory in... by WorldMaker on Friday April 21, 2017 @11:09AM (#14166245)

If you wish to get pedantic, it has been a combined fault of both WebKit-based browsers: Chrome and Safari (Android and iPhone, plus Chrome on the desktop). If it helps, feel free to replace every reference in the posts here to Chrome with WebKit. (Or WebKit-family if you want to get really pedantic and pretend Blink is that different of a renderer.)

[ Parent | on HN ]

Re:JavaScript performance, WebAssembly, and Shared Memory in... by sangnoir on Friday April 21, 2017 @05:04AM (#14164038)

IE invented nice things like AJAX (XMLHttpRequest) as an ActiveX control - let's not forget this is exactly the sort of standards-breaking behaviour that you are accusing Google of doing with Chrome.

The web has a long history of post-facto standardization where implementation comes before standardazation (see browser wars).

[ Parent | on HN ]

Re:JavaScript performance, WebAssembly, and Shared Memory in... by WorldMaker on Friday April 21, 2017 @11:03AM (#14166182)

Yes, that was exactly my point. Browser monocultures create good, bad, and ugly results. As I pointed out with both of my examples: we standardize the good ones, complain about the bad ones, and try to ignore the ugly ones. I am accusing the Chrome monoculture of creating the same sort of environment. As I posted: then no one else can move forward without first guaranteeing "Chrome compatibility" rather than spec compatibility.

[ Parent | on HN ]

Re:JavaScript performance, WebAssembly, and Shared Memory in... by z3t4 on Thursday April 20, 2017 @04:16PM (#14160415)

You can get a free copy of windows for testing purpuse. you cant do that for mac.

[ Parent | on HN ]