13 ms·

It seems to me that Wasm largely succeeded and meets most/all of the goals for when it was created. The article backs this up by listing the many niches in whic

by Ameo 9mo ago

It seems to me that Wasm largely succeeded and meets most/all of the goals for when it was created. The article backs this up by listing the many niches in which its found support, and I personally have deployed dozens of projects (both personal and professional) that use Wasm as a core component. I''m personally a big fan of Wasm; it has been one of my favorite technologies ever since the first time I called malloc from the JS console when experimenting with an early version of Emscripten. Modern JS engines can be almost miraculously fast, but Wasm still offers the best performance and much higher levels of control over what's actually running on the CPU. I've written about this in the past. The only way it really fell short is in the way that a lot of people were predicting that it would become a sort of total replacement for JS+HTML+CSS for building web apps. In this regard, I'd have to agree. It could be the continued lack of DOM bindings that have been considered a key missing piece for several years now, or maybe something else or more fundamental. I've tried out some of the Wasm-powered web frameworks like Yew and not found them to provide an improvement for me at all. It just feels like an awkwardly bolted-on layer on top of JS and CSS without adding any new patterns or capabilities. Like you still have to keep all of the underlying semantics of the way JS events work, you still have to keep the whole DOM and HTML element system, and you also have to deal with all the new stuff the framework introduces on top of that. Things may be different with other frameworks like Blazor which I've not tried, but I just find myself wanting to write JS instead. I openly admit that it might just be my deep experience and comfort building web apps using React or Svelte though. Anyway, I strongly feel that Wasm is a successful technology. It's probably in a lot more places than you think, silently doing its job behind the scenes. That, to me, is a hallmark of success for something like Wasm.

deleted 9mo ago
[deleted]
gritzko 9mo ago
That is like Linux on a laptop. When you buy a laptop, you pay for Windows anyway.
- graemep 9mo ago
  Not necessarily. I bought a laptop with Linux preinstalled and its the best thing to do if you buy one with the intent of using Linux on it.
  - zdragnar 9mo ago
    That's what I thought when I bought a Dell XPS. Probably the worst laptop I've owned. There's lots of good options that come with windows preinstalled.
rob74 9mo ago
> The only way it really fell short is in the way that a lot of people were predicting that it would become a sort of total replacement for JS+HTML+CSS for building web apps. I for one hope that doesn't happen anytime soon. YouTube or Spotify could theoretically switch to Wasm drawing to a canvas right now (with a lot of development effort), but that would make the things that are currently possible thanks to the DOM (scraping, ad blockers etc.) harder or impossible.
- ivell 9mo ago
  I suspect this will be coming soon. For ad-driven companies, having an opaque deployment which would prevent ad-blockers would be ideal. However ads still need to be delivered over the net so there is still some way to block them (without resorting to router/firewall level blocking).
  - creata 9mo ago
    They'd be raked over the coals for the lack of accessibility, I hope.
    - javcasas 9mo ago
      That's like the mafia being raked over the coals for not having accessibility ramps for wheelchairs in their clandestine distilleries. Not gonna happen.
      - lynx97 9mo ago
        You are probably right. What will happen is that ad-blocker people will indirectly kill accessibility. That would make a lot of sense in this world. Its a reoccuring pattern. Spam killed a part of accessibility indirectly via CAPTCHA. And "it is my god-given right to block ads of free services I use" people will indirectly finally kill accessibility for good, now that we have <canvas>.
- gf000 9mo ago
  > DOM (scraping, ad blockers etc.) harder or impossible. This is a cat mouse fight, and Facebook already does some ultra-shady stuff like rendering a word as a list of randomly ordered divs for each character, and only using CSS to display in a readable way. But it can't be made impossible, at the worst case we can always just capture the screen and use an AI to recognize ads, wasting a lot of energy. The same is true for cheating in video games and many forms of online integrity problems - I can just hire a good player who would play in my place, and no technology could recognize that.
stkdump 9mo ago
I never thought that it would be a promising approach to build entire web apps using wasm. You don't just have to make it possible to interact with the DOM. You also have to have the right high level language to do this kind of DOM interaction and application logic. JS isn't bad for that purpose and it would probably take a lot to find something that is much better (which compiles to WASM instead of js, like ts and svelte do). The only real avenue for js-free web applications would be to completely abandon the browser rendering path and have everything render into a canvas. There are experiments to use UI toolkits designed for the desktop. But even that I see more of a niche solution and unlikely to become very widely used. HTML/css/js have become the lingua franca of UI development and they are taking over desktop applications as well. Why should that trend reverse?
- codeflo 9mo ago
  Maybe that's not the dominant mindset anymore, but I for one would love to use a language that's actually built for functional/reactive programming instead of inventing half-baked JavaScript dialects for that purpose. Elm was a language in that spirit, but it never felt complete.
  - lynx97 9mo ago
    You can probably build something in PureScript.
    - pjmlp 9mo ago
      Gone are the days it used to show up routinely in sites like HN, another proof how the language adoption cycles go.
    - ddellacosta 9mo ago
      Makes me sad that PureScript doesn't have more adoption, not that I'm surprised. It's orders of magnitude better than Elm and even improves upon Haskell in some meaningful ways (row polymorphism).
- lynx97 9mo ago
xipix 9mo ago
The article seems to evaluate Wasm as it were a framework upon which apps are built. It's not that, it's an orthogonal technology allowing CPU optimisations and reuse of native code in the browser. Against that expectation, it has been a huge success despite not yet reaching bare-metal levels of performance and energy efficiency. One such example: audio time stretch in the browser based upon a C++ library [1]. There is no way that if this were implemented in JS that it could deliver (a) similar performance or (b) source code portability to native apps. [1] https://bungee.parabolaresearch.com/change-audio-speed-pitch https://bungee.parabolaresearch.com/change-audio-speed-pitch
- coldtea 9mo ago
  >despite not yet reaching bare-metal levels of performance and energy efficiency. "Not yet"? It will never reach "bare-metal levels of performance and energy efficiency".
  - creata 9mo ago
    Why? My only guess is that the instructions don't match x86 instructions well (way too few Wasm instructions) and the runtime doesn't have enough time to compile them to x86 instructions as well as, say, GCC could.
    - HPsquared 9mo ago
      To be fair, x86 instructions don't match internal x86 processor architecture either.
      - 201984 9mo ago
        How don't they? Most x86 instructions map to just one or two uops as you can see at https://uops.info https://uops.info
  - flohofwoe 9mo ago
    FWIW the native and WASM versions of my home computer emulators are within about 5% of each other (on an ARM Mac), e.g. more or less 'measuring noise': https://floooh.github.io/tiny8bit/ https://floooh.github.io/tiny8bit/ You can squeeze out a bit more by building with -march=native, but then there's no reason that a WASM engine couldn't do the same.
pmontra 9mo ago
About building web apps: > It could be the continued lack of DOM bindings that have been considered a key missing piece for several years now, or maybe something else or more fundamental. More fundamentally, every front end developer uses more or less the same JS language (Typescript included) and every module is more or less interoperable. As WASM is a compilation target, every developer could be using a different language and different tools and libraries. One of them could have reached critical mass but there is a huge incumbent (JS) that shadows everything else. So special purpose parts of web apps can be written in one of those other languages but there still is a JS front end between them and the user and GUIs can be huge apps. It looks like a system targeted to optimizations. And for the backend, if one writes Rust or any other compiled language that can target WASM, why compiling to WASM and not to native code?
- CuriouslyC 9mo ago
  Using WASM lets you bundle native stuff in NPM packages without cross compiling.
catapart 9mo ago
Agreed. This article feels like someone asking "What happened to ffmpeg?" It's like...ah, yeah, I see how you might not hear about it, but uh... it's everywhere.
afavour 9mo ago
> The only way it really fell short is in the way that a lot of people were predicting that it would become a sort of total replacement for JS+HTML+CSS for building web apps. Agreed and I’m personally glad progress on that hasn’t moved quickly. My biggest fear with WASM is that even the simplest web site would end up needing to download a multi MB Python runtime just because the author didn’t want to use JS! The sad reality is that the slowness very often comes from the DOM, not from JavaScript. Don’t get me wrong, there could be improvements, e.g. VDOM diffing would be a cinch with tuples and records, but ultimately you have to interact with the DOM at some point.
lenkite 9mo ago
> It could be the continued lack of DOM bindings that have been considered a key missing piece for several years now, or maybe something else or more fundamental. No, it is NOT "something else or more fundamental" - it is most certainly the lack of proper, performant access to the DOM without having to use crazy, slow hacks. Do that and frontend web-apps will throw JS into the gutter within a decade.
- ggiigg 9mo ago
  They will not. E.g WordPress and Dajango are 20 years old and still very popular. People don't just jump to hype because hacker news does.
- codelikeawolf 9mo ago
  > Do that and frontend web-apps will throw JS into the gutter within a decade. Why though? What's wrong with JS? I feel like it's gotten a lot better over the years. I don't really understand all the hate.
  - tpm 9mo ago
    > What's wrong with JS? Let's not go into that for the millionth time and instead perhaps ask yourself why is TS wildly successful and even before that everyone was trying to use anything-but-js.
    - codelikeawolf 9mo ago
      > Let's not go into that for the millionth time Ok, that's fair. My goal with this question wasn't to open a can of worms. But whenever I see a strong averse reaction to JS, I assume that the person hasn't tried using _modern_ JS. > why is TS wildly successful From my perspective, it stops me from making stupid mistakes, improves autocomplete, and adds more explicitness to the code, which is incredibly beneficial for large teams and big projects. But I don't think that answers my original question, because if you strip away the types, it's JS. > even before that everyone was trying to use anything-but-js Because JS used to suck a lot more, but it sucks a lot less now.
WorldMaker 9mo ago
> Things may be different with other frameworks like Blazor which I've not tried, but I just find myself wanting to write JS instead. Blazor WASM probably is among the best approaches to what is possible with WASM today, for better and worse. C# is a great language to write domain code in. A lot of companies like C# for their backends so you get same-language sharing between backend and frontend. The Razor syntax is among the better somewhat type-safe template languages in the wild, with reasonably good IDE support. C# was designed with FFI in mind (as compared to Java and some other languages) so JS imports and exports fit reasonably well in C#; the boundaries aren't too hairy. That said, C# by itself isn't always that big of leap from Typescript. C# has better pattern matching today, but overall the languages feel like step-brothers and in general the overhead of shipping an entire .NET CLR, most of the BCL, and your C# code as web assembly is a lot more than just writing things more vanilla in Typescript. You can also push C# more functional with libraries like LanguageExt (though you also fight the reasons to pick C# by doing so as so many engineers don't think LanguageExt feels enough like C# to justify using C#). I'm curious to try Bolero [0] as F# would be a more interesting jump/reason for WASM, but I don't think I could sell it to engineering teams at my day job. (Especially as it can't use Razor syntax, because Razor is pretty deeply tied to C# syntax, and has its own very different template languages.) With WASM not having easy direct access to the DOM, Blazor's renderer is basically what you would expect it to be: it tosses simple objects over to a tiny Virtual DOM renderer on the JS side. It has most of the advantages and disadvantages of just using something like React or Preact directly, but obviously a smaller body of existing performance optimizations. Blazor's Virtual DOM has relatively great performance given the WASM to JS and back data management and overhead concerns, but it's still not going to out-compete hand written Vanilla JS any time soon. [0] https://fsbolero.io/ https://fsbolero.io/
- Shalomboy 9mo ago
  I found Blazor WASM to be extremely helpful if you have to start from the opposite side of the spectrum. I was working in a self-proclaimed gov agency "Microsoft Shop" whose head of development was adamantly opposed to any sort of JS-driven web app development, but kept accepting requesting apps that fit perfectly into the SPA model. .NET 6 released a few months after I started and with it came a huge amount of progress with Blazor WASM. I had plenty of experience with Vue and Typescript, so Blazor WASM and C# mapped really easily to my existing model of how to build. That similarity also made it easy to onboard new grads who had experience in web dev but weren't familiar with C#. After enough evangelizing, we built a critical mass of projects leveraging Blazor WASM to convince leadership to reconsider his position on Typescript. I can't say enough nice things about the work Steve Sanderson has done to bring Blazor to the public.
eek2121 9mo ago
It won't ever replace anything, because most folks don't understand the tech. I've no other way to explain this except to present this question: which is more popular, ASM, or literally any other higher level language (C, C++, etc.)? Compilers, languages, and frameworks were built for ease of use for the end developer specifically so that any type of ASM would be avoided. Web technologies/frameworks along with Operating system APIs, etc. were a FURTHER level of abstraction. WASM has it's place, just the same as ASM has it's place. Trying to replace React with x86 ASM sounds foolish, does it not? The same goes for WASM. Why? WASM is designed for situations where performant, low latency compute is needed, along with low level control, etc. Even IF they integrated DOM, very few would use it. Most of today's developers don't even know ASM for any platform, and they aren't about to learn it. They want to be productive, not rewrite basic stuff. I mean shoot, as much as I dislike the AI bubble (AI/LLMs are great, corporate america is the issue), it is SHOWING what people want, which most of us already knew people wanted: we want to automate out the boring stuff and focus on the hard stuff.
- cush 9mo ago
  > WASM is designed for situations where performant, low latency compute is needed I don't get this argument at all. When is performance not needed? Every website can benefit from be faster than it currently is.
shams93 9mo ago
X used yew and rust to rebuild their client and had success in that they are dealing with lots of heavy lifting where these tools start to show their value for large scale products. For most products its immense overkill, for a lot of stuff even react is total overkill where htmx is a better choice.
sebazzz 9mo ago
At work we’re incrementally rewriting a legacy Javascript Electron application in Blazor / C# WASM. The biggest issue we’ve run into as far as WASM interop goes is that it is not really possible to pass objects between WASM and JS. It requires some form of serialization to JSON or a different blittable format. Since the data we work with in the application is quite large, this has caused some headaches.
- RagnarD 9mo ago
  But why are you? Unless it requires interfacing with a JS library or some JS operation on the DOM, the goal of a Blazor app is to write in C#, not JS. What's your JS code doing that it requires passing C# objects to it? (That said, Blazor supports JS Interop, see https://dev.to/rasheedmozaffar/intro-to-js-interop-in-blazor-46mo https://dev.to/rasheedmozaffar/intro-to-js-interop-in-blazor...)

by Ameo 9mo ago

deleted 9mo ago

[deleted]

gritzko 9mo ago

That is like Linux on a laptop. When you buy a laptop, you pay for Windows anyway.

graemep 9mo ago
Not necessarily. I bought a laptop with Linux preinstalled and its the best thing to do if you buy one with the intent of using Linux on it.
- zdragnar 9mo ago
  That's what I thought when I bought a Dell XPS. Probably the worst laptop I've owned. There's lots of good options that come with windows preinstalled.

rob74 9mo ago

> The only way it really fell short is in the way that a lot of people were predicting that it would become a sort of total replacement for JS+HTML+CSS for building web apps. I for one hope that doesn't happen anytime soon. YouTube or Spotify could theoretically switch to Wasm drawing to a canvas right now (with a lot of development effort), but that would make the things that are currently possible thanks to the DOM (scraping, ad blockers etc.) harder or impossible.

ivell 9mo ago
I suspect this will be coming soon. For ad-driven companies, having an opaque deployment which would prevent ad-blockers would be ideal. However ads still need to be delivered over the net so there is still some way to block them (without resorting to router/firewall level blocking).
- creata 9mo ago
  They'd be raked over the coals for the lack of accessibility, I hope.
  - javcasas 9mo ago
    That's like the mafia being raked over the coals for not having accessibility ramps for wheelchairs in their clandestine distilleries. Not gonna happen.
    - lynx97 9mo ago
      You are probably right. What will happen is that ad-blocker people will indirectly kill accessibility. That would make a lot of sense in this world. Its a reoccuring pattern. Spam killed a part of accessibility indirectly via CAPTCHA. And "it is my god-given right to block ads of free services I use" people will indirectly finally kill accessibility for good, now that we have <canvas>.
gf000 9mo ago
> DOM (scraping, ad blockers etc.) harder or impossible. This is a cat mouse fight, and Facebook already does some ultra-shady stuff like rendering a word as a list of randomly ordered divs for each character, and only using CSS to display in a readable way. But it can't be made impossible, at the worst case we can always just capture the screen and use an AI to recognize ads, wasting a lot of energy. The same is true for cheating in video games and many forms of online integrity problems - I can just hire a good player who would play in my place, and no technology could recognize that.

stkdump 9mo ago

I never thought that it would be a promising approach to build entire web apps using wasm. You don't just have to make it possible to interact with the DOM. You also have to have the right high level language to do this kind of DOM interaction and application logic. JS isn't bad for that purpose and it would probably take a lot to find something that is much better (which compiles to WASM instead of js, like ts and svelte do). The only real avenue for js-free web applications would be to completely abandon the browser rendering path and have everything render into a canvas. There are experiments to use UI toolkits designed for the desktop. But even that I see more of a niche solution and unlikely to become very widely used. HTML/css/js have become the lingua franca of UI development and they are taking over desktop applications as well. Why should that trend reverse?

codeflo 9mo ago
Maybe that's not the dominant mindset anymore, but I for one would love to use a language that's actually built for functional/reactive programming instead of inventing half-baked JavaScript dialects for that purpose. Elm was a language in that spirit, but it never felt complete.
- lynx97 9mo ago
  You can probably build something in PureScript.
  - pjmlp 9mo ago
    Gone are the days it used to show up routinely in sites like HN, another proof how the language adoption cycles go.
  - ddellacosta 9mo ago
    Makes me sad that PureScript doesn't have more adoption, not that I'm surprised. It's orders of magnitude better than Elm and even improves upon Haskell in some meaningful ways (row polymorphism).
lynx97 9mo ago

xipix 9mo ago

The article seems to evaluate Wasm as it were a framework upon which apps are built. It's not that, it's an orthogonal technology allowing CPU optimisations and reuse of native code in the browser. Against that expectation, it has been a huge success despite not yet reaching bare-metal levels of performance and energy efficiency. One such example: audio time stretch in the browser based upon a C++ library [1]. There is no way that if this were implemented in JS that it could deliver (a) similar performance or (b) source code portability to native apps. [1] https://bungee.parabolaresearch.com/change-audio-speed-pitch https://bungee.parabolaresearch.com/change-audio-speed-pitch

coldtea 9mo ago
>despite not yet reaching bare-metal levels of performance and energy efficiency. "Not yet"? It will never reach "bare-metal levels of performance and energy efficiency".
- creata 9mo ago
  Why? My only guess is that the instructions don't match x86 instructions well (way too few Wasm instructions) and the runtime doesn't have enough time to compile them to x86 instructions as well as, say, GCC could.
  - HPsquared 9mo ago
    To be fair, x86 instructions don't match internal x86 processor architecture either.
    - 201984 9mo ago
      How don't they? Most x86 instructions map to just one or two uops as you can see at https://uops.info https://uops.info
- flohofwoe 9mo ago
  FWIW the native and WASM versions of my home computer emulators are within about 5% of each other (on an ARM Mac), e.g. more or less 'measuring noise': https://floooh.github.io/tiny8bit/ https://floooh.github.io/tiny8bit/ You can squeeze out a bit more by building with -march=native, but then there's no reason that a WASM engine couldn't do the same.

pmontra 9mo ago

About building web apps: > It could be the continued lack of DOM bindings that have been considered a key missing piece for several years now, or maybe something else or more fundamental. More fundamentally, every front end developer uses more or less the same JS language (Typescript included) and every module is more or less interoperable. As WASM is a compilation target, every developer could be using a different language and different tools and libraries. One of them could have reached critical mass but there is a huge incumbent (JS) that shadows everything else. So special purpose parts of web apps can be written in one of those other languages but there still is a JS front end between them and the user and GUIs can be huge apps. It looks like a system targeted to optimizations. And for the backend, if one writes Rust or any other compiled language that can target WASM, why compiling to WASM and not to native code?

CuriouslyC 9mo ago
Using WASM lets you bundle native stuff in NPM packages without cross compiling.

catapart 9mo ago

Agreed. This article feels like someone asking "What happened to ffmpeg?" It's like...ah, yeah, I see how you might not hear about it, but uh... it's everywhere.

afavour 9mo ago

> The only way it really fell short is in the way that a lot of people were predicting that it would become a sort of total replacement for JS+HTML+CSS for building web apps. Agreed and I’m personally glad progress on that hasn’t moved quickly. My biggest fear with WASM is that even the simplest web site would end up needing to download a multi MB Python runtime just because the author didn’t want to use JS! The sad reality is that the slowness very often comes from the DOM, not from JavaScript. Don’t get me wrong, there could be improvements, e.g. VDOM diffing would be a cinch with tuples and records, but ultimately you have to interact with the DOM at some point.

lenkite 9mo ago

> It could be the continued lack of DOM bindings that have been considered a key missing piece for several years now, or maybe something else or more fundamental. No, it is NOT "something else or more fundamental" - it is most certainly the lack of proper, performant access to the DOM without having to use crazy, slow hacks. Do that and frontend web-apps will throw JS into the gutter within a decade.

ggiigg 9mo ago
They will not. E.g WordPress and Dajango are 20 years old and still very popular. People don't just jump to hype because hacker news does.
codelikeawolf 9mo ago
> Do that and frontend web-apps will throw JS into the gutter within a decade. Why though? What's wrong with JS? I feel like it's gotten a lot better over the years. I don't really understand all the hate.
- tpm 9mo ago
  > What's wrong with JS? Let's not go into that for the millionth time and instead perhaps ask yourself why is TS wildly successful and even before that everyone was trying to use anything-but-js.
  - codelikeawolf 9mo ago
    > Let's not go into that for the millionth time Ok, that's fair. My goal with this question wasn't to open a can of worms. But whenever I see a strong averse reaction to JS, I assume that the person hasn't tried using _modern_ JS. > why is TS wildly successful From my perspective, it stops me from making stupid mistakes, improves autocomplete, and adds more explicitness to the code, which is incredibly beneficial for large teams and big projects. But I don't think that answers my original question, because if you strip away the types, it's JS. > even before that everyone was trying to use anything-but-js Because JS used to suck a lot more, but it sucks a lot less now.

WorldMaker 9mo ago

> Things may be different with other frameworks like Blazor which I've not tried, but I just find myself wanting to write JS instead. Blazor WASM probably is among the best approaches to what is possible with WASM today, for better and worse. C# is a great language to write domain code in. A lot of companies like C# for their backends so you get same-language sharing between backend and frontend. The Razor syntax is among the better somewhat type-safe template languages in the wild, with reasonably good IDE support. C# was designed with FFI in mind (as compared to Java and some other languages) so JS imports and exports fit reasonably well in C#; the boundaries aren't too hairy. That said, C# by itself isn't always that big of leap from Typescript. C# has better pattern matching today, but overall the languages feel like step-brothers and in general the overhead of shipping an entire .NET CLR, most of the BCL, and your C# code as web assembly is a lot more than just writing things more vanilla in Typescript. You can also push C# more functional with libraries like LanguageExt (though you also fight the reasons to pick C# by doing so as so many engineers don't think LanguageExt feels enough like C# to justify using C#). I'm curious to try Bolero [0] as F# would be a more interesting jump/reason for WASM, but I don't think I could sell it to engineering teams at my day job. (Especially as it can't use Razor syntax, because Razor is pretty deeply tied to C# syntax, and has its own very different template languages.) With WASM not having easy direct access to the DOM, Blazor's renderer is basically what you would expect it to be: it tosses simple objects over to a tiny Virtual DOM renderer on the JS side. It has most of the advantages and disadvantages of just using something like React or Preact directly, but obviously a smaller body of existing performance optimizations. Blazor's Virtual DOM has relatively great performance given the WASM to JS and back data management and overhead concerns, but it's still not going to out-compete hand written Vanilla JS any time soon. [0] https://fsbolero.io/ https://fsbolero.io/

Shalomboy 9mo ago
I found Blazor WASM to be extremely helpful if you have to start from the opposite side of the spectrum. I was working in a self-proclaimed gov agency "Microsoft Shop" whose head of development was adamantly opposed to any sort of JS-driven web app development, but kept accepting requesting apps that fit perfectly into the SPA model. .NET 6 released a few months after I started and with it came a huge amount of progress with Blazor WASM. I had plenty of experience with Vue and Typescript, so Blazor WASM and C# mapped really easily to my existing model of how to build. That similarity also made it easy to onboard new grads who had experience in web dev but weren't familiar with C#. After enough evangelizing, we built a critical mass of projects leveraging Blazor WASM to convince leadership to reconsider his position on Typescript. I can't say enough nice things about the work Steve Sanderson has done to bring Blazor to the public.

eek2121 9mo ago

It won't ever replace anything, because most folks don't understand the tech. I've no other way to explain this except to present this question: which is more popular, ASM, or literally any other higher level language (C, C++, etc.)? Compilers, languages, and frameworks were built for ease of use for the end developer specifically so that any type of ASM would be avoided. Web technologies/frameworks along with Operating system APIs, etc. were a FURTHER level of abstraction. WASM has it's place, just the same as ASM has it's place. Trying to replace React with x86 ASM sounds foolish, does it not? The same goes for WASM. Why? WASM is designed for situations where performant, low latency compute is needed, along with low level control, etc. Even IF they integrated DOM, very few would use it. Most of today's developers don't even know ASM for any platform, and they aren't about to learn it. They want to be productive, not rewrite basic stuff. I mean shoot, as much as I dislike the AI bubble (AI/LLMs are great, corporate america is the issue), it is SHOWING what people want, which most of us already knew people wanted: we want to automate out the boring stuff and focus on the hard stuff.

cush 9mo ago
> WASM is designed for situations where performant, low latency compute is needed I don't get this argument at all. When is performance not needed? Every website can benefit from be faster than it currently is.

shams93 9mo ago

X used yew and rust to rebuild their client and had success in that they are dealing with lots of heavy lifting where these tools start to show their value for large scale products. For most products its immense overkill, for a lot of stuff even react is total overkill where htmx is a better choice.

sebazzz 9mo ago

At work we’re incrementally rewriting a legacy Javascript Electron application in Blazor / C# WASM. The biggest issue we’ve run into as far as WASM interop goes is that it is not really possible to pass objects between WASM and JS. It requires some form of serialization to JSON or a different blittable format. Since the data we work with in the application is quite large, this has caused some headaches.

RagnarD 9mo ago
But why are you? Unless it requires interfacing with a JS library or some JS operation on the DOM, the goal of a Blazor app is to write in C#, not JS. What's your JS code doing that it requires passing C# objects to it? (That said, Blazor supports JS Interop, see https://dev.to/rasheedmozaffar/intro-to-js-interop-in-blazor-46mo https://dev.to/rasheedmozaffar/intro-to-js-interop-in-blazor...)