Blazor Mobile, Uno Platform, and WebAssembly(platform.uno)
platform.uno
Blazor Mobile, Uno Platform, and WebAssembly
https://platform.uno/blazor-mobile-uno-platform-and-webassembly-piling-up-the-tech/
8 comments
I've used Blazor for one project, and it was a true joy to learn. All the good parts of React, but without some of the clunky design decisions that come from having to work with traditional browser javascript.
Wow its great to see an actual working webassembly site in the wild. https://todo-blazornative-wasm.platform.uno/ Ive been looking for a while.
Its a bunch slower than I was expecting. I was hoping to be impressed, now I'm not sure. Is there a reason its slow?
Its a bunch slower than I was expecting. I was hoping to be impressed, now I'm not sure. Is there a reason its slow?
As you can see in the top banner, it's using the "interpreted" mode, which is the slowest runtime mode for running .NET on mono-wasm. But it's also the "compatible" mode.
It would be possible to produce an AOT build which would be 50x faster, but it's a little more work and it wasn't the goal of this demo.
It would be possible to produce an AOT build which would be 50x faster, but it's a little more work and it wasn't the goal of this demo.
Impressing with performance is one hell of a goal for a demo.
Here is another one then - Windows Calculator running in the browser. https://calculator.platform.uno/
Chrome says 68.4MB(10.5MB compressed)for the Todo app and 61 for the calculator app.
If you look in the *.clr files you see things like "This program cannot be run in DOS mode." which i found amusing.
If you look in the *.clr files you see things like "This program cannot be run in DOS mode." which i found amusing.
Will the challenge be that you cannot hook to low enough UI/human interaction events to build an alternative for DOM? E.g. Paste menu is impossible to do (needs CTRL+V in Google docs for Firefox), cannot get information about keyboard typing mode in multilingual setups and so on.
IIRC Flipboard once tried this approach, rendering everything to a <canvas>. As it stands right now, that will never be a viable solution for the reasons you mentioned, along with the fact you throw literally all accessibility features out the window.