8 ms·

> across all browsers IE. Everywhere I've worked, we still have to support it. Unless Microsoft ports Edge to Windows 7/8 and makes it a default browser, I d

> across all browsers IE. Everywhere I've worked, we still have to support it. Unless Microsoft ports Edge to Windows 7/8 and makes it a default browser, I don't see the situation changing anytime soon.

kowdermeister 9y ago
You can still ship an asm.js version there as a fallback.
- jlebrech 9y ago
  do webassembly compilers also compile the fallback?
  - themihai 9y ago
    You could actually exec wasm with a JS/asm polyfill
    - Filligree 9y ago
      You want to run a bytecode interpreter in JS? What's battery life going to look like with that?
      - themihai 9y ago
        That should encourage the browser vendors to support wasm natively, right?
        dbbk 9y ago
        They do? This article is about browser vendors supporting wasm.
        themihai 9y ago
        >> This article is about browser vendors supporting wasm. And my comment was about old browsers/OSes not supporting wasm.
        dbbk 9y ago
        The reason old browsers don't support WASM is because they can't go back in time... the modern versions do (for instance Edge).
    - vanderZwan 9y ago
      I'm sure you could, but wouldn't the added overhead defeat the purpose of using either WASM or asm.js? Serious question, because if this could work it's a fun example of "turtles all the way down" in programming. I can see two ways of interpreting your answer, and neither looks like it gives the desired performance benefits of a plain asm.js fallback: One: a WASM interpreter in asm.js. Given what this would imply for performance I'm pretty certain that this wasn't what you meant. Two: a WASM-to-asm.js compiler, possibly in asm.js, that can take downloaded WASM.js files, turn it into asm.js, then load it through the Function constructor. Assuming you meant the latter: do browsers even support loading asm.js that way? Assuming they do, this would still introduce extra overhead, having to download the compiler, and adding a compilation phase. Of course, since WASM files are binary, the benefit might be lower bandwidth use, so for slower connections it could be a net gain over plain asm.js... I also vaguely recall that functions creating with the Function constructor don't enjoy all the JIT-compiled optimisations that normal JS functions have, but a quick visit to jsperf[0] seems to disprove this for modern browsers at least. Or perhaps that had more to do with inlining, since they are always created in the global context - an issue that does not apply to asm.js functions anyway. [0] https://jsperf.com/function-vs-constructor-vs-eval/7 https://jsperf.com/function-vs-constructor-vs-eval/7, https://jsperf.com/function-by-constructor https://jsperf.com/function-by-constructor
      - themihai 9y ago
        well it's supposed to be a fallback...you are aware that a fallback is just something better than nothing, right? There are several prototypes already (i.e. https://github.com/lukewagner/polyfill-prototype-1 https://github.com/lukewagner/polyfill-prototype-1 )
        vanderZwan 9y ago
        Of course, but I'm basically asking which of the two possible fallbacks would be better: - test for presence of WASM, if absent fetch the pre-compiled asm.js fallback - test for presence of WASM, if absent fetch an asm.js WASM compiler to runtime-compile WASM to asm.js. There's a potential a trade-off in both downloaded size (depending on how big the compiles asm.js file would be compared to WASM + asm.js-based compiler) and loading times. The prototype you linked looks cool though; too bad development on it seems to have stopped in early 2016. I'll copy their outline of how it works for the lazy: 1. On the main thread, the client kicks off a load of a URL by calling loadWebAssembly and receives a Promise<Function>. 2. The polyfill library starts up a worker containing asm.js code compiled from unpack.cpp concatenated with the glue code in load-wasm-worker.js. 3. The worker glue code fetches the binary via XHR then copies the result into the asm.js heap. 4. The asm.js code decodes the binary into asm.js in the form of UTF8 bytes in a separate region of the asm.js heap. 5. The worker glue code creates a Blob (a read-only copy) from a view of just the asm.js UTF8 bytes. 6. The Blob is postMessage()ed back to the main thread (a non-copying operation) where it is loaded as a script element with script.src = URL.getObjectURL(blob). 7. When the asm.js script is executed, it passes the asm.js module function object to a callback which resolves the promise in step 1.
golergka 9y ago
http://gs.statcounter.com/ http://gs.statcounter.com/ I think it's only relevant for business applications, as employees can't just easily switch browsers on their own. Consumer apps and games have a lot more leeway.
- krapp 9y ago
  It seems like we're never going to get away from the paradigm of developing for the web, then doing something else to cater to Microsoft's backwards problem child. It's not much different than having to ship a runtime for an app written in languages other than C/C++. WASM apps will just require the use of a proper browser. At some point the world has to cut the cord on IE anyway.
  - dspillett 9y ago
    > doing something else to cater to Microsoft's backwards problem child It isn't just old IE that can be a problem in corporate environments. I work on a product used by branch and admin staff in larger UK banks, and where an alternative is used it isn't usually an up-to-date one. For the largest instance of the app, the most common UA in IE11 (in various compatibility modes for extra confusion) but IE8 is still common enough that we have to care. They seem to have skipped IE9 and IE10 completely. Edge is nowhere to be seen but that is expected as I don't think they've moved beyond Windows 7 for the most part (I still see XP in use). Chrome is in use in some parts of the business, but not the latest: the Chrome versions witnessed in the last month range from 40 (released at the start of 2015) to 59 (much better, only four releases back, but still 6 months old). Though IE is the main problem, if you have commercial clients who use Chrome/Firefox/other you still need to be careful not to rely on enhancements that haven't been common for some time.
    - zerkten 9y ago
      This confirms that the root problem is distribution. Even when you have an "evergreen" platform like Chrome, you can hobble it by requiring deployment through a central IT team. This also opens up attack vectors against the organisation. Aside: I'd be really interested in whether these browser microclimates ever develop dependencies on old Chrome versions that end up being problematic to carry forward to newer versions.
userbinator 9y ago
I'll take the contrarian opinion here, and say that that is a good thing, if only for the fact that it "keeps the target from moving too quickly", as the saying goes. The slower the adoption of these fancy new features, the more chances for content to remain accessible to those who simply don't want to feed the hedgemony and use other alternative browsers. As it is, the situation is bad enough with developers/designers itching to hide otherwise simple, static, and accessible content behind massive bloated web apps. I feel WebAsm is going to make that even worse, because now they can go even further with obfuscation. When considering the state of the web as a whole, and one of its goals of wide access to information regardless of user-agent, if the presence of IE can slow the needless appification trend, IMHO that's a good thing. There's some more detailed discussion on that here: https://news.ycombinator.com/item?id=15836027 https://news.ycombinator.com/item?id=15836027 and in particular my comment at https://news.ycombinator.com/item?id=15836315 https://news.ycombinator.com/item?id=15836315 Also related: https://news.ycombinator.com/item?id=9961613 https://news.ycombinator.com/item?id=9961613
- kristiandupont 9y ago
  Information is one use case for the web. Apps are another. We agree that if people make apps where a static HTML file would suffice, that's a bad thing. However, for writing apps I think webassembly is going to greatly improve things for developers and users. I enjoy writing JS both for frontend and backend but the perspective of being able to write strictly in something like F# looks really appealing.
- krapp 9y ago
  I take issue with the inference that all attempts at expanding the types of content on the web are needless and "hegemonic," particularly as you're defending the greatest hegemon the web has ever known in making it. I would even argue that the ability to execute code on the web is more profound and revolutionary than the ability to only publish text. It's not unnecessary complexity, it's adding a new dimension to what the web will be capable of, and by extension, what users will be capable of. >. As it is, the situation is bad enough with developers/designers itching to hide otherwise simple, static, and accessible content behind massive bloated web apps. That bloat isn't a problem with the web itself, or with features added to the web, it's a problem with developers and coding trends, and the need to provide polyfills and shims to support IE.
send_computers 9y ago
Looking at the usage relative to browser support, the UC browser for Android is a bigger concern, no doubt it will add support soon unlike IE. See here and click 'usage relative': https://caniuse.com/#search=WebAssembly https://caniuse.com/#search=WebAssembly
- pluma 9y ago
  Unless your audience happens to be an exact mirror of the relative global browser stats, that is less than helpful. If 90% of your users are on IE, it's not enlightening to point out that those 90% only make up a tiny fraction of the global browser users.
onion2k 9y ago
Unless Microsoft ports Edge to Windows 7/8... Support for Windows 8 ends in a month[1]. There's extended support for some users for a further 5 years, but if you're doing client work rather than writing bespoke software for a specific user then IE, and Windows versions less than 10, are effectively dead and gone. It's perfectly reasonable to use web technologies that aren't supported by IE. Ideally you should have a bare HTML server-side alternative for those users, but that's true for everything that a user might not have (or have turned off, eg JS). [1] https://support.microsoft.com/en-gb/help/13853/windows-lifecycle-fact-sheet https://support.microsoft.com/en-gb/help/13853/windows-lifec...
- teilo 9y ago
  There are certain industries where these numbers are highly skewed toward Windows 7. Healthcare, hospitals in particular, are especially bad.
- pmlnr 9y ago
  > Windows versions less than 10, are effectively dead and gone That is not how this works.
- frik 9y ago
  End of patch support of Windows 7 is 2020, of Windows 8 is 2023, of Windows 10 Mobile is 2020, of rest of Windows 10 is 2025. No one cares about your PR speak. https://support.microsoft.com/en-us/help/13853/windows-lifecycle-fact-sheet https://support.microsoft.com/en-us/help/13853/windows-lifec...
  - jrs95 9y ago
    So, is Windows 10 not really the last major release? Or do they have an end of service date for it just as a formality, and it'll probably get extended repeatedly?
    - collinmanderson 9y ago
      "rest of Windows 10 is 2025" is not quite right. There are different versions/branches of Windows 10 that come out every 6 months or so. Some of the branches/versions are "Long term servicing branches" (LTSB) for enterprise environments, supported for 10 years. There are already two of those. https://en.wikipedia.org/wiki/Windows_10#Updates_and_support https://en.wikipedia.org/wiki/Windows_10#Updates_and_support For everyone else, the branches are supported for 18 months. https://technet.microsoft.com/en-us/windows/release-info.aspx?f=255&MSPPError=-2147217396 https://technet.microsoft.com/en-us/windows/release-info.asp... In reality Microsoft can stop supporting your computer's _hardware_ much earlier than that, if your device maker stops supporting it (reminds me of Andriod phones): > A device may not be able to receive updates if the device hardware is incompatible, lacking current drivers, or otherwise outside of the Original Equipment Manufacturer’s (“OEM”) support period. https://support.microsoft.com/en-us/help/13853/windows-lifecycle-fact-sheet https://support.microsoft.com/en-us/help/13853/windows-lifec... And they've already stopped supporting some devices: https://www.computerworld.com/article/3216005/microsoft-windows/microsofts-still-trying-to-figure-out-windows-10-support.html https://www.computerworld.com/article/3216005/microsoft-wind...
zitterbewegung 9y ago
I swear “supports all browsers” always means “supports all modern browsers”. No one seems to realize what Enterpriss deployments means anymore. Windows 7 deployments just finished for a bunch of those users and there is a huge cost to move to windows 10 or even adding a modern browser to your deployment.
baxuz 9y ago
That won't fix the problem, since IE11 is still available in Windows 10, and IE11 is supported until 20-freaking-25. That's 6 more years. Let that sink in for a bit. Seriously thinking about switching careers at this point.
- starik36 9y ago
  Wow, I was about to dismiss your comment because one would have to be some sort of sadomasochist to actually seek out IE 11 on a Windows 10 machine and use it on purpose. But according to Netmarketshare, fully 7% of Windows 10 users use IE. https://www.netmarketshare.com/browser-market-share.aspx?options=%7B%22filter%22%3A%7B%22%24and%22%3A%5B%7B%22platformVersion%22%3A%22Windows%2010%22%7D%5D%7D%2C%22dateLabel%22%3A%22Custom%22%2C%22attributes%22%3A%22share%22%2C%22group%22%3A%22browser%22%2C%22sort%22%3A%7B%22share%22%3A-1%7D%2C%22id%22%3A%22browsersDesktop%22%2C%22dateInterval%22%3A%22Monthly%22%2C%22dateStart%22%3A%222017-10%22%2C%22dateEnd%22%3A%222017-11%22%2C%22plotKeys%22%3A%5B%7B%22browser%22%3A%22Chrome%22%7D%2C%7B%22browser%22%3A%22Edge%22%7D%2C%7B%22browser%22%3A%22Firefox%22%7D%2C%7B%22browser%22%3A%22Internet%20Explorer%22%7D%5D%2C%22segments%22%3A%22-1000%22%7D https://www.netmarketshare.com/browser-market-share.aspx?opt... Insane.
- dbbk 9y ago
  I think you are being a bit overly dramatic, IE 11 is not that bad.

kowdermeister 9y ago

You can still ship an asm.js version there as a fallback.

jlebrech 9y ago
do webassembly compilers also compile the fallback?
- themihai 9y ago
  You could actually exec wasm with a JS/asm polyfill
  - Filligree 9y ago
    You want to run a bytecode interpreter in JS? What's battery life going to look like with that?
    - themihai 9y ago
      That should encourage the browser vendors to support wasm natively, right?
      - dbbk 9y ago
        They do? This article is about browser vendors supporting wasm.
        themihai 9y ago
        >> This article is about browser vendors supporting wasm. And my comment was about old browsers/OSes not supporting wasm.
        dbbk 9y ago
        The reason old browsers don't support WASM is because they can't go back in time... the modern versions do (for instance Edge).
  - vanderZwan 9y ago
    I'm sure you could, but wouldn't the added overhead defeat the purpose of using either WASM or asm.js? Serious question, because if this could work it's a fun example of "turtles all the way down" in programming. I can see two ways of interpreting your answer, and neither looks like it gives the desired performance benefits of a plain asm.js fallback: One: a WASM interpreter in asm.js. Given what this would imply for performance I'm pretty certain that this wasn't what you meant. Two: a WASM-to-asm.js compiler, possibly in asm.js, that can take downloaded WASM.js files, turn it into asm.js, then load it through the Function constructor. Assuming you meant the latter: do browsers even support loading asm.js that way? Assuming they do, this would still introduce extra overhead, having to download the compiler, and adding a compilation phase. Of course, since WASM files are binary, the benefit might be lower bandwidth use, so for slower connections it could be a net gain over plain asm.js... I also vaguely recall that functions creating with the Function constructor don't enjoy all the JIT-compiled optimisations that normal JS functions have, but a quick visit to jsperf[0] seems to disprove this for modern browsers at least. Or perhaps that had more to do with inlining, since they are always created in the global context - an issue that does not apply to asm.js functions anyway. [0] https://jsperf.com/function-vs-constructor-vs-eval/7 https://jsperf.com/function-vs-constructor-vs-eval/7, https://jsperf.com/function-by-constructor https://jsperf.com/function-by-constructor
    - themihai 9y ago
      well it's supposed to be a fallback...you are aware that a fallback is just something better than nothing, right? There are several prototypes already (i.e. https://github.com/lukewagner/polyfill-prototype-1 https://github.com/lukewagner/polyfill-prototype-1 )
      - vanderZwan 9y ago
        Of course, but I'm basically asking which of the two possible fallbacks would be better: - test for presence of WASM, if absent fetch the pre-compiled asm.js fallback - test for presence of WASM, if absent fetch an asm.js WASM compiler to runtime-compile WASM to asm.js. There's a potential a trade-off in both downloaded size (depending on how big the compiles asm.js file would be compared to WASM + asm.js-based compiler) and loading times. The prototype you linked looks cool though; too bad development on it seems to have stopped in early 2016. I'll copy their outline of how it works for the lazy: 1. On the main thread, the client kicks off a load of a URL by calling loadWebAssembly and receives a Promise<Function>. 2. The polyfill library starts up a worker containing asm.js code compiled from unpack.cpp concatenated with the glue code in load-wasm-worker.js. 3. The worker glue code fetches the binary via XHR then copies the result into the asm.js heap. 4. The asm.js code decodes the binary into asm.js in the form of UTF8 bytes in a separate region of the asm.js heap. 5. The worker glue code creates a Blob (a read-only copy) from a view of just the asm.js UTF8 bytes. 6. The Blob is postMessage()ed back to the main thread (a non-copying operation) where it is loaded as a script element with script.src = URL.getObjectURL(blob). 7. When the asm.js script is executed, it passes the asm.js module function object to a callback which resolves the promise in step 1.

golergka 9y ago

http://gs.statcounter.com/ http://gs.statcounter.com/ I think it's only relevant for business applications, as employees can't just easily switch browsers on their own. Consumer apps and games have a lot more leeway.

krapp 9y ago
It seems like we're never going to get away from the paradigm of developing for the web, then doing something else to cater to Microsoft's backwards problem child. It's not much different than having to ship a runtime for an app written in languages other than C/C++. WASM apps will just require the use of a proper browser. At some point the world has to cut the cord on IE anyway.
- dspillett 9y ago
  > doing something else to cater to Microsoft's backwards problem child It isn't just old IE that can be a problem in corporate environments. I work on a product used by branch and admin staff in larger UK banks, and where an alternative is used it isn't usually an up-to-date one. For the largest instance of the app, the most common UA in IE11 (in various compatibility modes for extra confusion) but IE8 is still common enough that we have to care. They seem to have skipped IE9 and IE10 completely. Edge is nowhere to be seen but that is expected as I don't think they've moved beyond Windows 7 for the most part (I still see XP in use). Chrome is in use in some parts of the business, but not the latest: the Chrome versions witnessed in the last month range from 40 (released at the start of 2015) to 59 (much better, only four releases back, but still 6 months old). Though IE is the main problem, if you have commercial clients who use Chrome/Firefox/other you still need to be careful not to rely on enhancements that haven't been common for some time.
  - zerkten 9y ago
    This confirms that the root problem is distribution. Even when you have an "evergreen" platform like Chrome, you can hobble it by requiring deployment through a central IT team. This also opens up attack vectors against the organisation. Aside: I'd be really interested in whether these browser microclimates ever develop dependencies on old Chrome versions that end up being problematic to carry forward to newer versions.

userbinator 9y ago

I'll take the contrarian opinion here, and say that that is a good thing, if only for the fact that it "keeps the target from moving too quickly", as the saying goes. The slower the adoption of these fancy new features, the more chances for content to remain accessible to those who simply don't want to feed the hedgemony and use other alternative browsers. As it is, the situation is bad enough with developers/designers itching to hide otherwise simple, static, and accessible content behind massive bloated web apps. I feel WebAsm is going to make that even worse, because now they can go even further with obfuscation. When considering the state of the web as a whole, and one of its goals of wide access to information regardless of user-agent, if the presence of IE can slow the needless appification trend, IMHO that's a good thing. There's some more detailed discussion on that here: https://news.ycombinator.com/item?id=15836027 https://news.ycombinator.com/item?id=15836027 and in particular my comment at https://news.ycombinator.com/item?id=15836315 https://news.ycombinator.com/item?id=15836315 Also related: https://news.ycombinator.com/item?id=9961613 https://news.ycombinator.com/item?id=9961613

kristiandupont 9y ago
Information is one use case for the web. Apps are another. We agree that if people make apps where a static HTML file would suffice, that's a bad thing. However, for writing apps I think webassembly is going to greatly improve things for developers and users. I enjoy writing JS both for frontend and backend but the perspective of being able to write strictly in something like F# looks really appealing.
krapp 9y ago
I take issue with the inference that all attempts at expanding the types of content on the web are needless and "hegemonic," particularly as you're defending the greatest hegemon the web has ever known in making it. I would even argue that the ability to execute code on the web is more profound and revolutionary than the ability to only publish text. It's not unnecessary complexity, it's adding a new dimension to what the web will be capable of, and by extension, what users will be capable of. >. As it is, the situation is bad enough with developers/designers itching to hide otherwise simple, static, and accessible content behind massive bloated web apps. That bloat isn't a problem with the web itself, or with features added to the web, it's a problem with developers and coding trends, and the need to provide polyfills and shims to support IE.

send_computers 9y ago

Looking at the usage relative to browser support, the UC browser for Android is a bigger concern, no doubt it will add support soon unlike IE. See here and click 'usage relative': https://caniuse.com/#search=WebAssembly https://caniuse.com/#search=WebAssembly

pluma 9y ago
Unless your audience happens to be an exact mirror of the relative global browser stats, that is less than helpful. If 90% of your users are on IE, it's not enlightening to point out that those 90% only make up a tiny fraction of the global browser users.

onion2k 9y ago

Unless Microsoft ports Edge to Windows 7/8... Support for Windows 8 ends in a month[1]. There's extended support for some users for a further 5 years, but if you're doing client work rather than writing bespoke software for a specific user then IE, and Windows versions less than 10, are effectively dead and gone. It's perfectly reasonable to use web technologies that aren't supported by IE. Ideally you should have a bare HTML server-side alternative for those users, but that's true for everything that a user might not have (or have turned off, eg JS). [1] https://support.microsoft.com/en-gb/help/13853/windows-lifecycle-fact-sheet https://support.microsoft.com/en-gb/help/13853/windows-lifec...

teilo 9y ago
There are certain industries where these numbers are highly skewed toward Windows 7. Healthcare, hospitals in particular, are especially bad.
pmlnr 9y ago
> Windows versions less than 10, are effectively dead and gone That is not how this works.
frik 9y ago
End of patch support of Windows 7 is 2020, of Windows 8 is 2023, of Windows 10 Mobile is 2020, of rest of Windows 10 is 2025. No one cares about your PR speak. https://support.microsoft.com/en-us/help/13853/windows-lifecycle-fact-sheet https://support.microsoft.com/en-us/help/13853/windows-lifec...
- jrs95 9y ago
  So, is Windows 10 not really the last major release? Or do they have an end of service date for it just as a formality, and it'll probably get extended repeatedly?
  - collinmanderson 9y ago
    "rest of Windows 10 is 2025" is not quite right. There are different versions/branches of Windows 10 that come out every 6 months or so. Some of the branches/versions are "Long term servicing branches" (LTSB) for enterprise environments, supported for 10 years. There are already two of those. https://en.wikipedia.org/wiki/Windows_10#Updates_and_support https://en.wikipedia.org/wiki/Windows_10#Updates_and_support For everyone else, the branches are supported for 18 months. https://technet.microsoft.com/en-us/windows/release-info.aspx?f=255&MSPPError=-2147217396 https://technet.microsoft.com/en-us/windows/release-info.asp... In reality Microsoft can stop supporting your computer's _hardware_ much earlier than that, if your device maker stops supporting it (reminds me of Andriod phones): > A device may not be able to receive updates if the device hardware is incompatible, lacking current drivers, or otherwise outside of the Original Equipment Manufacturer’s (“OEM”) support period. https://support.microsoft.com/en-us/help/13853/windows-lifecycle-fact-sheet https://support.microsoft.com/en-us/help/13853/windows-lifec... And they've already stopped supporting some devices: https://www.computerworld.com/article/3216005/microsoft-windows/microsofts-still-trying-to-figure-out-windows-10-support.html https://www.computerworld.com/article/3216005/microsoft-wind...

zitterbewegung 9y ago

I swear “supports all browsers” always means “supports all modern browsers”. No one seems to realize what Enterpriss deployments means anymore. Windows 7 deployments just finished for a bunch of those users and there is a huge cost to move to windows 10 or even adding a modern browser to your deployment.

baxuz 9y ago

That won't fix the problem, since IE11 is still available in Windows 10, and IE11 is supported until 20-freaking-25. That's 6 more years. Let that sink in for a bit. Seriously thinking about switching careers at this point.

starik36 9y ago
Wow, I was about to dismiss your comment because one would have to be some sort of sadomasochist to actually seek out IE 11 on a Windows 10 machine and use it on purpose. But according to Netmarketshare, fully 7% of Windows 10 users use IE. https://www.netmarketshare.com/browser-market-share.aspx?options=%7B%22filter%22%3A%7B%22%24and%22%3A%5B%7B%22platformVersion%22%3A%22Windows%2010%22%7D%5D%7D%2C%22dateLabel%22%3A%22Custom%22%2C%22attributes%22%3A%22share%22%2C%22group%22%3A%22browser%22%2C%22sort%22%3A%7B%22share%22%3A-1%7D%2C%22id%22%3A%22browsersDesktop%22%2C%22dateInterval%22%3A%22Monthly%22%2C%22dateStart%22%3A%222017-10%22%2C%22dateEnd%22%3A%222017-11%22%2C%22plotKeys%22%3A%5B%7B%22browser%22%3A%22Chrome%22%7D%2C%7B%22browser%22%3A%22Edge%22%7D%2C%7B%22browser%22%3A%22Firefox%22%7D%2C%7B%22browser%22%3A%22Internet%20Explorer%22%7D%5D%2C%22segments%22%3A%22-1000%22%7D https://www.netmarketshare.com/browser-market-share.aspx?opt... Insane.
dbbk 9y ago
I think you are being a bit overly dramatic, IE 11 is not that bad.