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

161–170 of 259 posts

Re: Introduction to WebAssembly: why should we care?

#161

Post by pjmlp »

Skinney wrote: post #149
pjmlp wrote: post #41

Earlier quoted context omitted.

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

WebAssembly doesn't change this. There's nothing preventing people from doing this with javascript (plain or asm.js flavored) and canvas/webGL, and yet no one does. It just doesn't make a lot of sense.

Try to disable JavaScript and see how much of the modern Web you are able to enjoy, even on sites which are supposed to display static text.

Re: Introduction to WebAssembly: why should we care?

#162

Post by zeveb »

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

> This will probably prevent Google from indexing your site, killing your page ranking and driving away potential customers.

Actually, it wouldn't surprise me if Google used some sort of AI to recognise the resulting images of text. What this would do is make it exponentially more difficult to start a search competitor to Google. Which might explain why Google is all-in on WebAssembly …

Re: Introduction to WebAssembly: why should we care?

#163

Post by recursive »

AboutTheWhisles wrote: post #129
joquarky wrote: post #121

Earlier quoted context omitted.

Good luck running an ad blocker when every site is run in wasm and rendered to canvas.

You can still block domains that serve ads. Also rendering the whole page in a canvas implies forgoing the entire DOM, which leaves behind basics like links, forms, embedded videos, etc. It would also mean getting raw input and drawing+laying out everything yourself instead of letting the browser do it.

That's all true.

But the domain serving the ads might be the same one serving the rest of the content. And if that server is motivated enough to show you that ad, they will do all of the things you mentioned. I've been worried for sometime that this will be the end-game of the ad-blocker wars.

Re: Introduction to WebAssembly: why should we care?

#164

Post by munificent »

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

I think the idea that "access to source code == freedom" is out of date. Imagine someone gave you a thumbdrive with the complete source code for all of Facebook's products, build system, infrastructure, everything that's checked into their repositories. They also gave you legal carte blanche to do as you feel with it.

Would you be free of Facebook? Would you be able to do anything useful with at all?

No. The problem is that Facebook still has all of the data and that's where the freedom and control live today. The code is just an interface for it.

Online multiplayer game developers figured this out decades ago. The primary way to prevent people from cheating is not by preventing them from hacking or cracking the client application code. It's keeping the game state — the data — only on the server.

Re: Introduction to WebAssembly: why should we care?

#165

Post by azakai »

jokoon wrote: post #154
azakai wrote: post #125

Earlier quoted context omitted.

What felt clumsy or bloated to you in the toolchain? We'd love to improve it, specific feedback would be very helpful.

I'd prefer a C++ compiler that directly compiles to wasm. Would it be either a G++ or clang++ module, but something a lot more straightforward and simple. No intermediary, no multiple dependencies. Either a simple compiler binary, and if not possible (although I still wonder why developer never release both source code AND binaries), provide a single downloadable repo that I can build using cmake. I have read tutoria…

I'd like to understand you better, I don't think I do yet.

From the user's perspective, isn't emcc a C++ compiler that directly compiles to wasm? There are some internal IRs along the way, but you shouldn't notice them, like you don't notice the GIMPLE IR when using gcc?

The emscripten sdk isn't small, that's true, but that's because LLVM+clang are not small, plus the musl libc and libc++ are not small either. But all those pieces are necessary in order to provide emcc which can compile C++ to wasm. So it can't be just a single repo, multiple components are needed here - in fact, regardless of emscripten, more will be needed soon since the LLVM wasm backend will depend on the lld linker.

What we can maybe do to make this unavoidable complexity seem simpler, is to compile all the necessary things into wasm, and have a single repo containing those builds. So it would contain clang compiled to wasm, lld compiled to wasm, etc. Then the user would check out that one repo and have all the tools immediately usable, on any OS. The wasm builds would be a little slower than native ones, but perhaps the ease of use would justify that - what do you think?

Re: Introduction to WebAssembly: why should we care?

#166

Post by umilegenio »

feelin_googley wrote: post #143

There is no "war against Javascript" as the author suggests. It just happens to be the chosen language of the now insidious ad-driven corporate-sponsored web browser. It is not Javascript per se , but the so-called "modern" browser that creates problems for so many users. The problem is not even that this program exists. The problem is that users are coerced to use it and it is controlled by a third party that needs…

It was more of a lighthearted joke about the attitude that many have toward JavaScript than an attack on the language itself.

I have nothing against JavaScript, although it is not a splendid example of design it certainly works for what was designed for. But I think it also undeniable that would choose something else for many tasks, if they had the option.

If you wanted, you could also use JavaScript for an entire operating systems just for JavaScript[1]. However this does not mean that it is good idea to do so.

[1] https://github.com/NodeOS/NodeOS

Re: Introduction to WebAssembly: why should we care?

#167

Post by AboutTheWhisles »

v_lisivka wrote: post #157
AboutTheWhisles wrote: post #126

Earlier quoted context omitted.

I don't understand this fear of webasm. Anyone can run their javascript through minifiers, or compile C++ to asm.js right now. Webasm doesn't move the needle of obfuscation much at all. The binary format can be turned into the textual ast representation directly. http://ast.run/

Same holds true for machine code: Anyone can run their C trough minifiers or compile to machine code right now. Machine code donesn't move needle of obfuscation much at all. The binary format can be turned into textual asm representation directly. Currently, difference in performance between asm.js and WebAsm is about 5%. It doesn't looks like performance gain or portability are main reasons to select WebAsm over JS.…

> Anyone can run their C trough minifiers

I don't know of any programs that are distributed as C to be run directly like javascript.

> Machine code donesn't move needle of obfuscation much at all

There are two very fundamental mistakes you are making when equating webasm to raw processor instructions. The first is that webasm even its binary format is still organized in a abstract syntax tree, so its instruction are not flat, they are in a hierarchy.

The second is that webasm doesn't take care of the input and output. Right now it doesn't even interface with the document object model, so all the IO is still done through javascript.

Re: Introduction to WebAssembly: why should we care?

#168

Post by tzahola »

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.

>the javascript security model

:Ddd

So you’re saying they have mitigated every cross-origin-based exploit? I bet they really mean it this time.

Re: Introduction to WebAssembly: why should we care?

#169

Post by AboutTheWhisles »

recursive wrote: post #163
AboutTheWhisles wrote: post #129

Earlier quoted context omitted.

You can still block domains that serve ads. Also rendering the whole page in a canvas implies forgoing the entire DOM, which leaves behind basics like links, forms, embedded videos, etc. It would also mean getting raw input and drawing+laying out everything yourself instead of letting the browser do it.

That's all true. But the domain serving the ads might be the same one serving the rest of the content. And if that server is motivated enough to show you that ad, they will do all of the things you mentioned. I've been worried for sometime that this will be the end-game of the ad-blocker wars.

Right, but all that could happen now. Webasm doesn't change anything in that regard.

Re: Introduction to WebAssembly: why should we care?

#170

Post by tzahola »

baldfat wrote: post #53
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.

> I can easily imagine that Adobe R&D already has a working WebAssembly prototype for Flash. Actually Haxe and Openfl will probably beat them to the punch since Adobe has pretty much killed flash by 2020.

Adobe has around 4 guys working on the whole Flash codebase.
Post reply on HN