Live data from Hacker News

W3C recommends WebAssembly

w3.org

261–270 of 350 posts

Re: W3C recommends WebAssembly

#261
post #127

Earlier quoted context omitted.

I don't get why binaries should be more bandwidth-intensive than JS. I guess in a sense you already have the JS engine installed with, say, Chrome, which is essentially a runtime. Why can't other runtimes come prepackaged? What am I missing here?

Nobody wants another fat runtime that is as entangled with the browser engine as the JS engine is. Getting the JS engine to be fast was a tremendous trouble and you wouldn't want to sink as much engineering power into another runtime that will have a smaller reach than the JS engine. Rather use that skills to make WASM faster.

> Nobody wants another fat runtime that is as entangled with the browser engine as the JS engine is.

Why would it need to be? There's no reason to assume the architectural decisions for javascript have to be repeated for WASM.

The runtimes themselves could be WASM binaries cached like any other resource, or managed like packages. Javascript could be disentangled from the browser by doing the same - just treating it as a resource that ships by default with the browser.

I don't know if that's feasible - maybe not - but I bet there are possibilities other than "ship the entire runtime with each script" that can be considered.

Re: W3C recommends WebAssembly

#262

For those who are asking themselves what WASM does differently than Java, .NET or other native extensions like ActiveX or NaCl, here's the best rationale doc I found on this topic: https://github.com/WebAssembly/spec/blob/master/papers/pldi2...

Thank you. This is the most exhaust ive article on WebAssembly design goals I have read.

Re: W3C recommends WebAssembly

#263
post #193

Earlier quoted context omitted.

The change in dev culture worries me more than the change in technology. At least Flash sites used to be considered bad taste. Dare to grumble about something unnecessarily requiring gratuitous JS now, and you'll get berated as an out-of-touch Luddite who needs to shut up and get with the times.

By definition, everyone agrees that "gratuitous" use of JS is bad. You're glossing over the nuance of the debate which comes down to the specifics of when something is actually gratuitous.

You mean when the amount of JS you have to download eclipses the size of the original DOOM executable?

Re: W3C recommends WebAssembly

#264

Earlier quoted context omitted.

>In the browser, text is your pixel. Of course you are welcome to build things on top of that with CSS, images, and Canvas. More to the point, I'm not saying that 95% of the time you should abandon your design and make a minimalist terminal interface -- I'm saying that for 95% of the phone apps and native apps I see, HTML would be fine. There is a pretty good chance the design someone has come up with is already repr…

> into something like this Unless I'm misunderstanding, this example seems to be exactly what I'm talking about. Even in its current state, there are only 2 or 3 things on this page I can see using Canvas. Everything else is already using HTML and CSS. It's not even lazy-loading the images -- this is a static page that is dynamically generated. And yet despite ultimately being a static page, it works fine . Great eve…

That page actually goes against your point of HTML as a singular render target. You need CSS or that entire page won't look right at all.

The point isn't whether or not you can do this in CSS + HTML. (Which by the way CSS + HTML is proven to be turing complete so you can actually do anything in CSS + HTML including writing a JS interpreter so you can use javascript on non-JS enabled pages)

The point is to get to the above, you need to basically hack your way there. HTML + CSS is not the ideal medium to program something like that in. It would be better to have a library written over a pixel level API to construct the interfaces you see in the page rather then either hack your way through HTML and CSS or create a library of hacks on top of HTML and CSS.

>I'll make a bolder claim then: 95% of native apps are just interactive documents (with a few category exceptions like games), and most native developers who claim that their interfaces couldn't be represented on the web in HTML are kidding themselves. In the majority of cases, HTML/CSS would be fine for what they're building.

Sure make that claim, even if it were true nobody wants a computer to just be a platform for text based UI. Nobody wants the internet to be JUST that. People want the computer to be a universal computing platform. Games may be category but it's a huge category as no one will buy a computer that only has the capability of displaying text, they buy it for the computing potential to do anything.

Heck under your logic, why even have the OS expose the pixel level api? Just have the OS expose a DOM. 95% of apps are that way so an OS that does this is perfectly fine.

If you want to restrict the potential of what the internet is, then yes. If you want to expand it while keeping your design philosophy in place then the platform must expose a pixel level API and HTML and CSS must be moved to a library. It makes no sense for a lower level library to be written as a component of a higher level library, it should be reversed.

Re: W3C recommends WebAssembly

#265

Earlier quoted context omitted.

Even if we don't lose the HTML-centered model, we are probably going to lose control of our browsers. Eventually somebody is going to ship a product that's nothing more than a browser implemented in WASM that runs inside your browser. The "inner browser" won't have content filtering, privacy controls, DOM inspector, or a Javascript debugger (for the Javascript engine running on the "inner browser") that you can inter…

Unfortunately, I must agree with you that there are definitely some very troubling implications to how WebAssembly might be used to build more effective walled gardens on the web. I can easily imagine a "platform" WASM module which acts as a runtime for other WASM modules built by "app" developers. This Platform module can be easily cached by FAANG or other big commercial interests, similar to AMP by Google (maybe ev…

Delete this!!!

Thanks for dooming us all, hombre. I'm holding you personally responsible when it happens.

In fact I think it may already have. Took a look at a web based learning portal for my niece the other day, and after poking around in devtoolsfound it was pretty similar to what you described.

Re: W3C recommends WebAssembly

#266

Earlier quoted context omitted.

It makes no sense to me. You are saying, that instead a 5 kB webpage, you would load 50 MB code, which emulates a browser, just to show you the same webpage? Every webpage pays for the traffic in some way, and everybody tries to save web traffic as much as possible (optimizing images, videos, minifying JS, CSS ...). It makes no sense to expect, that websites would turn the opposite way just for fun. I would be very g…

Yes. I am saying that some website operators would like to load an entire browser into your client just so they can control the presentation (make sure you're not able to block their ads, control their scripts, etc). I'm not talking about the sandboxed browser being able to "clear your hard drive", etc. I'm talking about users having no real agency when it comes to controlling the presentation of websites. (Sure, it'…

It would make content control more complicated, but it can't make it impossible.

If the embedded browser uses the host's HTTP implementation, then you can filter and edit content there.

If it implements HTTP itself on top of raw sockets, then you can intercept traffic on socket level (although you'd need to MITM any SSL connection).

Re: W3C recommends WebAssembly

#267
post #130

Earlier quoted context omitted.

Meanwhile here I am running around with js off by default. Most of the internet still works. More sites work better with js off than work worse. I hope webassembly doesn't change that into a world where the "js off" analogy is "running my OS without the ability to execute programs."

> Meanwhile here I am running around with js off by default. Most of the internet still works. Just wait 5 more years that 80% of the web switch to React / Vue / TheNewHypeSPAFramework and with or without WASM, you will be unable to browse "js off". The blame here is not on WASM but on the abuse of client side rendering and "everything as an App" when most page are just barely interactive documents. The Web succeeded…

But now companies are paying more to push their WASM good message. Many of them actually believe it now, because they can't comprehend anything different.

Re: W3C recommends WebAssembly

#268
post #242

Earlier quoted context omitted.

One of the reasons of the downfall of Flash were those tiny Flash sites in the middle of a full screen page when we suddenly moved from small screens to 1366x768 or better. Many sites didn't have the resources to upgrade and started looking like something 100 years old.

I always thought the primary driver of the demise of Flash was that Apple simply decided not to support it in iOS Safari. Is that not right?

Apple did decide to not support it, but they didn't decide not to support a thriving product - it's like 3 1/4 floppy disks, when the iMac decided not to include a 3 1/4 drive people grumbled but it was mostly dead tech, writable CDs had become wide spread enough to obsolete it - with flash, when Apple decided to drop support, they did so in an era where preferred alternatives already existed and the tech was thoroughly reviled - so Apple put the final nail in the coffin, but flash was already in the ground at that point.

Re: W3C recommends WebAssembly

#269

Earlier quoted context omitted.

> Could we ever lose the HTML centered model? This is what people should be worried about, not replacing JS. It became a kind of popular hot-take for a while to say that separation of concerns was a mistake, and that's not how apps get built in the real world, and what we really need is a way to encapsulate all of our DOM and CSS in JS. We need to start pushing back against that idea and keep emphasizing that separat…

It’s a bad render target, and it’s only half the story. It’s html + css that’s the render target. Separation of concerns happens because the render target is a over complicated mess. So separate the good parts out of the mess as much as possible but the mess is still there.

I wonder if perhaps we need to revive FOP...

Re: W3C recommends WebAssembly

#270
post #160

Earlier quoted context omitted.

Yes this is what I am talking about. Once you know the instruction, I fail to see how it is more difficult to understand than javascript.

That's like saying x86_64 assembly is as easy to understand as C. High level languages exist to make code easier to understand.

wasm is higher-level than x86 (or any other native) assembly.
Post reply on HN