Live data from Hacker News

Introduction to WebAssembly: why should we care?

tomassetti.me

201–210 of 259 posts

Re: Introduction to WebAssembly: why should we care?

#201
post #159

Earlier quoted context omitted.

I guess you missed all those sites using Flash, Silverlight, Applets, WebStart, ClickOnce and many other plugins. WebAssembly on the long run will enable to bypass JavaScript and target the browser as if it is yet another OS.

> I guess you missed all those sites using Flash, Silverlight, Applets, WebStart, ClickOnce and many other plugins. I did actually, because most aren't around any more. Even so, I was talking about sites that purely use the html canvas to draw. There is nothing preventing websites from being built like that right now, so I don't see how webasm will make much of a difference.

You're missing it...

Web Assembly would allow devs to build apps without any html or javascript or css.

The UI construct could be WPF/XAML or even WinForms like tech or something new.

Scripting and CSS would be entirely unnecessary. A lot of businesses would love nothing better than to dump the Jedi-like skills of the scripting developers and trade that for mundane forms skills.

Re: Introduction to WebAssembly: why should we care?

#202
post #16
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.

>other than a format that makes all browser vendors happy

No small feat!

Re: Introduction to WebAssembly: why should we care?

#203

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

I still don’t understand the primary use case or benefit over JS. Looks a lot like a solution in search of a problem. Maybe it can be used for DRM?

Re: Introduction to WebAssembly: why should we care?

#204
post #175

Earlier quoted context omitted.

That’s not my problem to fix, no proposal is required of me.

Okay, then don't expect anybody to build one. Web browsers are incredibly complex, and nobody is going to build one for free nowadays.

>Web browsers are incredibly complex

This is the problem. A much less complex browser, without wasm, without JavaScript, with a simpler DOM... would not be that incredibly complex and expensive to build. So the point is moot.

Re: Introduction to WebAssembly: why should we care?

#205

Now, more obfuscated than ever! Better DRM! A few more layers of bloat! Buffer overflows are back! Search for WebAssembly demos. There's a crappy tank game.[1] WebGL is doing all the real work; the game part is simple. There's ZenGarden.[2] 200MB download. Again, WebGL is doing all the real work. WebAssembly is going to be a way for sites to bypass ad blockers. That's the real use case. Maybe the only use case. It's…

It's not always WebGL-y stuff. For instance Qt is working on a WASM compilation target: > https://msorvig.github.io/qt-webassembly-examples/widgets_wi... cf. https://bugreports.qt.io/browse/QTBUG-63917 The WASM binaries are around 10 megabytes for this. That's a lot, for sure, but this includes a whole windowing system, a raster paint engine, and a C++ reflection mechanism.

this includes a whole windowing system, a raster paint engine, and a C++ reflection mechanism

All of which the browser already has.

Re: Introduction to WebAssembly: why should we care?

#206

Earlier quoted context omitted.

It's not always WebGL-y stuff. For instance Qt is working on a WASM compilation target: > https://msorvig.github.io/qt-webassembly-examples/widgets_wi... cf. https://bugreports.qt.io/browse/QTBUG-63917 The WASM binaries are around 10 megabytes for this. That's a lot, for sure, but this includes a whole windowing system, a raster paint engine, and a C++ reflection mechanism.

this includes a whole windowing system, a raster paint engine, and a C++ reflection mechanism All of which the browser already has.

sure, but if you want to get your existing 500kloc Qt app to show quickly on screen to make a demo for instance, you aren't going to rewrite it in HTML/CSS/JS for the fun.

Re: Introduction to WebAssembly: why should we care?

#207

Earlier quoted context omitted.

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

I think the main reason is https://caniuse.com/#feat=asmjs vs https://caniuse.com/#feat=wasm

Asm.js is just JS. "No support" means just "No ahead of time compilation for JS in engine."

If you are trying to point that wasm is supported better on iOS, then look at performance tests: https://arewefastyet.com/#machine=29&view=breakdown&suite=as... . At many tests, Safari is faster than other browsers at asm.js microbenchmarks.

Re: Introduction to WebAssembly: why should we care?

#208
post #11

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.

You don't need WebAssembly to invent your own UI in a canvas. WebGL and all that works from Javascript.

Re: Introduction to WebAssembly: why should we care?

#209
post #37
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'…

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.

Plenty of companies use FOSS libraries,languages and tools outside the web - never to contribute anything back. And there is nothing wrong with that as long as the license is respected.

That said many companies do contribute back and in the case of the web quite a few big libraries and frameworks were released open by private companies.

Re: Introduction to WebAssembly: why should we care?

#210
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'm worried about the intersection with EME and DRM.

No more open web. And the crap will become inextricably intertwined with the content of value.

Right now, it's "for content." There is going to be enormous commercial pressure to make it "for everything".

We should start reconsidering the term "user agent".

Post reply on HN