Hacker News Reader

Comment by starik36 | Hacker News Reader

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

View on HN

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 and in particular my comment at https://news.ycombinator.com/item?id=15836315

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.

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.

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

The guys behind Java applets, Flash, ActiveX, Silver light etc all thought that exact same thing.

And they were right.

But all of those required plugins or proprietary code in a single language, whereas Webassembly is intended serve as a proper bytecode for any supported language, and it's not owned by any particular company.

> because now they can go even further with obfuscation.

They'll be able to go just as far: too far for you to be able to make sense of it. WebAssembly or not, that ship has sailed.

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

> Windows versions less than 10, are effectively dead and gone

That is not how this works.

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

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?

"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

For everyone else, the branches are supported for 18 months. 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-lifec...

And they've already stopped supporting some devices: https://www.computerworld.com/article/3216005/microsoft-wind...

Having worked for the federal government, let me assure you, Windows 7 will be around for a long time. But let me give a better example: Samsung mobile devices. Since Samsung was so clever in naming their default browser "The Internet", there are a metric ton of folks who will be using that browser on their Galaxy S5s for a few more years. I think many underestimate those two groups, the ones that won't upgrade due to simply misunderstanding the whole mechanism, and the ones that are locked in by government infrastructure.

Those are reasons to offer fallbacks and alternatives for users who don't have access to an up-to-date browser. They're not reasons to ignore modern web technologies that are a good fit for the problem you're solving.

> Windows versions less than 10, are effectively dead and gone.

Ha! Don't we all wish. Here's the marketshare numbers from this month [1].

- Windows 7: 43%

- Windows 10: 30%

- Windows XP: 6%

- Windows 8: 5%

And companies are going to be buying extended support for 7 no different than XP so you'll have to wait out that 5 years.

[1] https://www.netmarketshare.com/operating-system-market-share...

My point is that once Microsoft no longer supports any version of Windows that runs IE as it's default there's a very valid reason to stop supporting it as a 'mainstream browser', and using it to avoid technologies that aren't supported by it is somewhat dubious reasoning.

If users with IE6 and users with IE11 get a boring HTML-only-but-still-basically-functional website, and users with Edge 15 get the fancy WASM enhanced website, then that's fine in my opinion.

> IE as it's default

So even though Windows 10 still ships IE the fact that it's not a default is enough to not support it? Bad news for Firefox and Chrome then.

> If users with IE6...

Sure, albeit a bit extreme, that's more or less progressive enhancement.

So even though Windows 10 still ships IE the fact that it's not a default is enough to not support it? Bad news for Firefox and Chrome then.

Using Firefox or Chrome is a step sideways to use an alternative browser. That's great. The more up-to-date browsers people use the better in my opinion.

Using IE is a step backwards usually to support a specific technology that isn't supported by other browsers (and IE is often used along side another browser if that's the case), or because the user is looking for a particular experience. I don't see either of those reasons to avoid using WASM on a new website so long as there's also a fallback to support browsers without it, even if that's a limited version of the site.

Windows 7 support doesn't end until 2020 and as someone pointed out on HN this a few days ago, Windows 10 IoT and LTSB don't come with Edge, they do come with IE11. Those aren't meant for desktop use but some people do use LTSB there and they could be used for browser-based digital signage, kiosks, etc.

I agree that older browsers can get basically functional while others can get a progressively enhanced experience but a lot developers hate the idea of making something twice. Also, for what WASM is best suited for, I don't know that there's a point to making a basic, HTML-only version.

Edit: I wasn't thinking about WASM support through polyfill, I don't know what the performance difference is typically like.

https://www.netmarketshare.com is biased towards US corporate market but doesn't represents the real world. Check wikipedia stats for more generic stats worldwide. What really matters though is the stats of your web site, not the rest. eg. debian.org does not have the same stats as msdn.com.

There are certain industries where these numbers are highly skewed toward Windows 7. Healthcare, hospitals in particular, are especially bad.

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.

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.

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?opt...

Insane.

I think you are being a bit overly dramatic, IE 11 is not that bad.

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

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.

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

do webassembly compilers also compile the fallback?

You could actually exec wasm with a JS/asm polyfill

You want to run a bytecode interpreter in JS? What's battery life going to look like with that?

That should encourage the browser vendors to support wasm natively, right?

They do? This article is about browser vendors supporting wasm.

>> This article is about browser vendors supporting wasm.

And my comment was about old browsers/OSes not supporting wasm.

The reason old browsers don't support WASM is because they can't go back in time... the modern versions do (for instance Edge).

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-by-constructor

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 )

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.

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.

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.

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

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.

Reply on news.ycombinator.com