Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Introduction to WebAssembly: why should we care?

tomassetti.me

Post reply on HN
Print view View original

41–50 of 259 posts

Re: Introduction to WebAssembly: why should we care?

#41

Post by pjmlp »

Figs wrote: post #31
pjmlp wrote: post #11

Earlier quoted context omitted.

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.

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

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.

Re: Introduction to WebAssembly: why should we care?

#42

Post by dagw »

endless1234 wrote: post #26
pjmlp wrote: post #11

Earlier quoted context omitted.

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

Re: Introduction to WebAssembly: why should we care?

#43

Post by yipopov »

aaron-lebo wrote: post #14

I can't tell immediately, but is there anything that compiles WASM to something native? As in I'd like to write some WASM and then compile that to a shared library that a C program could load in.

Why go from WASM to native? If you're using LLVM to get your WASM, just go directly to native, if other, find a native implementation of the language you're using.

Re: Introduction to WebAssembly: why should we care?

#44

Post by realusername »

pjmlp wrote: post #11
Longhanks wrote: post #7

Earlier quoted context omitted.

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.

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

Re: Introduction to WebAssembly: why should we care?

#45

Post by _red »

osrec wrote: post #5

I know a lot of people long for the days when the web was just text and a few JPGs. I personally am waiting for the web to become a rich, ubiquitous, standardised application delivery platform that works on any device. I think web assembly adds to the richness while being fairly standardised, so I welcome it!

These things are cyclical:

* Early computers (1960-1980s): Dumb Terminal - Remote Server

* Early PCs (1980s-1995): Local Processing - Remote Storage

* WWW (1995-2010s): Dumb Terminal - Remote Server

* JS/ASM/Etc (2010s - near future): Local Processing - Remote Storage

Its fully possible that we will switch again to dumb terminal model. For instance, once the hassle of local code execution takes it toll, someone will have the bright idea of just putting the web browser itself in the cloud and just having a remote control connection to that browser....and the cycle will begin again.

Re: Introduction to WebAssembly: why should we care?

#46

Post by hmmmmnm »

pdkl95 wrote: post #29

Remember that WebAssembly means no more ad blockers as soon as someone ports freetype. The behavior of a program written in a Turing complete language cannot be predicted without running the program[1]. Ad-blocking by regexp or DOM element doesn't help when the entire contents of the page - including the ads - is just a bunch of {canvas,WebGL} draw calls generated by a blob of obfuscated code. [1] https://en.wikipedi…

How is this any different to rendering to canvas or WebGL using minified and obfuscated Javascript?

WebAssembly is just a more compact representation.

Re: Introduction to WebAssembly: why should we care?

#47

Post by hood_syntax »

_red wrote: post #45
osrec wrote: post #5

I know a lot of people long for the days when the web was just text and a few JPGs. I personally am waiting for the web to become a rich, ubiquitous, standardised application delivery platform that works on any device. I think web assembly adds to the richness while being fairly standardised, so I welcome it!

These things are cyclical: * Early computers (1960-1980s): Dumb Terminal - Remote Server * Early PCs (1980s-1995): Local Processing - Remote Storage * WWW (1995-2010s): Dumb Terminal - Remote Server * JS/ASM/Etc (2010s - near future): Local Processing - Remote Storage Its fully possible that we will switch again to dumb terminal model. For instance, once the hassle of local code execution takes it toll, someone will…

Yeah, if we want latency added to literally every action... I understand that what you're saying is a possibility, but I sure hope it doesn't come to pass.

Re: Introduction to WebAssembly: why should we care?

#48

Post by umilegenio »

jokoon wrote: post #13

The toolchain feels pretty clumsy and bloated, there are many intermediary stages that should be done automatically. I hope better alternatives will quickly become available, or at least some package where you don't to install a thing inside the thing you already downloaded and installed.

I agree. At the moment you can use WebAssembly, but it is not exactly user friendly. Effectively they have only build tools that can work inside other tools or as a part of an existing toolchain.

However, the end game is to be able to load a WebAssembly module just like you load a JS script. So, we are going to get there, but it will take some time.

Re: Introduction to WebAssembly: why should we care?

#49

Post by Vinnl »

rekado wrote: post #27

I'm worried that this will make the JavaScript trap[1] even more of a problem. The default operation of the web is to allow remote sites to push non-free applications to your browser that it then proceeds to execute. As people have been shifting towards running everything in the browser (just like people like me run everything in Emacs), this effectively results in a revival of ubiquitous proprietary software. I don'…

This is hardly inherent to Javascript/WebAssembly. Installed applications are binary code, i.e. closed by default unless you explicitly provide source code. The same holds true for web applications, however, for some reason we don't care about it being open source that much anymore...

Re: Introduction to WebAssembly: why should we care?

#50

Post by umilegenio »

GrumpyNl wrote: post #10

From the site: The kind of binary format being considered for WebAssembly can be natively decoded much faster than JavaScript can be parsed (experiments show more than 20× faster). On mobile, large compiled codes can easily take 20–40 seconds just to parse, so native decoding (especially when combined with other techniques like streaming for better-than-gzip compression) is critical to providing a good cold-load user…

You are right only for the average website. If you are building applications delivered through the web, like games and advanced webmail, it can take a few seconds right now. With WebAssembly you could basically create all desktop applications on the web and it would be perfectly reasonable to take a few seconds to load one of them.
Post reply on HN