4 ms·

Honestly I just see all this, even despite the author claiming taking time to "mull it over", as a knee-jerk reaction. There is little evidence that MS changing

Honestly I just see all this, even despite the author claiming taking time to "mull it over", as a knee-jerk reaction. There is little evidence that MS changing to Blink/V8 will have any tangible impact on the web. Microsoft has hardly offered much as far as competition and diversity goes since IE6, basically the only web "innovations" they're responsible for is a bunch of IE-specific APIs that didn't work in any other browser. The garbage rhetoric that Mozilla and their supporters have been spreading is pure FUD: > By adopting Chromium, Microsoft hands over control of even more of online life to Google. MS' new default browser being based on Chromium does not give any additional control of online life to Google. They're open-source projects that, while Google manages, does not have absolute control over the consumption of. If Google did ever try to muscle control on Chromium like they've been doing with Android, Microsoft could simply fork it without the hostile Google changes. If anything I see this whole thing being beneficial for the web in the long run - now instead of MS engineers pissing their time and effort down the drain on a dead browser and needlessly fragmenting the market with engine differences, even if people don't use the default Windows browser Microsoft's engineers can contribute to and benefit the web by contributing their improvements upstream to the Chromium/Blink/V8 projects.

mcny 8y ago
Downvoters, please stop and think. > If anything I see this whole thing being beneficial for the web in the long run - now instead of MS engineers pissing their time and effort down the drain on a dead browser and needlessly fragmenting the market with engine differences, even if people don't use the default Windows browser Microsoft's engineers can contribute to and benefit the web by contributing their improvements upstream to the Chromium/Blink/V8 projects. This is absolutely spot on. Keep in mind that Microsoft's EdgeHTML team went as far to almost declare that any difference from Chrome is a bug that Microsoft intends to fix. I mean I get it if Edge was free and open source, there would be some value in seeing reimplementation of a browser that is compatible with Chrome but I doubt making Edge free and open source was ever in the works (I think, I am not sure if Edge was actually a clean slate. It might just have been removing "bad" code from IE tbh). I simply don't understand why we should mourn Edge when the Edge team pretty much says any difference from Chrome is a bug.
exogen 8y ago
> Microsoft has hardly offered much as far as competition and diversity goes since IE6, basically the only web "innovations" they're responsible for is a bunch of IE-specific APIs that didn't work in any other browser. I don't have much love for MS, but this is just wrong. XMLHttpRequest, the precursor to fetch, pretty much allowed "web 2.0" to exist. Now we use fetch, but they introduced it first. box-sizing: border-box, a much better way to reason about the CSS box model, is almost always introduced as "the way Internet Explorer had always done things in older versions and quirks mode." Surely its existence in IE (and the experience people had w/ CSS there, preferring its box model) had some historical weight in this property coming about? Lastly, and something still not standardized: setImmediate. Lots of libraries currently have to polyfill this with MessageChannel, postMessage, and other hacks. Clearly there's high demand for it.
- sureaboutthis 8y ago
  There are thousands and thousands of APIs, properties, attributes, functions and so on for web programming. Holding up a few examples of past accomplishments from long ago is no defense for IE and the widely known vulgarities.
- wyqydsyq 8y ago
  You seem to have missed the part of my comment that said "since IE6" AFAIK the box-sizing box model you mentioned was implemented since the beginning of Trident, well before IE6 came about. XHR was available from IE5 onwards (only accessible via ActiveX object, it didn't become available as a native window property in JS until IE7 but the feature was still available), so again isn't "since IE6". If you think whether it was available in native JS matters, note that Mozilla had a native JS XHR object available in 2002, well before it was available in IE7 in 2006. I specifically mentioned "since IE6" because that was the point at which Microsoft had decided they'd won the browser war, and ceased to innovate. From that point onwards they have been playing a perpetual game of catch-up, constantly lagging behind other browsers in implementing new specifications and features. setImmediate is not standardised for good reason, there are already more appropriate use-case specific solutions: use `requestAnimationFrame` if you are working with animations/visual changes use `postMessage` or WebWorkers if you are working with transporting or processing heavy data There's no browser use-case enabled by `setImmediate` that isn't supported by one of the above. It does however make sense for `setImmediate` to be implemented in node because a node environment lacks the two APIs mentioned above and doesn't really have any way of achieving the desired outcome short of forking child processes.
tannhaeuser 8y ago
The problem is this: HTML (+CSS) is supposed to be a standardized and recommendable format for publishing rich text with the expectation that it can be rendered for a long time to come. But if only a single browser will be able to display it, this not only questions the longevity claim, but also questions the whole web stack. New CSS specs can't be reviewed and proven with independent implementations, and web specs will, even more so than they already do, become "whatever Chrome does". This is a terrible and fatal result for the web as we know it. Because why would we continue the practice of creating baroque, power-inefficient web frontends with JavaScript and the browser stack monstrosity when we're essentially targetting a single browser? We could as well use a much leaner and lighter GUI framework designed for the purpose, and a saner language. What did we really expect from the way so-called web standards are created? WHATWG (who write the HTML5 specs and call this a "standard") pride themselves in creating a "living standard" where nothing ever is locked down, and ECMA has put itself up to creating yearly JavaScript updates (after the language has stagnated for 15 years). W3C creates an enormous amount of CSS specs and has said goodbye to versions/levels and profiles a long time ago. The result is that there is no reasonable spec as an implementation target for browser development. Those in the game have closed the door behind them. Firefox has, unfortunately, a shrinking user base, is financially dependent on Google, and might suffer from problematic incentives in the future. The web is in tatters.
- JumpCrisscross 8y ago
  > But if only a single browser will be able to display it Chromium has no intrinsic power. If Chromium and Google disagree, the latter can easily break off. The browser political landscape is fragmented as ever.
  - 43920 8y ago
    > the latter can easily break off How? Developing a browser takes hundreds of millions of dollars, and Google is currently providing all the funding for that (meaning they decide what changes get made). Who has the necessary resources to fork Chromium, and would actually be willing to do it?
deleted 8y ago
[deleted]

mcny 8y ago

Downvoters, please stop and think. > If anything I see this whole thing being beneficial for the web in the long run - now instead of MS engineers pissing their time and effort down the drain on a dead browser and needlessly fragmenting the market with engine differences, even if people don't use the default Windows browser Microsoft's engineers can contribute to and benefit the web by contributing their improvements upstream to the Chromium/Blink/V8 projects. This is absolutely spot on. Keep in mind that Microsoft's EdgeHTML team went as far to almost declare that any difference from Chrome is a bug that Microsoft intends to fix. I mean I get it if Edge was free and open source, there would be some value in seeing reimplementation of a browser that is compatible with Chrome but I doubt making Edge free and open source was ever in the works (I think, I am not sure if Edge was actually a clean slate. It might just have been removing "bad" code from IE tbh). I simply don't understand why we should mourn Edge when the Edge team pretty much says any difference from Chrome is a bug.

exogen 8y ago

> Microsoft has hardly offered much as far as competition and diversity goes since IE6, basically the only web "innovations" they're responsible for is a bunch of IE-specific APIs that didn't work in any other browser. I don't have much love for MS, but this is just wrong. XMLHttpRequest, the precursor to fetch, pretty much allowed "web 2.0" to exist. Now we use fetch, but they introduced it first. box-sizing: border-box, a much better way to reason about the CSS box model, is almost always introduced as "the way Internet Explorer had always done things in older versions and quirks mode." Surely its existence in IE (and the experience people had w/ CSS there, preferring its box model) had some historical weight in this property coming about? Lastly, and something still not standardized: setImmediate. Lots of libraries currently have to polyfill this with MessageChannel, postMessage, and other hacks. Clearly there's high demand for it.

sureaboutthis 8y ago
There are thousands and thousands of APIs, properties, attributes, functions and so on for web programming. Holding up a few examples of past accomplishments from long ago is no defense for IE and the widely known vulgarities.
wyqydsyq 8y ago
You seem to have missed the part of my comment that said "since IE6" AFAIK the box-sizing box model you mentioned was implemented since the beginning of Trident, well before IE6 came about. XHR was available from IE5 onwards (only accessible via ActiveX object, it didn't become available as a native window property in JS until IE7 but the feature was still available), so again isn't "since IE6". If you think whether it was available in native JS matters, note that Mozilla had a native JS XHR object available in 2002, well before it was available in IE7 in 2006. I specifically mentioned "since IE6" because that was the point at which Microsoft had decided they'd won the browser war, and ceased to innovate. From that point onwards they have been playing a perpetual game of catch-up, constantly lagging behind other browsers in implementing new specifications and features. setImmediate is not standardised for good reason, there are already more appropriate use-case specific solutions: use `requestAnimationFrame` if you are working with animations/visual changes use `postMessage` or WebWorkers if you are working with transporting or processing heavy data There's no browser use-case enabled by `setImmediate` that isn't supported by one of the above. It does however make sense for `setImmediate` to be implemented in node because a node environment lacks the two APIs mentioned above and doesn't really have any way of achieving the desired outcome short of forking child processes.

tannhaeuser 8y ago

The problem is this: HTML (+CSS) is supposed to be a standardized and recommendable format for publishing rich text with the expectation that it can be rendered for a long time to come. But if only a single browser will be able to display it, this not only questions the longevity claim, but also questions the whole web stack. New CSS specs can't be reviewed and proven with independent implementations, and web specs will, even more so than they already do, become "whatever Chrome does". This is a terrible and fatal result for the web as we know it. Because why would we continue the practice of creating baroque, power-inefficient web frontends with JavaScript and the browser stack monstrosity when we're essentially targetting a single browser? We could as well use a much leaner and lighter GUI framework designed for the purpose, and a saner language. What did we really expect from the way so-called web standards are created? WHATWG (who write the HTML5 specs and call this a "standard") pride themselves in creating a "living standard" where nothing ever is locked down, and ECMA has put itself up to creating yearly JavaScript updates (after the language has stagnated for 15 years). W3C creates an enormous amount of CSS specs and has said goodbye to versions/levels and profiles a long time ago. The result is that there is no reasonable spec as an implementation target for browser development. Those in the game have closed the door behind them. Firefox has, unfortunately, a shrinking user base, is financially dependent on Google, and might suffer from problematic incentives in the future. The web is in tatters.

JumpCrisscross 8y ago
> But if only a single browser will be able to display it Chromium has no intrinsic power. If Chromium and Google disagree, the latter can easily break off. The browser political landscape is fragmented as ever.
- 43920 8y ago
  > the latter can easily break off How? Developing a browser takes hundreds of millions of dollars, and Google is currently providing all the funding for that (meaning they decide what changes get made). Who has the necessary resources to fork Chromium, and would actually be willing to do it?

deleted 8y ago

[deleted]