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