3 ms·

> 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

by 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.
- exogen 8y ago
  I see you have never had to implement Promises in userland. :) setImmediate is one of the more popular polyfills in fact, all the workarounds you mentioned either have downsides or are ugly hacks. It's useful to anything that has a scheduler. Like Vue for example. Maybe someone should tell Evan You that it doesn't make sense to need setImmediate? https://github.com/vuejs/vue/blob/b111de486b1bdc747fe0f5795fe22697d151bb8c/src/core/util/next-tick.js#L33-L35 https://github.com/vuejs/vue/blob/b111de486b1bdc747fe0f5795f... Check the download counts: https://www.npmjs.com/package/setimmediate https://www.npmjs.com/package/setimmediate https://www.npmjs.com/package/next-tick https://www.npmjs.com/package/next-tick https://www.npmjs.com/package/set-immediate-shim https://www.npmjs.com/package/set-immediate-shim https://www.npmjs.com/package/core-js#setimmediate https://www.npmjs.com/package/core-js#setimmediate
- jancsika 8y ago
  > You seem to have missed the part of my comment that said "since IE6" IIRC the pointer events specification[1] came from Microsoft and is implemented in Chrome and Firefox (just checked and found setPointerCapture in devTools-- yay). It allows developers to use a unified approach that can work for various pointer devices. I can confirm it does just that in Chrome and am waiting to hear back from someone who will test it with multi-touch on a surface pro. That API was released well after IE6. [1] https://www.w3.org/TR/pointerevents/ https://www.w3.org/TR/pointerevents/
- gsnedders 8y ago
  > 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. There are definitely examples: IE8 was the first browser with separate content processes (before Chrome was announced). CSS Grid was heavily pushed by MS (and shipped, prefixed, in IE10). Ultimately, being in a game of perpetual catchup in unsurprising when they stood still, with only an absolute minimal amount of work happening, for three years, while other browsers continued to march forwards.
  - WorldMaker 8y ago

by exogen 8y ago

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.

exogen 8y ago
I see you have never had to implement Promises in userland. :) setImmediate is one of the more popular polyfills in fact, all the workarounds you mentioned either have downsides or are ugly hacks. It's useful to anything that has a scheduler. Like Vue for example. Maybe someone should tell Evan You that it doesn't make sense to need setImmediate? https://github.com/vuejs/vue/blob/b111de486b1bdc747fe0f5795fe22697d151bb8c/src/core/util/next-tick.js#L33-L35 https://github.com/vuejs/vue/blob/b111de486b1bdc747fe0f5795f... Check the download counts: https://www.npmjs.com/package/setimmediate https://www.npmjs.com/package/setimmediate https://www.npmjs.com/package/next-tick https://www.npmjs.com/package/next-tick https://www.npmjs.com/package/set-immediate-shim https://www.npmjs.com/package/set-immediate-shim https://www.npmjs.com/package/core-js#setimmediate https://www.npmjs.com/package/core-js#setimmediate
jancsika 8y ago
> You seem to have missed the part of my comment that said "since IE6" IIRC the pointer events specification[1] came from Microsoft and is implemented in Chrome and Firefox (just checked and found setPointerCapture in devTools-- yay). It allows developers to use a unified approach that can work for various pointer devices. I can confirm it does just that in Chrome and am waiting to hear back from someone who will test it with multi-touch on a surface pro. That API was released well after IE6. [1] https://www.w3.org/TR/pointerevents/ https://www.w3.org/TR/pointerevents/
gsnedders 8y ago
> 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. There are definitely examples: IE8 was the first browser with separate content processes (before Chrome was announced). CSS Grid was heavily pushed by MS (and shipped, prefixed, in IE10). Ultimately, being in a game of perpetual catchup in unsurprising when they stood still, with only an absolute minimal amount of work happening, for three years, while other browsers continued to march forwards.
- WorldMaker 8y ago