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

191–200 of 259 posts

Re: Introduction to WebAssembly: why should we care?

#191

Post by constexpr »

azakai wrote: post #165
jokoon wrote: post #154

Earlier quoted context omitted.

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

Incremental linking is something that most C++ toolchains support. Lacking it is currently our biggest pain point with emscripten. I'm very happy to be wrong, but my understanding is that it's hard to add that to emscripten because it's constructed using several different tools that have been chained together. I suspect a lighter-weight WASM-specific compiler backend would make standard C++ compiler features such as incremental linking significantly easier to do. Is that true?

Re: Introduction to WebAssembly: why should we care?

#192

Post by mrec »

tzahola wrote: post #168
mrec wrote: post #64

Earlier quoted context omitted.

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.

Nobody's claiming it's flawless. I'm just objecting to the claim that it's untested.

Re: Introduction to WebAssembly: why should we care?

#193

Post by mikegerwitz »

munificent wrote: post #164
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…

Yes that's a different problem different than software freedom:

https://www.gnu.org/philosophy/who-does-that-server-really-s...

Re: Introduction to WebAssembly: why should we care?

#194

Post by conradev »

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

I think the main reason is

https://caniuse.com/#feat=asmjs vs https://caniuse.com/#feat=wasm

Re: Introduction to WebAssembly: why should we care?

#195

Post by collyw »

loup-vaillant wrote: post #124
niftich wrote: post #116

Earlier quoted context omitted.

Obligatory point that Flash didn't fail in the marketplace. Rather, it was wildly popular, so much so that Microsoft eventually felt the need to develop a comparable tech -- Silverlight. Flash on the web faltered rapidly after many years of efforts by Mozilla, Apple, Opera, and associated individuals. They were looking to move the web 'forward' had a high-profile disagreement with W3C, so they started their own stand…

Seconded. If Flash wasn't proprietary, it would still thrive. It could have displaced JavaScript itself.

There is an open source version Gnash. I installed it on a laptop a few years back and it ran fairly well, but a bit slow compared to the real Flash. Why do you think that didn't take off?

Edit: Looking at the wikipedia page I see one reason (though I am not convinced its the reason it didn't take off). https://en.wikipedia.org/wiki/Gnash_(software)#Adobe_Flash_P...

Re: Introduction to WebAssembly: why should we care?

#196

Post by Animats »

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 all about reducing user power and giving total control to the big sites.

[1] http://webassembly.org/demo/Tanks/ [2] https://s3.amazonaws.com/mozilla-games/ZenGarden/EpicZenGard...

Re: Introduction to WebAssembly: why should we care?

#197

Post by greiskul »

baybal2 wrote: post #106
hood_syntax wrote: post #47

Earlier quoted context omitted.

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.

Now I expect that there will come usability experts from google/facebook/amazon and tell you that an average user does not event know what latency is. Native apps have won over web app ecosystem, plainly and simple. WASM will not change things even a bit to root causes of people deciding to use native apps over web apps.

Google and amazon certainly think the average user cares about latency, even if they don't know what it is: https://blog.gigaspaces.com/amazon-found-every-100ms-of-late...

Re: Introduction to WebAssembly: why should we care?

#198

Post by azakai »

constexpr wrote: post #191
azakai wrote: post #165

Earlier quoted context omitted.

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

Incremental linking is something that most C++ toolchains support. Lacking it is currently our biggest pain point with emscripten. I'm very happy to be wrong, but my understanding is that it's hard to add that to emscripten because it's constructed using several different tools that have been chained together. I suspect a lighter-weight WASM-specific compiler backend would make standard C++ compiler features such as…

Actually emscripten should be getting incremental linking soon. It depends on upstream components, the LLVM wasm backend and lld. Those are almost ready now.

In other words, the emscripten integration for those components is the easy work, the upstream LLVM/lld stuff is the hard part.

Re: Introduction to WebAssembly: why should we care?

#199

Post by justincormack »

alexchamberlain wrote: post #184
TeMPOraL wrote: post #177

Earlier quoted context omitted.

> 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. That would be great, if only we could make it not belong to Amazon or Google . Consider the same idea phrased like this: apartment complex have servers in their basement offering compute, and services you use work on those se…

Let's imagine we could solve the easy problem of writing the software that is fully distributed to each complex and interacts with the software in any other complex. How do we solve the operations problem of running the machines in the complex?

One model is to overprovision hardware a bit, and just not repair until it is significantly degraded (at which point you just swap it out and refurbish). Maintaining a software platform is getting easier.

Re: Introduction to WebAssembly: why should we care?

#200

Post by jcelerier »

Animats wrote: post #196

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.

Post reply on HN