Gtk+ and WPF have very good support for people with disabilities.
The harm to disabled users remains.
HTML5 was there to obsolete quirky flash/silverlight/java applets and tell people to not to confuse code and the content, now main "web ecosystem pushers" are doing everything to reincarnate Flash in a new embodiment as WASM
I can't think of a single site that works like you are saying, yet webasm would only be a 2x-8x speedup over existing techniques.
WebAssembly on the long run will enable to bypass JavaScript and target the browser as if it is yet another OS.
I did actually, because most aren't around any more. Even so, I was talking about sites that purely use the html canvas to draw. There is nothing preventing websites from being built like that right now, so I don't see how webasm will make much of a difference.
Web Assembly would allow devs to build apps without any html or javascript or css.
The UI construct could be WPF/XAML or even WinForms like tech or something new.
Scripting and CSS would be entirely unnecessary. A lot of businesses would love nothing better than to dump the Jedi-like skills of the scripting developers and trade that for mundane forms skills.
HTML, javascript and CSS are easier than C, C++ or Rust. Writing a website in HTML/CSS/JS and updating a website in HTML/CSS/JS are vastly simpler than writing a graphical application then rewriting and recompiling it.
As with Flash, WebAssembly will be implemented as fully integrated apps where it makes business sense, which will probably be a limited number of cases, such as graphics or media delivery. Everywhere else, it will either not be implemented at all, or be used alongside JS in the existing web.
Qt, Delphi, WPF are miles ahead in terms of tooling in what a pile of HTML, CSS and JavaScript are capable of.
Anvil and tools like OutSystems are probably the one thing that comes close to what Blend is capable of.
Having a pixel perfect WYSIWYG GUI designer, with a components market, painless DB integration and deploying to the web at the press of a button will get lots of enterprise love.
Not every site is a business site and not every business with a website has the budget or impetus to chase the bleeding edge of web development. HTML and javascript will continue to exist and be supported by browsers for the forseeable future (meaning the option to choose not to use WASM will also always be there.) Billions and billions of sites already on the web which would have to be completely taken down and rebuilt for no practical reason.
I look forward to the age of embedded binary apps on the web . I think the web is the only real option we have to preserve software long-term, and the likelihood of software being preserved is enhanced by that software remaining executable. But even in my wildest fantasies where every program ever written maps to a URL, I doubt that use case will take up more than a fraction of online content. The web is just too big and too complex and too general to reduce to any single heuristic or use case.
People are still using COBOL and Perl and pushing code to production with Notepad++ and Filezilla. The real world doesn't optimize the way you're suggesting it would. The business world certainly doesn't.
We're just saying the developer and deployment optimization story would be vastly simplified without the JS/HTML/CSS stack.
Those of us who remember what development was like before "front-end" development as it is today know that story very well. The amount of undocumented, untested, and wonky code in the current web stack has always seemed ridiculous to us.
The problem with ActiveX, Flash, Silverlight, and OneClick was never about the developer story. It was about security and openness. WebAssembly solves both of those problems.
Open tools, pixel-perfect GUI design, compilers and debuggers, and strongly-typed languages would absolutely reduce the amount of HTML/JS/CSS in the world. It may not kill all of it, but it would put a sizable dent in it.
With WebAssembly you can bypass all of it, and do your UI framework in GL, and everything else with native libraries compiled into WebAssembly.
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].
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.
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.
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...
Just, don't. Please don't do that.
I really think it will bring Flash like web sites back, and browser vendors are the ones actually pushing it.
The wheels are already in motion, with everyone trying to port their favorite language or VM into WebAssembly.
For example, today it is Qt WebGL Streaming, tomorrow it might just run directly from WebAssembly.
http://blog.qt.io/blog/2017/07/07/qt-webgl-streaming-merged/
It will be up to those frameworks to provide usability support, like WPF does for Windows.
"Add support for WebAssembly as target platform for Qt
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 …
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.