21–30 of 31 posts
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.
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.
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.
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.
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.
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.
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.
Earlier quoted context omitted.
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
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…
AtomVM is something like 1m when compiled, isn't it?
Compiled to WASM it's ~700K, gzipped only 190K. But there's also BEAM code - the whole standard library is ~3M gzipped. We plan to do tree shaking to only include the used parts of the stdlib - then it should get way smaller for most use cases.
Cool thing would be to somehow wire it up to liveview to make it possible to run some parts on the frontend side transparently.
I'm not doing any active development on it right now, but it looked pretty doable when I tried last time.
Earlier quoted context omitted.
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…
.NET doesn't use WasmGC because Microsoft found it too different from how .NET's GC works. Which is quite unfortunate
Earlier quoted context omitted.
.NET doesn't use WasmGC because Microsoft found it too different from how .NET's GC works. Which is quite unfortunate
Oh what a pity. Anywhere I can read more about that?
edit: found a more concrete statement https://github.com/dotnet/runtime/issues/94420
Earlier quoted context omitted.
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
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…
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.