Hacker News new | ask | show | jobs
by GiorgioG 2365 days ago
I can’t wait for WASM to kill off JS for mainstream web front end app dev. It can’t come soon enough.

edit: Look at Blazor and Yew for example, these types of frameworks can and will replace the bulk of what we use JS for today.

3 comments

I'm not sure where this idea has come from, but WASM is designed to run alongside Javascript. It isn't replacing it.
This.

It's funny tough, people are starting to pump giant runtimes over the air just to get C# running on the frontend, while people already complaining about JS bundle size smh.

Indeed, I tried Blazor and a simple Hello World page loaded about 7 megabytes of DLLs in the browser just to show some text.
Blazor (WASM) has not been released yet - they're working on optimizing payload size.
I didn't know this, I was just trying out the project because it seemed interesting. If they can get the bundle sizes down it looks like it could be a great developer experience.
As of the latest preview of Blazor, the boilerplate template (Release build) app loads a total 4.92mb, of which ~4.5mb is the runtime. It's not ideal, but if they can manage to get that to below 3mb it's "good enough" for my purposes. As an Angular developer, at work our app bundles are no smaller than 3mb these days.
Did they plan to get rid of this somehow? What about lazy loading (runtime and/or userspace code)
Have you actually used WASM? WASM is provided through JS APIs and WASM do not have DOM/HTML5 APIs so that they must be imported from JS wrapper functions. Therefore you will never be able to ditch when you are using WASM.

Currently WASM is a way worse in terms of shipping on the web. On top of wrapper JS scripts, .wasm files are treated as statice files like image files. You have extra burden with the path of every .wasm files.

Is it even on the roadmap? WASM does not have access to DOM at all.
I think it is.
No they are not. Standard DOM API is not i their roadmap. There is no point of doing it when WASM has to be loaded by JS anyway.

Currently DOM libraries using WASM are implemented by importing JS wrapper functions.

The interface types proposal will allow to call DOM APIs from WebAssembly directly [https://github.com/WebAssembly/interface-types/blob/master/p...]

The point of doing it is of course performance.

That's what I thought. Thanks.
>Standard DOM API is not in their roadmap.

It is...

"To realize the high-level goals of (1) integrating well with the existing Web platform and (2) supporting languages other than C++, WebAssembly needs to be able to...reference DOM and other Web API objects directly from WebAssembly code...call Web APIs (passing primitives or DOM/GC/Web API objects) directly from WebAssembly without calling through JavaScript..."

https://github.com/WebAssembly/proposals/issues/16