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

211–220 of 259 posts

Re: Introduction to WebAssembly: why should we care?

#211

Post by v_lisivka »

hood_syntax wrote: post #186
v_lisivka wrote: post #157

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

Is executable size not a good reason? Also, I don't know how you think there's a noticeable difference of readability between minified asm.js and textual wasm for the average person. It might be more difficult for a programmer to read the wasm, but I can't imagine that "disassembled" asm.js is particularly readable in the first place (and both are completely incomprehensible to a non expert)

No, because size is about same after compression.

Average person see no difference at all. Moreover, I tested tank demo right now, and asm.js version is about 6% faster at loading (1.99s vs 2.12s from cache at Firefox 57.0/Fedora 26).

Re: Introduction to WebAssembly: why should we care?

#212

Post by CaptSpify »

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.

Really? Yeah, it's been tested extensively, but it's security has also been found to be quite lacking. I'm legitimately surprised someone can say this with a straight face.

Re: Introduction to WebAssembly: why should we care?

#213

Post by CaptSpify »

dbbk wrote: post #111
Endy wrote: post #3

We shouldn't. All the nonsense we're trying to cram into the Web is making it harder to justify connecting to it. I long for the days when simple images and text were the norm. Nowadays, I need to have and devote constant system resources to a tracking-blocker, cookie-blocker, an ad-blocker, a script-blocker, a separate javascript-blocker, and a who-knows-what-else-blocker, just to do the things I want to do; let alo…

Okay, say every browser had a built-in tracking, cookie, ad, script blocker etc. How would you propose websites then make any money?

They could ask their users. That model seems to be working well. But even if they couldn't make money? Who cares?

The web existed long before it was monetized, and it worked great! Better than now, actually.

Re: Introduction to WebAssembly: why should we care?

#214

Post by jjrh »

Endy wrote: post #3

We shouldn't. All the nonsense we're trying to cram into the Web is making it harder to justify connecting to it. I long for the days when simple images and text were the norm. Nowadays, I need to have and devote constant system resources to a tracking-blocker, cookie-blocker, an ad-blocker, a script-blocker, a separate javascript-blocker, and a who-knows-what-else-blocker, just to do the things I want to do; let alo…

If the revenue generating nonsense (ads, tracking, etc) weren't on the web they would creep in where every they could. At least on the web we can fairly easily block the majority of ads.

I liked simple text pages of the past but I also appreciate that lots and lots of applications that would only ever see a windows release (and maybe a buggy mac release) will run on whatever platform I want as long as I have a modern browser.

I hear ya though that it's frustrating when you go to a site that is pretty much only text and it just flatout doesn't work without javascript, or they have done something weird with the css and it doesn't reflow properly on a small screen/mobile browser.

Re: Introduction to WebAssembly: why should we care?

#215

Post by CaptSpify »

dingo_bat wrote: post #65
GrumpyNl wrote: post #10

From the site: The kind of binary format being considered for WebAssembly can be natively decoded much faster than JavaScript can be parsed (experiments show more than 20× faster). On mobile, large compiled codes can easily take 20–40 seconds just to parse, so native decoding (especially when combined with other techniques like streaming for better-than-gzip compression) is critical to providing a good cold-load user…

Gmail takes around 5 seconds to load over a 100mbit connection. Seems to not have posed any problem for them.

Just because it works and makes money doesn't mean it isn't poorly designed. It may be that some people care about their users, more than their company's profit.

Weird, I know.

Re: Introduction to WebAssembly: why should we care?

#216

Post by TazeTSchnitzel »

umilegenio wrote: post #80
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.

There is no need to be rude. TypeScript was used as an example of a well-known language that currently is transpiled to JavaScript. I am not saying that TypeScript will surely be compiled to WebAssembly, just that it could. TypeScript is designed for development of large applications. It is a superset of JavaScript both because this facilitates learning, but also because there was really not an alternative. In the en…

> There is no need to be rude.

I apologise. I'm just… rather surprised at such an idea.

> It is not hard to imagine a language with the same objective of TypeScript that is compiled to WebAssembly.

It is not hard to an imagine a strongly-typed language targeting WebAssembly, sure. But TypeScript is not that kind of language. TypeScript is just JavaScript, and JavaScript, as a highly dynamic language, is a very poor candidate for the kind of ahead-of-time compilation to a low-level target that WebAssembly was made for. I mean… it could, technically, be done, but why would anyone do so? The result would be bigger and slower than normal JS.

Re: Introduction to WebAssembly: why should we care?

#217

Post by TazeTSchnitzel »

Fifer82 wrote: post #70
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.

Since TypeScript is a transpiler, couldn't it output a new "MyLittlePony Lang" for example and then WebAssembly from that?

It could output whatever it likes, you can compile anything to anything.

Re: Introduction to WebAssembly: why should we care?

#218

Post by loup-vaillant »

collyw wrote: post #195
loup-vaillant wrote: post #124

Earlier quoted context omitted.

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

It's not fully compatible. Of course it didn't take off. You want the default application to be free software.

Re: Introduction to WebAssembly: why should we care?

#219

Post by Roboprog »

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…

Not everybody wants “Scheme in the browser”. In the spirit of “Worse is Better”, plenty of people want to run C++ in the browser. I’m not one of them, but hey, whatever floats your boat.

That said, I’d like a few useful libraries (e.g. - fixed precision decimal arithmetic) written in web assembler. But otherwise, I actually prefer writing in JavaScript (as FP more than OOP) over C++/Java/C# (degenerate Simula 67 clones) for most application level tasks.

Writing in C++ won’t make DOM access or async I/O go away, though :-)

Re: Introduction to WebAssembly: why should we care?

#220

Post by Roboprog »

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 really don’t understand the industry fixation with C++. It has to be one of the WORST (as in “error prone death trap”) computer languages ever devised. God how I wish it would fade away into obscurity.

If half the effort wasted on C++ compilers and usage learning had been spent on something worthwhile...

Post reply on HN