|
I've summarized the differences in a convenient chart
Blazor justification:
Fundamentally, it deploys a .net runtime in a browser as a big chunk of WASM. This will always be bigger than the TeaVM method of compiling bytecode to JavaScript, no JVM needed.
Notable Features:
Debugging in the browser let you see the original source (like TeaVM), but also allowed variable inspection.
The demo app was very slow to load, even locally, taking at least 10 seconds. Compare that to the CoronaWait 3s launch time over the internet!
The second demo showed entered data cached while offline, then synced once back within wifi range. It wasn't clear if that is built into the framework or required custom app logic.
Localization (L10N) uses rex files, the C# version of property files. Flavour should consider something like this to allow Java-native L10N.
Blazor currently lacks threading.
The Blazor team compiles the .net VM to WASM using emscripten. This is kind of like what CheerpJ does. And we've seen how that works out.
Blazor apparently supports debug and production builds. Like TeaVM, the production mode omits the source code.
Someone asked how small the download size could be, could it even get to 100KB? Answer: "Not realistic, it won't be possible" —Steve Sanderson, Microsoft Blazor team. Steve said they might be able to get down to 1.6MB. Compare that to real-world download sizes of 130KB for CoronaWait.
One comment that will resonate with TeaVM users is, "now I can add Senior Full Stack Developer to my resume".
TeaVM: When You Want To Do Today What Blazor Will Never Do.
Copyright © 2024 Andrew Oliver