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

81–90 of 259 posts

Re: Introduction to WebAssembly: why should we care?

#81

Post by JustSomeNobody »

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

Exactly. Leave https alone and use it for hypertext. Have another protocol (vmtps?) that is used for apps. Browsers could support both.

Re: Introduction to WebAssembly: why should we care?

#82

Post by pjmlp »

mrec wrote: post #64
pjmlp wrote: post #24

Earlier quoted context omitted.

It remains to be tested on the wild. Lets see when the first examples pop up on Project Zero or CCC.

It reuses the existing Javascript security model, which has been tested pretty extensively in the wild.

Should I list all of the CVEs related to exploits on JavaScript VMs?

Just today there were a few on another HN thread.

Re: Introduction to WebAssembly: why should we care?

#83

Post by loup-vaillant »

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

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.

Re: Introduction to WebAssembly: why should we care?

#84

Post by [deleted] »

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.

[deleted]

Re: Introduction to WebAssembly: why should we care?

#85

Post by 0xfeba »

JustSomeNobody wrote: post #81
loup-vaillant wrote: post #72

Earlier quoted context omitted.

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

Exactly. Leave https alone and use it for hypertext. Have another protocol (vmtps?) that is used for apps. Browsers could support both.

Agreed. It seems we are just piling on one thing after another. Surely we can start fresh with a better eye toward the future.

TLS + HTTP Methods/WebSockets + HTML + CSS + JavaScript + JS frameworks

Plus all the server side stuff. It's all a mess.

Re: Introduction to WebAssembly: why should we care?

#86

Post by sjmulder »

emj wrote: post #25
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: htt…

Agreed, back when I got the tooling up and running it generated a whole bunch of things to emulate stdio and such. I couldn't figure out how to make a freestanding wasm library.

I wish I could just do `wasmcc -ofoo.wasm foo.c` and get a `foo.wasm` that I can include, without any implicit dependencies and such. Let me supply malloc if I call it. I'm sure there'd be libc-lite libraries in no time (if they aren't there already, I'm out of date).

Re: Introduction to WebAssembly: why should we care?

#87

Post by pjmlp »

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.

Yet it is already happening.

https://github.com/AssemblyScript/assemblyscript

https://github.com/01alchemist/TurboScript

Re: Introduction to WebAssembly: why should we care?

#88

Post by pjmlp »

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

Yes, there are already quite a few ongoing ports to WebAssembly, including TypeScript dialects.

https://github.com/mbasso/awesome-wasm

Re: Introduction to WebAssembly: why should we care?

#89

Post by Vinnl »

rekado wrote: post #59
Vinnl wrote: post #49

Earlier quoted context omitted.

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

Admittedly, I'm looking at this situation from within my comfortable bubble of a GNU system in which I only use software for which I have a source-to-binary mapping through GNU Guix. JavaScript applications are the exception in my environment and they threaten to burst that shiny bubble. Aside: I really think that the terms "open" and "closed" are imprecise and confusing, which is why I avoid them. With deterministic…

I guess I mostly agree. I just think that theoretically it should be able for web applications to be open source just as much as our GNU systems are, and that it's a shame that in practice, this is often not the case.

Re: Introduction to WebAssembly: why should we care?

#90

Post by [deleted] »

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

[deleted]
Post reply on HN