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

71–80 of 259 posts

Re: Introduction to WebAssembly: why should we care?

#71

Post by GrumpyNl »

dingo_bat wrote: post #65
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…

Gmail takes around 5 seconds to load over a 100mbit connection. Seems to not have posed any problem for them.

2 and 5 seconds are far away from 20-40.

Re: Introduction to WebAssembly: why should we care?

#72

Post by loup-vaillant »

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!

Problem is, adding to the bl… sorry, richness, doesn't remove the old cruft.

How about having an application platform that would be just an application platform? No HTML, no CSS, no built in multimedia. Just a VM, a viewport, audio, and inputs (and local storage if the user allows it).

Re: Introduction to WebAssembly: why should we care?

#73

Post by umilegenio »

Fifer82 wrote: post #19

I am still a bit baffled. I am a TypeScript user and in the article he states: For instance, instead of compiling TypeScript to JavaScript, its developers could now compile to WebAssembly. Alright, so I don't need to be a C/C++ dude to get some WebAssembly goodness (maybe some day). But now with this in my toolbelt. What occurs? What does it mean? If I have a particle simulation in TypeScript on Canvas using Shaders.…

The end game is to have a WebAssembly module that you can load just like you now load a JS script. When we get there, there will also be (probably[1]) easy methods to access the DOM from WebAssembly.

At the moment the easiest way would probably be to write some glue code in JavaScript (see Let’s write Pong in WebAssembly https://medium.com/@mbebenita/lets-write-pong-in-webassembly...).

[1] https://github.com/WebAssembly/gc/blob/master/proposals/gc/O...

Re: Introduction to WebAssembly: why should we care?

#74

Post by Normal_gaussian »

tzahola wrote: post #55
c-cube wrote: post #35

Earlier quoted context omitted.

Currently you can block many ads based on their url (which is from a third party provider). Using umatrix, ad and tracking is often clearly marked in red, and the corresponding js never even loaded. I don't think that would change with webasm?

Websites will be obfuscated blobs downloaded from a single server.

That's possible now. You can serve the ad so its indistinguishable from any other image. Redirect it and clicks through your server. Give it an obfuscated DOM path.

Its just a hassle and can't be done with pasting a line of code

Re: Introduction to WebAssembly: why should we care?

#75

Post by erikj »

Fifer82 wrote: post #19

I am still a bit baffled. I am a TypeScript user and in the article he states: For instance, instead of compiling TypeScript to JavaScript, its developers could now compile to WebAssembly. Alright, so I don't need to be a C/C++ dude to get some WebAssembly goodness (maybe some day). But now with this in my toolbelt. What occurs? What does it mean? If I have a particle simulation in TypeScript on Canvas using Shaders.…

You can access Canvas in WebAssembly, no problem here.

Re: Introduction to WebAssembly: why should we care?

#76

Post by flohofwoe »

loup-vaillant wrote: post #72
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!

Problem is, adding to the bl… sorry, richness , doesn't remove the old cruft. How about having an application platform that would be just an application platform? No HTML, no CSS, no built in multimedia. Just a VM, a viewport, audio, and inputs (and local storage if the user allows it).

I'm all for building from scratch a lean minimal runtime platform as you describe (that's what operating systems should be), also it should be "easy", take a minimal Linux kernel and add some thin APIs on top. But good luck turning this into a project that gains any traction.

Using the browser platform to bootstrap such a thing isn't such a bad idea in comparison... sooner than later we need to depreciate the ugly parts, like WebRTC, WebAudio and trim some fat here and there, but other platforms have their ugly parts as well (look at the mess that is Android).

Re: Introduction to WebAssembly: why should we care?

#77

Post by mikegerwitz »

rekado wrote: post #66
pjmlp wrote: post #37

Earlier quoted context omitted.

Proprietary software doesn't need any revival, because it never went away. The irony is that proprietary browser based software happens to run on top of FOSS libraries and languages, which most companies hardly contribute anything back.

> Proprietary software doesn't need any revival, because it never went away. True, though we have reached a point where one could be really comfortable without proprietary software. I certainly am. It's just with an increasingly "appified" web that proprietary software makes again inroads on otherwise free systems.

> True, though we have reached a point where one could be really comfortable without proprietary software. I certainly am. It's just with an increasingly "appified" web that proprietary software makes again inroads on otherwise free systems.

Agreed. I extremely comfortable with my fully free system, and the only risk I have each day (which I've mitigated) for running non-free software is the constant barrage that others attempt to force upon me using my web browser---free browsers gladly download and execute non-free software by default.

I gave a talk about this and the issues of package management and code signing at LP2016: https://media.libreplanet.org/u/libreplanet/collection/resto...

Re: Introduction to WebAssembly: why should we care?

#78

Post by Shoothe »

TazeTSchnitzel wrote: post #58
Fifer82 wrote: post #19

I am still a bit baffled. I am a TypeScript user and in the article he states: For instance, instead of compiling TypeScript to JavaScript, its developers could now compile to WebAssembly. Alright, so I don't need to be a C/C++ dude to get some WebAssembly goodness (maybe some day). But now with this in my toolbelt. What occurs? What does it mean? If I have a particle simulation in TypeScript on Canvas using Shaders.…

You're baffled because the author has no idea what they're talking about. TypeScript is a superset of JS, it makes no sense to compile it to a platform designed for AoT-compiled systems programming languages.

> ...the author has no idea what they're talking about. TypeScript is a superset of JS, it makes no sense to compile it to ...

I agree with this. Mentioning compilation of TypeScript to WebAssembly shows some misunderstandings of both of these technologies. WebAssembly was designed to run code already written in some low level language like C/C++ because running already written software in a browser is easier than rewriting it. Of course you can compile Rust into WebAssembly but that was not a reason for why WebAssembly (and it's predecessors, asm.js, PNaCL) were conceived.

On the other hand TypeScript makes JavaScript programming easier for when the app becomes too big to maintain without tooling.

Re: Introduction to WebAssembly: why should we care?

#79

Post by kabes »

JSONwebtoken wrote: post #30

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?

JS has been optimized to the extreme for years and years. Compilers that compile to WASM are still new so I'm guessing there's still a lot of room for optimization.

Re: Introduction to WebAssembly: why should we care?

#80

Post by umilegenio »

TazeTSchnitzel wrote: post #58
Fifer82 wrote: post #19

I am still a bit baffled. I am a TypeScript user and in the article he states: For instance, instead of compiling TypeScript to JavaScript, its developers could now compile to WebAssembly. Alright, so I don't need to be a C/C++ dude to get some WebAssembly goodness (maybe some day). But now with this in my toolbelt. What occurs? What does it mean? If I have a particle simulation in TypeScript on Canvas using Shaders.…

You're baffled because the author has no idea what they're talking about. TypeScript is a superset of JS, it makes no sense to compile it to a platform designed for AoT-compiled systems programming languages.

There is no need to be rude.

TypeScript was used as an example of a well-known language that currently is transpiled to JavaScript. I am not saying that TypeScript will surely be compiled to WebAssembly, just that it could.

TypeScript is designed for development of large applications. It is a superset of JavaScript both because this facilitates learning, but also because there was really not an alternative. In the end you had to compile to JavaScript. It is not hard to imagine a language with the same objective of TypeScript that is compiled to WebAssembly. Furthermore, if TypeScript was compiled to WebAssembly you could use it wherever there was a platform for the WebAssembly format. So if somebody created a project to consume WASM binary files and execute them from within .NET assemblies[1], you could use TypeScript outside the browser and node.

[1] https://www.hanselman.com/blog/NETAndWebAssemblyIsThisTheFut...

Post reply on HN