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

21–30 of 259 posts

Re: Introduction to WebAssembly: why should we care?

#21

Post by TomMarius »

pjmlp wrote: post #16
skohan wrote: post #8

Earlier quoted context omitted.

> I long for the days when simple images and text were the norm. The main issue with the web currently is that tools designed for the purpose of displaying simple images and text, plus a little interactivity, are being stretched to realize complex applications. Powerful on-demand applications on the web are a good thing, and it's a good thing that we're finally getting the tools to build them properly.

We already had them, WebAssembly adds little to Flash, Java applets, Oberon Juice, ActiveX, Silverlight, other than a format that makes all browser vendors happy. I can easily imagine that Adobe R&D already has a working WebAssembly prototype for Flash.

Not true. A good security model is added.

Re: Introduction to WebAssembly: why should we care?

#24

Post by pjmlp »

TomMarius wrote: post #21
pjmlp wrote: post #16

Earlier quoted context omitted.

We already had them, WebAssembly adds little to Flash, Java applets, Oberon Juice, ActiveX, Silverlight, other than a format that makes all browser vendors happy. I can easily imagine that Adobe R&D already has a working WebAssembly prototype for Flash.

Not true. A good security model is added.

It remains to be tested on the wild.

Lets see when the first examples pop up on Project Zero or CCC.

Re: Introduction to WebAssembly: why should we care?

#25

Post by emj »

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.

Agreed since the toolchain is aimed at automatic conversion of C/C++ applications to WebAssembly, emulating filesystems, graphics etc, that makes it feel sluggish for me. At this point I haven't seen many people using WebAssembly directly to develop for the web. Mostly it's people who write to a canvas.

This game logic in Rust was a good example of at least some communication with javascript in a non bloated way:

https://news.ycombinator.com/item?id=15843064 https://aochagavia.github.io/js/embedded-rocket.js

Re: Introduction to WebAssembly: why should we care?

#26

Post by endless1234 »

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.

Why couldn't you do that now with canvas?

Re: Introduction to WebAssembly: why should we care?

#27

Post by rekado »

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't think this is desirable.

Granted, we already have this problem with plain minified JavaScript, but as we shift more towards treating the web as a platform for which to compile software, this problem is going to become worse.

I'd love for the web to be a set of stable application interfaces that in-browser applications can talk to. Give me the sources and I'll use my package manager to build the JavaScript applications I want my browser to execute for particular online services. I want more control over the increasingly complex software that we're expected to just execute blindly upon reception.

[1]: https://www.gnu.org/philosophy/javascript-trap.html

Re: Introduction to WebAssembly: why should we care?

#28

Post by alex_duf »

MistahKoala wrote: post #17

For non-dev idiots like me, what is it and why is it special? I got the impression that it allows compiled scripts to run in the browser and is faster than JavaScript.

It potentially allows any language (C, C++, Rust, .NET, heck in the future maybe Java, Scala or anything you want) to be run inside a webbrowser, at near native speed.

Because any language would be compiled to this intermediate form (wasm) it would drastically simplify the distribution of complex applications.

Because any language can be compiled to that form, you can potentially reuse your existing company's code to run it inside a webbrowser

Because it's already integrated in web browsers, it means the technology deployment promise to be quick.

Because it's just an intermediary form, you can use a typesafe language (Javascript isn't) and still use it at native speed rather than going through a step of conversion to javascript.

It's still missing a few key things (garbage collection, interaction with the DOM) but I see that as being the new standard for pretty much anything. I can see that being used everywhere, from server side to client side, to mobile devices, why not hardware support (Is that possible?)

Re: Introduction to WebAssembly: why should we care?

#29

Post by pdkl95 »

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.wikipedia.org/wiki/Halting_problem

Re: Introduction to WebAssembly: why should we care?

#30

Post by JSONwebtoken »

I haven't been able to find many examples of working WASM projects or experiments for a topic I have been hearing about for years, but here's one that seemed pretty well made:

https://d2jta7o2zej4pf.cloudfront.net/

However it appears all the video editting effects render slower through WASM than JS, what's the deal?

Post reply on HN