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

91–100 of 259 posts

Re: Introduction to WebAssembly: why should we care?

#91

Post by austincheney »

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

Use a code beautifier. JavaScript code isn't encrypted or compiled to binary. It is just text.

Re: Introduction to WebAssembly: why should we care?

#92

Post by Jasper_ »

pjmlp wrote: post #87
TazeTSchnitzel wrote: post #58

Earlier quoted context omitted.

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

https://github.com/AssemblyScript/assemblyscript/blob/master...

This doesn't look like traditional TypeScript to me. The explicit loads/stores give away the whole trick.

https://github.com/AssemblyScript/assemblyscript/blob/master...

And it requires JS twice the size of the TypeScript to actually use the output generated by AssemblyScript. I personally don't see WASM a valid target for AssemblyScript for another year or two, until either the gc or host-bindings proposals lands.

Re: Introduction to WebAssembly: why should we care?

#93

Post by TheRealPomax »

hood_syntax wrote: post #47
_red wrote: post #45

Earlier quoted context omitted.

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.

New technology starts with the above-well-off, using tech you currency consider "absurdly unattaible to the masses" (like cars in the 20s, or telephone in the 40s, or computers in the 60s, or 24/7 internet in the 90s): for instance, when you just get a basically free gigabit connection straight into the backbone (like in a new upscale Japanese apartment building) the very idea that latency could even be a problem just... disappears.

In that context, just attaching an interactive window to a remote running process (as long as it can stream faster than whatever is your minimum acceptable framerate at your minimum acceptable resolution) is literally indistinguishable from running locally. So I frankly do hope that comes to pass (as long as I also get to keep being able to build a desktop computer for working offline).

Re: Introduction to WebAssembly: why should we care?

#94

Post by osrec »

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

But that's also the beauty of it. Within the browser we can support the old and the new without too much trouble.

Re: Introduction to WebAssembly: why should we care?

#95

Post by olavk »

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

We already tried that - Java Applets. Silverligt was the same idea. And Flash I guess? All attempts failed in the marketplace. It turns out using higher level standards like HTML, CSS, URL's etc actually provide a a lot of value.

Re: Introduction to WebAssembly: why should we care?

#96

Post by opportune »

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

That's basically what Chromebooks already are. I think it's the future too. The only problem is that it moves away from the "upgrade your device every X years" paradigm that makes consumer electronics manufacturers money. They'll have to switch to a subscription model and people may not like that (and personally I'm terrified of the alternative situation where a company would rather I give them my personal information than pay them $1000 every 4 years)

One way to approach the latency problem is with more aggressive colocation. For example, an apartment complex could have its own AWS or Google servers for local computation or video streaming.

Re: Introduction to WebAssembly: why should we care?

#97

Post by moron4hire »

pdkl95 wrote: post #68
moron4hire wrote: post #61

Earlier quoted context omitted.

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.

Re: Introduction to WebAssembly: why should we care?

#98

Post by rekado »

austincheney wrote: post #91
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'…

Use a code beautifier. JavaScript code isn't encrypted or compiled to binary. It is just text.

> It is just text

This misses the point. Looking at a binary through a hex editor is also just text --- and the binary is also "just code", albeit at a level at which only few people are comfortable to work.

Obfuscated code (and generated code in general) is clearly not the preferred form, so it hardly even counts as source code.

But let's pretend your point were valid: would it remain valid with WebASM?

Re: Introduction to WebAssembly: why should we care?

#99

Post by yorwba »

Normal_gaussian wrote: post #74
tzahola wrote: post #55

Earlier quoted context omitted.

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

The more important reason this isn't being done more often is that advertisers want to push their own code and make connections to their own servers in order to protect themselves against ad fraud, and because they want their own tracking data.

Re: Introduction to WebAssembly: why should we care?

#100

Post by opportune »

kabes wrote: post #69
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…

Why is WebAssembly special in this regard? Javascript is also a turing complete language that can just do a bunch of canvas / WebGL draw calls.

Yep. Also this could be approached as an adversarial machine learning problem, analogous to a spam filter. Modern spam filters re pretty good, so if push comes to shove, I'm pretty confident adblockers will adapt to more creative ways to circumvent adblocking

If it leads to an arms race of adblockers vs. websites wanting to serve ads, the longer the race goes on, the longer web-page loading times become. So eventually a website will lose because its loading times will get too long and users, even non-adblocking ones, will go elsewhere

Post reply on HN