4 ms·

I'm honestly surprised at how slow WASM is moving. As a very experienced web dev, when I first learned about WASM I was sure people would be building production

I'm honestly surprised at how slow WASM is moving. As a very experienced web dev, when I first learned about WASM I was sure people would be building production UIs in Python and Golang and other traditionally server-side languages.

Muromec 1y ago
Wasm doesn help much with UI, its more about moving parts of the server into the client as blacboxes with no access to dom. The blackbox can of course return the state of UI to be rendered/pathced, but that doesnt unlock much (if any) interesting capabilities for amount of overhead it adds
eterm 1y ago
Well there's blazor, which does that rather well, but it's treated with the same suspicion that most MS frameworks are. The fear that it'll be killed for poor adoption, leading to poor adoption. The blazor adoption probably isn't even that bad, but it's hard for MS to shake this stigma since so many people got burned on Silverlight and don't ever want to make the same mistake.
- throwawaymaths 1y ago
  I thought blazor failed because people didn't like websites that take minutes to load up all the websites assets. I'm not sure why, it could be: - Technical issue with blazor performance or blazor makes perf regressions hard to fix - blazor technical framework encourages programming style that is bad for perf - blazor or blazor ecosystem attracts programmers that can't deal with perf issues
  - josephg 1y ago
    As I understand it, blazor really needs WasmGC in order to have good performance and small bundle sizes. Otherwise, blazor is forced to ship a GC inside the wasm bundle - and that adds a lot of weight. And it also makes it more complex to share C# objects with javascript. WasmGC is supported in all browsers + nodejs now, but its still pretty new. Safari only started shipping it in December last year. I'm not sure if wasmgc is the default build for blazor, or what the status is on it. Blazor should be able to be good, small and fast. (Maybe even smaller than rust web frameworks.) But I don't know if we're there yet.
    - lylejantzi3rd 1y ago
      Doesn't Blazor include the entire .net core runtime? Or has that changed?
    - chris_pie 1y ago
      .NET doesn't use WasmGC because Microsoft found it too different from how .NET's GC works. Which is quite unfortunate
      - josephg 1y ago
        Oh what a pity. Anywhere I can read more about that?
        chris_pie 1y ago
        I can't find the actual decision, but there was some discussion here: https://github.com/WebAssembly/gc/issues/77 https://github.com/WebAssembly/gc/issues/77 Microsoft later in 2023 said that that discussion "is the current state we are in. We will keep eye on wasm GC in the future." edit: found a more concrete statement https://github.com/dotnet/runtime/issues/94420 https://github.com/dotnet/runtime/issues/94420
    - throwawaymaths 1y ago
      Then explanations 2&3?
- pier25 1y ago
  Blazor wasm is just too heavy for most use cases. In terms of speed, it's not even close to anything else in JS: https://krausest.github.io/js-framework-benchmark/current.html https://krausest.github.io/js-framework-benchmark/current.ht...
afavour 1y ago
That’s actually what I feared the most and I’m glad we haven’t seen it happen. Python and Go are not small languages, making users download entire runtimes to do something that can be done fine without them would be a huge shame. The performance problem with web UI is the DOM, not JavaScript.
- lylejantzi3rd 1y ago
  You can mitigate some of that with web workers, but it's a shame that multiple websites can't share a python runtime the same way they can on a shared linux box. You have to download a separate one for every website that uses it. But, if you follow that train of thought to the end, you wind up with the browser itself bundling those runtimes, just like it did with Flash back in the day. I'm not sure any of this would be an improvement over what we have now.
  - chii 1y ago
    the only good reason to build these runtimes is to enable existing applications to be recompiled into wasm for use inside the browser - it doesnt make sense to greenfield an application that uses non-web UI libraries, only to then bundle the entire UI runtime with it.
- hinkley 1y ago
  At least with Go static analysis should allow you to tree shake the bits you aren’t using. The problem with the CDN solution was always that it assumed that everyone would be on a couple versions and that never happens. With success comes more contributors and with more contributors come more point releases and more users who are not on the latest version. So soon you could have five versions for five sites you visit.
- camdenreslink 1y ago
  I kind of thought popular runtimes would just be bundled with the browser if we could get an "official" enough source (e.g. Python Software Foundation or Google). Then users wouldn't need to download a million different versions and sources of Python for each website.
IshKebab 1y ago
I really hope nobody plans to make web front-ends in Python. Jesus.
jcmontx 1y ago
That's what the .NET folks have been doing for many years now. Blazor is .NET on the client-side
lenkite 1y ago
[dead]

Muromec 1y ago

Wasm doesn help much with UI, its more about moving parts of the server into the client as blacboxes with no access to dom. The blackbox can of course return the state of UI to be rendered/pathced, but that doesnt unlock much (if any) interesting capabilities for amount of overhead it adds

eterm 1y ago

Well there's blazor, which does that rather well, but it's treated with the same suspicion that most MS frameworks are. The fear that it'll be killed for poor adoption, leading to poor adoption. The blazor adoption probably isn't even that bad, but it's hard for MS to shake this stigma since so many people got burned on Silverlight and don't ever want to make the same mistake.

throwawaymaths 1y ago
I thought blazor failed because people didn't like websites that take minutes to load up all the websites assets. I'm not sure why, it could be: - Technical issue with blazor performance or blazor makes perf regressions hard to fix - blazor technical framework encourages programming style that is bad for perf - blazor or blazor ecosystem attracts programmers that can't deal with perf issues
- josephg 1y ago
  As I understand it, blazor really needs WasmGC in order to have good performance and small bundle sizes. Otherwise, blazor is forced to ship a GC inside the wasm bundle - and that adds a lot of weight. And it also makes it more complex to share C# objects with javascript. WasmGC is supported in all browsers + nodejs now, but its still pretty new. Safari only started shipping it in December last year. I'm not sure if wasmgc is the default build for blazor, or what the status is on it. Blazor should be able to be good, small and fast. (Maybe even smaller than rust web frameworks.) But I don't know if we're there yet.
  - lylejantzi3rd 1y ago
    Doesn't Blazor include the entire .net core runtime? Or has that changed?
  - chris_pie 1y ago
    .NET doesn't use WasmGC because Microsoft found it too different from how .NET's GC works. Which is quite unfortunate
    - josephg 1y ago
      Oh what a pity. Anywhere I can read more about that?
      - chris_pie 1y ago
        I can't find the actual decision, but there was some discussion here: https://github.com/WebAssembly/gc/issues/77 https://github.com/WebAssembly/gc/issues/77 Microsoft later in 2023 said that that discussion "is the current state we are in. We will keep eye on wasm GC in the future." edit: found a more concrete statement https://github.com/dotnet/runtime/issues/94420 https://github.com/dotnet/runtime/issues/94420
  - throwawaymaths 1y ago
    Then explanations 2&3?
pier25 1y ago
Blazor wasm is just too heavy for most use cases. In terms of speed, it's not even close to anything else in JS: https://krausest.github.io/js-framework-benchmark/current.html https://krausest.github.io/js-framework-benchmark/current.ht...

afavour 1y ago

That’s actually what I feared the most and I’m glad we haven’t seen it happen. Python and Go are not small languages, making users download entire runtimes to do something that can be done fine without them would be a huge shame. The performance problem with web UI is the DOM, not JavaScript.

lylejantzi3rd 1y ago
You can mitigate some of that with web workers, but it's a shame that multiple websites can't share a python runtime the same way they can on a shared linux box. You have to download a separate one for every website that uses it. But, if you follow that train of thought to the end, you wind up with the browser itself bundling those runtimes, just like it did with Flash back in the day. I'm not sure any of this would be an improvement over what we have now.
- chii 1y ago
  the only good reason to build these runtimes is to enable existing applications to be recompiled into wasm for use inside the browser - it doesnt make sense to greenfield an application that uses non-web UI libraries, only to then bundle the entire UI runtime with it.
hinkley 1y ago
At least with Go static analysis should allow you to tree shake the bits you aren’t using. The problem with the CDN solution was always that it assumed that everyone would be on a couple versions and that never happens. With success comes more contributors and with more contributors come more point releases and more users who are not on the latest version. So soon you could have five versions for five sites you visit.
camdenreslink 1y ago
I kind of thought popular runtimes would just be bundled with the browser if we could get an "official" enough source (e.g. Python Software Foundation or Google). Then users wouldn't need to download a million different versions and sources of Python for each website.

IshKebab 1y ago

I really hope nobody plans to make web front-ends in Python. Jesus.

jcmontx 1y ago

That's what the .NET folks have been doing for many years now. Blazor is .NET on the client-side

lenkite 1y ago

[dead]