Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Making WebAssembly a first-class language on the Web

hacks.mozilla.org

Post reply on HN
Print view View original

41–50 of 287 posts

Re: Making WebAssembly a first-class language on the Web

#41

Post by bvisness »

haberman wrote: post #40

> Thankfully, there is the esm-integration proposal, which is already implemented in bundlers today and which we are actively implementing in Firefox. From the code sample, it looks like this proposal also lets you load WASM code synchronously. If so, that would address one issue I've run into when trying to replace JS code with WASM: the ability to load and run code synchronously, during page load. Currently WASM co…

This is not strictly true; there are synchronous APIs for compiling Wasm (`new WebAssembly.Module()` and `new WebAssembly.Instance()`) and you can directly embed the bytecode in your source file using a typed array or base64-encoded string. Of course, this is not as pleasant as simply importing a module :)

Re: Making WebAssembly a first-class language on the Web

#42

Post by pizlonator »

eqrion wrote: post #32
pizlonator wrote: post #12

Earlier quoted context omitted.

> WebAssembly has a sandbox and was designed for untrusted code. So does JavaScript. > It's almost impossible to statically reason about JS code, and so browsers need a ton of error prone dynamic security infrastructure to protect themselves from guest JS code. They have that infrastructure because JS has access to the browser's API. If you tried to redesign all of the web APIs in a way that exposes them to WebAssemb…

> If you compile them to GC wasm instead of running directly in JS then you're just adding unnecessary overheads for no upside Language portability is a big feature. There's a lot of code that's not JS out there. And JS isn't a great compilation target for a lot of languages. Google switched to compiling Java to Wasm-GC instead of JS and got a lot of memory/speed improvements. > Because for example if a browser chang…

> Language portability is a big feature.

It's a big feature of JS. JS's dynamism makes it super easy to target for basically any language.

> Google switched to compiling Java to Wasm-GC instead of JS and got a lot of memory/speed improvements.

That's cool. But that's one giant player getting success out of a project that likely required massive investment and codesign with their browser team.

Think about how sad it is that these are the kinds of successes you have to cite for a technology that has had as much investment as wasm!

> Almost 6% of page loads use wasm

You can disable wasm and successfully load more than 94% of websites.

A lot of that 6% is malicious ads running bitcoin mining.

> Wasm is way too complicated to use today.

I'm articulating why it's complicated. I think that for those same reasons, it will continue to be complicated

Re: Making WebAssembly a first-class language on the Web

#43

Post by pizlonator »

swiftcoder wrote: post #39
pizlonator wrote: post #34

Earlier quoted context omitted.

> I mean, you are obviously entitely to your opinion I'm trying to explain to you why attempts to make wasm mainstream have failed so far, and are likely to continue to fail. I'm not expressing an "opinion"; I'm give you the inside baseball as a browser engineer. > Getting rid of the glue layer I'm trying to elucidate why that glue layer is inherent, and why JS is the language that has ended up dominating web develop…

> why JS is the language that has ended up dominating web development JS was dominating web development long before WASM gained steam. This isn't the same situation as "JS beating Java/ActivX for control of the web" (if I follow the thrust of your argument correctly). WASM has had less than a decade of widespread browser support, terrible no-good DevEx for basically the whole time, and it's still steadily making it's…

WebAssembly has had extraordinary levels of investment from browser devs and the broader community.

> terrible no-good DevEx for basically the whole time

I'm telling you why.

> still steadily making it's way into more and more of the web.

It is, but you can still browser the web without it just fine, despite so much investment and (judging by how HN reacts to it) overwhelming enthusiasm from devs

Re: Making WebAssembly a first-class language on the Web

#44

Post by davexunit »

mananaysiempre wrote: post #9

This (appears as though it) all could have happened half a decade ago had the interface-types people not abandoned[1,2] their initial problem statement of WebIDL support in WebAssembly in favour of building Yet Another IDL while declaring[3] the lack of DOM access a non-issue. (I understand the market realities that led to this, I think. This wasn’t a whim or pure NIH. Yet I still cannot help but lament the lost time…

I really want stringref to make a comeback.

Re: Making WebAssembly a first-class language on the Web

#45

Post by saghm »

csmantle wrote: post #28

Another important aspect is that, without an external library like `wabt`, I can't just open Notepad, write some inline WASM/WAT in HTML and preview it in a browser, in the same way that HTML+CSS+JS works. Having to obtain a full working toolchain is not very friendly for quick prototyping and demonstrative needs.

The same limitation exists with "non-web" assembly. It turns out that having languages that compile to assembly makes a lot of sense for almost every real-world use case than writing it by hand.

Re: Making WebAssembly a first-class language on the Web

#47

Post by davexunit »

eqrion wrote: post #17
steve_adams_86 wrote: post #11

The WASM cliff is very real. Every time I go to use it, because of the complexity of the tool chain and process of going from zero to anything at all, I feel like I'm already paying a cognitive tax. I worry that I should update my tooling, look into the latest and greatest, understand the tooling better, etc... It would be incredible to see that improved. The difference in perf without glue is crazy. But not surprisi…

I agree that a lot of the tooling is still early days. There has also been a lot of churn as the wasm component spec has changed. We personally have a goal that in most cases web developers won't need to write WIT and can just use Web API's as if they were a library. But it's early days.

I am excited by the prospect of booting Wasm binaries without any JS glue, but when I've looked at the documentation for the component model and WIT it says that resources are references passed using a borrow checking model. That would be a serious downgrade compared to the GC-managed reference passing I can do today with Wasm GC. Do you know if there are any plans to resolve this mismatch?

Re: Making WebAssembly a first-class language on the Web

#48

Post by saghm »

pizlonator wrote: post #5

It's simple. JavaScript is the right abstraction for running untrusted apps in a browser. WebAssembly is the wrong abstraction for running untrusted apps in a browser. Browser engines evolve independently of one another, and the same web app must be able to run in many versions of the same browser and also in different browsers. Dynamic typing is ideal for this. JavaScript has dynamic typing. Browser engines deal in…

I'm not convinced JavaScript is a great abstraction for the browser as much as we've forced the web into a shape that fits JavaScript because of a lack of viable alternatives. I'd argue that the popularity of TypeScript implies that dynamic typing is not a universal ideal. Browser engines deal in objects because they're currently all built on top of JavaScript only; that doesn't demonstrate anything fundamental about the web that implies object oriented is the only reasonable representation.

If it gets stuck as a second-class citizen like you're predicting, it sounds a lot more like it's due to inflexibility to consider alternatives than anything objectively better about JavaScript.

Re: Making WebAssembly a first-class language on the Web

#49

Post by mananaysiempre »

eqrion wrote: post #15
mananaysiempre wrote: post #9

This (appears as though it) all could have happened half a decade ago had the interface-types people not abandoned[1,2] their initial problem statement of WebIDL support in WebAssembly in favour of building Yet Another IDL while declaring[3] the lack of DOM access a non-issue. (I understand the market realities that led to this, I think. This wasn’t a whim or pure NIH. Yet I still cannot help but lament the lost time…

I worked on the original interface-types proposal a little bit before it became the component model. Two goals that were added were: 1. Support non-Web API's 2. Support limited cross language interop WebIDL is the union of JS and Web API's, and while expressive, has many concepts that conflict with those goals. Component interfaces take more of an intersection approach that isn't as expressive, but is much more porta…

> Two goals that were added were: 1. Support non-Web API's. 2. Support limited cross language interop.

I mean, surely it does not come to a surprise to anyone that either of these is a huge deal, let alone both. It seems clear that non-Web runtimes have had a huge influence on the development priorities of WebAssembly—not inherently a bad thing but in this case it came at the expense of the actual Web.

> WebIDL is the union of JS and Web API's, and while expressive, has many concepts that conflict with those goals.

Yes, another part of the problem, unrelated to the WIT story, seems to have been the abandonment of the idea that could be something other than JavaScript and that the APIs should try to accomodate that, which had endured for a good while based on pure idealism. That sure would have come useful here when other languages became relevant again.

(Now with the amputation of XSLT as the final straw, it is truly difficult to feel any sort of idealism from the browser side, even if in reality some of the developers likely retain it. Thank you for caring and persisting in this instance.)

Post reply on HN