I've talked with 3 WASM related startups today and every devtool investor seems to be looking for a WASM play. Everyone seems to have strong conviction that the future will be safer/faster/polyglot if we just rewrote all the things to WASM.

I built a WASM app with dotnet a year and a half ago. It was cool to be able to write c# for the whole stack, but debugging was still painful. Curious how that's looking these days.

you used Blazor? how big were the frontend bundles? 😅

Pretty hefty 😅 I might have a link somewhere still to it...

Found it! dad-joke-scrobbler.firebaseapp.com

is this right? 70kb? thats less than React!

A lot less than I remembered, but yes that does seem right!

I think it was about 800kb uncached last time I checked but it depends. It's pretty comparable to a fully loaded Angular app. Not React, because that's just a component library, not a framework.

That doesn't seem right, there should be more than just js files. Try a hard reload, they're probably all cached.

The "JS" filter is enabled on that screenshot

You're missing mono.wasm and all the dotnet libraries.

Have you used AssemblyScript? I'm curious how people feel about it. I haven't done any production work with it.

no i have not. the sense i get from people is its a good proof of concept but nobody's really learning it to compile to wasm. i think javascript land will embrace wasm *last* because it already runs in the browser. the other langs have more incentive.

Good take on js. More curious if typescript to wasm will take off. Given you already have a compiler, and a damn fine one at that, you could get some wicked wins & even leave backwards compatibility modes

I have used it and reallllly dig it. The biggest problem is the same as most targets, if you need a garbage collector it's tough. Theirs is really robust but it's still a hit. Because of that I prefer rust, but it's impossible to debug anything without sourcemaps which asmscr has

Sshhhh please not yet I’m trying to hire somebody who understands the WASM ecosystem and there’s already enough competition

how do you evaluate if someone really understands the WASM ecosystem? i can rattle off a bunch of names but unless you have the experience to call BS it seems so hard to tell whats real

I dug in myself to be able to tell what's real/call BS, at least a little bit. From there, I start with my usual question: "what is this *not* good for?" then probe the specifics of what we're looking to do. Helps that what we're looking to do is narrow.

Is this a side hustle thing?

Nopity nope.

Why do they need to understand wasm. Can't they learn in the job if they ate a good engineer with proven track record?

Lol are* 😆

Hmm, won't that lead to even more consolidation of power and influence in the big 3 browsers? One of which I have in mind is already trying to perform manifest destiny on the web and succeeding. WASM is awesome tech, I wonder though if we're actually ready for it

I might take the other side of the bet: That new Typescript-native runtimes and deployment targets get so good (and can seamlessly call into WASM when really needed) that the answer for 95% of use cases remains “why bother?” Wdyt?

(No comment)

This is all part of google’s diabolical plan to become the final dominant platform and slowly choke out windows and macOS

Yes! The server-side Wasm ecosystem should include startups & big companies. Both have strengths. Right now, a lot of Wasm talent is at big co's like Google, Shopify & Fastly. Some of these engineers will need to leave to build out the startup ecosystem more. That's the hope. 🙂

Amplify probably crawling the linkedins of every WASM dev at BigCo right now waiting for them to emerge 🦋

Coincidentally the rest of my Twitter network seems to be 🚮 docker this evening.

Everything sort of hinges on web IDL bindings. Right now wasm is only faster some of the time, and it’s definitely not faster for low-CPU tasks like DOM manipulation. But this is because it’s not a fair fight—web IDL bindings would make wasm’s dominance almost inevitable.

Server side and wasi don’t really have to wait for web IDL, I suppose, but the need for JS on the frontend makes people more inclined to use it elsewhere.

yes they are all betting on server side, almost nobody cares about frontend WASM

I care! :)

I think if you look at enterprise users you'll see a lot(!) of WASM via Blazor, obviously that doesn't require anyone to actually understand WASM at all and the tools are already taken care of. I agree server side WASM will be more interesting (fast + portable).

Not also that enterprise users do not tweet, so the visibility of that is low.

why is that? frontend WASM seems like the actually interesting play. eventually web will get more interactive experiences.

if this was the case how is wasm better than jvm, clr, or beam

I'm not familiar with CLR or beam, but wasm is available in the browser right now and is lower level than the jvm

Also supported as a llvm backend

then a follow up question would be how come there was no llvm backend for those runtimes that have existed since forever

Not wrong...

It’s not because you (re)write it in WASM that it will be faster. This is a misconception. WASM is an extension of JS, not a replacement. @elmd_ and I gave a workshop on WebWorkers + WebAssembly and that was also our takeaway for the attendees.

In my experience the main significant performance gains of wasm vs js so far are in integer math and recursive algorithms

partially agree

Maybe in the far future, but I've tried WASM (in production) more than once, sometimes compiled from C, sometimes from Rust, and it's an absolute nightmare to interop correctly, on all browsers and runtimes. Just importing it is very cumbersome. I gave up on WASM.

Concrete example: Rust is about fearless concurrency (e.g. with rayon) and wasm-bindgen-rayon simply doesn't work on Firefox. And it may work on Chrome (after you fight the super convoluted way of importing wasm) but if you have a single runtime error it's very weird to debug.

I've realized that unless you're building something really CPU or GPU intensive, like games, there is not much you gain from WASM. JS on the other hand runs *everywhere* without compilation (this is extremely underrated benefit), is easy to use and debug when it fails in runtime.

Faster is the most likely value prop, and the one with the most certain second-order effects. But polyglot could be really interesting too.

Faster not per se. It really depends and WASM is not a silver bullet for performance. It depends on multiple things.

The main advantages of wasm re: programming language interop Sandboxing portability to different architectures and platforms With arm, risc-v, x64, iOS, macos, windows, Linux and android cross-compiling and platform incompatibilities are becoming a nightmare

I say do not rewrite everything with WASM. Find use cases for it and use it pragmatically. JS is really fast and runtimes like V8 optimize JS really well and WASM is not a silver bullet for performance. Polyglot sounds like the right direction.

once kotlin has js + wasm interop, i'm just gonna start writing almost everything in svelte and kotlin like, imagine a vite/webpack/rollup plugin to import *.kt files into js, plus auto-generated typedefs

wasm is delivering what java promised in the 90s and early 2000s, yet there is less hype I got laughed at the other day when I told our embedded devs that in 5 years we would be compiling our code to wasm instead of x64 (windows and Darwin) and arm7 (Darwin and Linux)

If we replace JS with WASM then web development will become a field I don't want to be in. Currently I have to know a ton of frameworks and tools (BE and FE). If we add WASM I have to know a ton of frameworks and tools for a dozen of languages and the languages themselves...

Sounds like JVM hype all over again.

Hmmmm

It helps that you can reasonable easy convert your Pascal, Go, VB, Swift code into WASM :)

We at work are using Go for our Android and iOS apps and use parts of the same code on the web via WASM without any rewrites. It's awesome