HN user
Gyroc was amazing at the time and is still spoken about in hushed tones in the UK HPR community. While it was using ADXL50 devices for acceleration, the main gyro was an entirely custom built mechanical rotating gyro, wish I still had some pictures of it. Now that's all on a single chip you hardly even notice on the board :) Some pictures of it are here http://ukrocketman.com/rocketry/gimbal.shtml
The component vendors are jumping on board as well https://demos.devexpress.com/blazor/ https://www.telerik.com/blazor-ui https://www.syncfusion.com/blazor-components https://www.matblazor.com/
There's some good demos on their sites. The 'official' one could do with an update!
Yep, that's pretty much the aim :)
Blazor has been split into two versions, there is a server side and a client side version, both that share the same component model. The server side version went GA a last week with .Net core 3.0, the client side is looking like it will GA in April 2020. The reason given is that their not happy with the size of the payloads required for now, the aim to have everything compiled to webAssembly by then, not just the mono runtime that's running as an IL interpreter at the moment.
The server side version is interesting, it ships DOM updates to the client from the server over a websocket (musch like OOUI https://github.com/praeclarum/Ooui). Not something that I'd use for production, but for quick internal projects which have the feel of a client side SPA, but while not requiring you to build the API layer it's quite neat.
There's an interview with MG talking about these cables on the Amp Hour podcast this week https://theamphour.com/the-amp-hour-454-mike-grover/
My understanding was that, at least for this example, is that the DNA runtime is loading raw IL, not webasm, and the interesting site specific stuff will be in IL. I do not doubt what you're saying about webasm.
If it ends up executing IL, then tools like Reflector will probably make it easier to read and explore the code than minified JS
The Asp.Net core are on record several times saying the primary goal was to be able to cram more websites per host for Azure Websites to reduce costs and to remove the issues of servicing a machine wide framework. Sounds like 'cloud optimized' was a good fit in the early days! :)