Hacker News Reader

Comment by Longhanks | Hacker News Reader

With all major browser JIT compiling JavaScript, aren't they already?

No, because it still is the pile of HTML, CSS and JavaScript hacks.

With WebAssembly you can bypass all of it, and do your UI framework in GL, and everything else with native libraries compiled into WebAssembly.

Why couldn't you do that now with canvas?

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.

Needing to download a large amount of JavaScript hasn't been a deterrent to anyone for anything yet. These arguments against WebAssembly are just FUD.

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

[1] https://www.ampproject.org/

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.

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

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.

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

Just, don't. Please don't do that.

Too late, WebAssembly is already here.

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.

Actually,

"Add support for WebAssembly as target platform for Qt

https://bugreports.qt.io/browse/QTBUG-63917

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.

Try to disable JavaScript and see how much of the modern Web you are able to enjoy, even on sites which are supposed to display static text.

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.

The point is that wasm doesn't change this; wasm won't make it 'worse'.

Are you suggesting that content providers shouldn't be able to control who can select/copy/save the text on their websites? What are you, a communist?

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.

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

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.

Yeah you can but then you have exactly the same problems as a browser render so I'm not sure it's useful.

Accessibility?

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 don't need WebAssembly to invent your own UI in a canvas. WebGL and all that works from Javascript.

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.

Reply on news.ycombinator.com