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

221–230 of 259 posts

Re: Introduction to WebAssembly: why should we care?

#221

Post by umilegenio »

TazeTSchnitzel wrote: post #216
umilegenio wrote: post #80

Earlier quoted context omitted.

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

Let's agree that is feasible, but unlikely.

Re: Introduction to WebAssembly: why should we care?

#222

Post by recursive »

AboutTheWhisles wrote: post #169
recursive wrote: post #163

Earlier quoted context omitted.

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.

I agree. I'm pretty excited about webasm, although I'm nervous about ad-blocking in general.

Re: Introduction to WebAssembly: why should we care?

#223

Post by dllthomas »

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…

It's not sufficient. It may or may not be necessary. But it is useful.

Re: Introduction to WebAssembly: why should we care?

#224

Post by zurn »

joquarky wrote: post #121
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!

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

Then ad blocking would move to image recognition and/or automatic binary reverse engineering.

Re: Introduction to WebAssembly: why should we care?

#225

Post by Skinney »

pjmlp wrote: post #161
Skinney wrote: post #149

Earlier quoted context omitted.

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.

So? My point is that most who relies on client-side code to render apps, does so in a way that integrates nicely with the browser. Most JS apps render html, they don't draw to a canvas. They could do that, but it would break a lot of functionality that people expect for a program that runs in a browser. This won't change with webasm. It will just make such pages load (and maybe perform) faster.

Re: Introduction to WebAssembly: why should we care?

#226

Post by samnardoni »

pjmlp wrote: post #161
Skinney wrote: post #149

Earlier quoted context omitted.

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.

The point is that wasm doesn't change this; wasm won't make it 'worse'.

Re: Introduction to WebAssembly: why should we care?

#227

Post by samnardoni »

pjmlp wrote: post #11
Longhanks wrote: post #7

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 can do all that with JS too. Wasm adds nothing extra. It's perfectly sensible to imagine wasm applications targeting the DOM (which it can do via JS, and will do natively in later releases) just like JS applications do now.

Re: Introduction to WebAssembly: why should we care?

#228

Post by tardygrad »

I doubt this will take off, because developers seem to prefer Javascript as a language.

On the server where there is a choice of several languages both interpreted and compiled, Nodejs is still very popular. If there were a war against Javascript people would be moving away from Node.

My guess is that this is going to be another niche, underutilised technology (like WebRTC or even SVG) that is efficient leads to highly optimised products, and but lacks mainstream usage.

Re: Introduction to WebAssembly: why should we care?

#229

Post by baq »

Animats wrote: post #205
jcelerier wrote: post #200

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.

Yeah but it doesn't have qt built in.

Re: Introduction to WebAssembly: why should we care?

#230

Post by Majora320 »

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…

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

At least, good online multiplayer game developers.

Post reply on HN