5 ms·

I think you’re a little misconceived, WebAssembly runs entirely in the client and have no bindings to the server, as far as the server is concerned such apps ma

by dagaci 3y ago

I think you’re a little misconceived, WebAssembly runs entirely in the client and have no bindings to the server, as far as the server is concerned such apps may as well be static HTML. This is Blazor WebAssembly. It will be just as trivial to run such on Mac, Linux or Windows server or any other plain web servers. TeaVM seems to be the same except it compiles Java to JavaScript which means has fast startup times. Web browsers and their fundamental development foundations are best described as a set of mostly well meaning compromises, and so even modern browsers have been updated to support all the other disagreeable things you have mentioned, even having the ability to navigate the browser history within an SPA

knome 3y ago
Ah, sure, for whatever WASM variant you're referring to. Whichever form of blazor I use pretty obviously makes calls back to the server to interact with client state on a per-event basis. If the backend has to restart, the clients all lose connection and die. I won't pretend to be an expert in the framework, or even C#. I had avoided both until recently, and this introduction hasn't made me particularly fond of either.
- gwbas1c 3y ago
  Server-side or WASM is an option when you create a Blazor project in Visual Studio. You can write libraries and either approach can use the same library. Server-side Blazor keeps a websocket open to send messages back and forth. If you can tolerate the latency, it allows your UI code to be able to handle data that needs to remain secret on the server.
- dagaci 3y ago
  Its pretty fundamental stuff to know the difference between what is server side and what is client side. I think you will have a lot of trouble undertanding a framework without this. Blazor WebAssemly requires you make explicity Ajax-like Calls to external web services in order to interact with a server and data. There is no server side framework in WebAssembly for maintaining state. State is entirely client side. Blazor Server basically uses Web Sockets (with fallbacks) to communicate changes between client and server, this is far more efficient than using http request calls. State here is server side. But differs from all other frameworks in that state is trasmitted over sockets not http requests. I'm not convinced you have actually used any kind blazor tbh
  - knome 3y ago
    At no point was I confused as to the server-side vs client-side nature of the software. I've been using what I assumed was the default of server-side blazor and was casually agreeing that, yes, a WASM compiled variant would obviously run fully in the browser. >I'm not convinced you have actually used any kind blazor tbh good for you, buddy.

by dagaci 3y ago

knome 3y ago

Ah, sure, for whatever WASM variant you're referring to. Whichever form of blazor I use pretty obviously makes calls back to the server to interact with client state on a per-event basis. If the backend has to restart, the clients all lose connection and die. I won't pretend to be an expert in the framework, or even C#. I had avoided both until recently, and this introduction hasn't made me particularly fond of either.

gwbas1c 3y ago
Server-side or WASM is an option when you create a Blazor project in Visual Studio. You can write libraries and either approach can use the same library. Server-side Blazor keeps a websocket open to send messages back and forth. If you can tolerate the latency, it allows your UI code to be able to handle data that needs to remain secret on the server.
dagaci 3y ago
Its pretty fundamental stuff to know the difference between what is server side and what is client side. I think you will have a lot of trouble undertanding a framework without this. Blazor WebAssemly requires you make explicity Ajax-like Calls to external web services in order to interact with a server and data. There is no server side framework in WebAssembly for maintaining state. State is entirely client side. Blazor Server basically uses Web Sockets (with fallbacks) to communicate changes between client and server, this is far more efficient than using http request calls. State here is server side. But differs from all other frameworks in that state is trasmitted over sockets not http requests. I'm not convinced you have actually used any kind blazor tbh
- knome 3y ago
  At no point was I confused as to the server-side vs client-side nature of the software. I've been using what I assumed was the default of server-side blazor and was casually agreeing that, yes, a WASM compiled variant would obviously run fully in the browser. >I'm not convinced you have actually used any kind blazor tbh good for you, buddy.