C#, the best upcoming news is Blazor. C# -> WebAssembly -> then run in minified Webrowser(Electron). That will give C# the ability to run anywhere. The ProofOfConcept is already done, now they are looking into how much they can minify the webbrowser. Current size is a couple of MB, but the dev-team at MS wants to shrink that to KB. =)
Currently developing futuristic smart-device, IoT connected, highway construction site safety system in EU.
Used to work on infrastructure, application architecture and cloud engineering.
Graduated in Digital Media M.Sc. now developing the next generation of educational software. Since a while I develop full stack in Javascript using Meteor. Love fitness and Muay Thai after work.
Currently developing futuristic smart-device, IoT connected, highway construction site safety system in EU.
Used to work on infrastructure, application architecture and cloud engineering.
Graduated in Digital Media M.Sc. now developing the next generation of educational software. Since a while I develop full stack in Javascript using Meteor. Love fitness and Muay Thai after work.
Currently developing futuristic smart-device, IoT connected, highway construction site safety system in EU.
Used to work on infrastructure, application architecture and cloud engineering.
Ah, I see. Basically while Blazor is front-end framework for building reactive applications (similar to React, Vue or Angular) it has in contrast 2 modes of operation. Client side rendering (similar to other frameworks based on Javascript or Typescript) where the code runs on the client. For this, of course since it is based on C# .Net you download minified version of .Net framework at very first run which technically is running as WebAssembly and AFAIK is currently based mostly on Mono (Open source .Net compatible framework for *nix systems that existed prior to multi-platform .Net Core).
The second mode of operation is Blazor server-side rendering using WebSockets. How this works is that your browser instead of downloading whole front-end application downlaods minimal WebSockets client that connects to the server, bootstraps your app and every request you do is handled and rendered at the server over this WebSockets connection where your browser downloads only resulting HTML and displays it by replacing the appropriate DOM elements.
The latter way was introduced in .Net Core 3.1 the former (client side) was until .Net Core 5.0 experimental but is getting wider adoption now.
Both have advantages and disadvantages, e.g. server side does not expose business logic but cannot work in offline scenarios (however supports automatic reconnection to the server) and updating it is easier and faster as all the code is on the server. Client side needs to load so far several megabytes of client binary (WebAssembly .Net Framework) at first run that is cached in the browser.
Hope that helped.
Did anyone say WebSockets?! =D Have you seen the draft for the upcoming replacement for WebSocket? It's called WebTransports and it will/can run through the Quic protocol instead of HTTP1/2. Which makes it blazing fast as a streaming protocol. I suspect that Microsoft will integrate it into Blazor as well. Here is the link for the draft: WebTransport
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
C#, the best upcoming news is Blazor. C# -> WebAssembly -> then run in minified Webrowser(Electron). That will give C# the ability to run anywhere. The ProofOfConcept is already done, now they are looking into how much they can minify the webbrowser. Current size is a couple of MB, but the dev-team at MS wants to shrink that to KB. =)Even the server-side Blazor over WebSockets is nuts.
I don't understand. Can you please elaborate?
Can you please be more specific what you don't understand and would like to get explained? I'd be glad to help.
I totally don't get the meaning of the sentence, since I rarely know Blazor nor it's relation to Websockets.
Ah, I see. Basically while Blazor is front-end framework for building reactive applications (similar to React, Vue or Angular) it has in contrast 2 modes of operation. Client side rendering (similar to other frameworks based on Javascript or Typescript) where the code runs on the client. For this, of course since it is based on C# .Net you download minified version of .Net framework at very first run which technically is running as WebAssembly and AFAIK is currently based mostly on Mono (Open source .Net compatible framework for *nix systems that existed prior to multi-platform .Net Core).
The second mode of operation is Blazor server-side rendering using WebSockets. How this works is that your browser instead of downloading whole front-end application downlaods minimal WebSockets client that connects to the server, bootstraps your app and every request you do is handled and rendered at the server over this WebSockets connection where your browser downloads only resulting HTML and displays it by replacing the appropriate DOM elements.
The latter way was introduced in .Net Core 3.1 the former (client side) was until .Net Core 5.0 experimental but is getting wider adoption now.
Both have advantages and disadvantages, e.g. server side does not expose business logic but cannot work in offline scenarios (however supports automatic reconnection to the server) and updating it is easier and faster as all the code is on the server. Client side needs to load so far several megabytes of client binary (WebAssembly .Net Framework) at first run that is cached in the browser.
Hope that helped.
Did anyone say WebSockets?! =D Have you seen the draft for the upcoming replacement for WebSocket? It's called WebTransports and it will/can run through the Quic protocol instead of HTTP1/2. Which makes it blazing fast as a streaming protocol. I suspect that Microsoft will integrate it into Blazor as well. Here is the link for the draft: WebTransport