Which is a terrible usability nightmare waiting to happen...
Seriously, DON'T do this. This breaks ctrl-f. This is unlikely to work well for people who need to enlarge text or enhance contrast due to vision impairment. This breaks screen readers. This will probably break most site archive navigators, so your content is lost to history (e.g. wayback machine). This will probably prevent Google from indexing your site, killing your page ranking and driving away potential customers. Even if you re-implement all the things you think it will break, you'll find that your users have things set up in ways you'd never considered...
Welcome to the Modern Web. Not sure if you noticed, but most web developers don't give a flying fuck about usability (despite what their company blogs say). A broken navigation is something you encounter daily on the Internet. CTRL+F still kinda works - it can scroll you to the more-less right area of the screen, but quite often the text you search for isn't highlighted anymore. Right-click is routinely broken (most recently with stupid-ass "social sharing" context menus). Copy-paste is routinely broken with stupid inventions that alter the contents of your clipboard in hope you don't notice the extra URL in there. Modern websites turn your computer into a frying pan with the shit ton of JS they execute, most of which is not only unnecessary, but also actively hostile. And/or mine cryptocoins, because it's almost 2018, so we need more dumb inventions.
It's a long topic, but basically boils down to companies being greedy and not giving a fuck about their users, and web developers being too busy chasing shiny to stop and care about actually providing value to users.
> you'll find that your users have things set up in ways you'd never considered...
Web companies don't care. They aim for the majority, which is users with popular browsers on default settings, without ad blockers and any plugins.
WebAssembly doesn't change this. There's nothing preventing people from doing this with javascript (plain or asm.js flavored) and canvas/webGL, and yet no one does. It just doesn't make a lot of sense.
So? My point is that most who relies on client-side code to render apps, does so in a way that integrates nicely with the browser. Most JS apps render html, they don't draw to a canvas. They could do that, but it would break a lot of functionality that people expect for a program that runs in a browser. This won't change with webasm. It will just make such pages load (and maybe perform) faster.
> This will probably prevent Google from indexing your site, killing your page ranking and driving away potential customers.
Actually, it wouldn't surprise me if Google used some sort of AI to recognise the resulting images of text. What this would do is make it exponentially more difficult to start a search competitor to Google. Which might explain why Google is all-in on WebAssembly …
There are reasonable people, who would only do this for applications (such as games or maps), and never for documents. Then there are those who require JavaScript for simple walls of texts.
But why on earth would you do that? That would be like bypassing the native UI framework on iOS or Android. It gives a worse experience for users, and is likely more work for you, the developer.
You can, theoretically, but it isn't practical because of the large amount of Javascript that would need to be downloaded and parsed. The WebAssembly's purpose is to remove that limitation, which is going to trash what's left of the open web. Get ready for lots of websites becoming un-adblockable, accessibility-hostile, "custom ui" trash.
> hasn't been a deterrent to anyone for anything yet
This is patently incorrect. Javascript's impact on page load time is so widespread that Google introduced AMP to "enables the creation of websites and ads that are consistently fast ... and high-performing"[1].
If it had been a deterrent, people wouldn't have done it, and we wouldn't have slow loading pages in the first place, and Google wouldn't have an AMP initiative. However, We have slow loading pages, and Google has AMP, which means that load speeds hasn't deterred stopped anyone from adding a ton of JS bloat
Go look at any major site in the wild right now. They all download several MB of JS. Facebook is 1.8MB of JS out of 3.9MB. The BBC is 1.6MB out of 3.8MB. Kotaku is 2.6MB out of 7.5MB. CNN is 2.8MB out of 6.5MB. Hell, here's an article complaining about the size of websites that itself downloads almost 1MB of JS: https://gigaom.com/2014/12/29/the-overweight-web-average-web...
I've written multiplayer VR experiences that run cross-platform through the browser that only clock in at 500KB of JS. You can put a LOT of code in a MB.
You are saying the same thing as he is. Javascript's impact on load time hasn't been a deterrent to people using mountains of bloat in their page.
Thus, webasm being a few times faster to download and parse won't change a whole lot, since few web developers seem to care much about the speed of their pages.
If webasm won't change much, then it isn't reasonable to predict a future of web pages that simply render to the canvas.
You could, but it's a pain and doesn't add much. With this you could in theory port GTK or Qt to WebAssembly and then simply change a compile flag and have your C++ GUI app running on the web.
You can do all that with JS too. Wasm adds nothing extra. It's perfectly sensible to imagine wasm applications targeting the DOM (which it can do via JS, and will do natively in later releases) just like JS applications do now.
