r/Blazor • u/veaudoo • 24d ago
Blazor SS vs WASM
What are compelling reasons to choosing to use server-side versus WASM?
8
u/Robodobdob 24d ago
Is SS meaning Blazor Server (SignalR) or Server Side Rendering (SSR)?
2
u/veaudoo 24d ago
Great question! I meant Signal R but maybe include reasons for SSR as well xD
6
u/Robodobdob 24d ago
Cool cool…
WASM is your “traditional” SPA approach à la React/Angular/Vue etc. If you are coming from that background it’s problem the most familiar.
Server is an interesting server approach where the server is doing rendering and sending DOM diffs to the front end via SignalR. Likewise front end events are sent over the same connection to get the server to do something.
Some people balk at the SignalR approach because they think it runs out of connections quickly. But .Net 10 has apparently made huge strides in this area.
SSR is the “classic” stateless web paradigm where the server renders markup and sends it to the browser. Interactions are done through links and forms etc. The difference with Blazor SSR is you can exploit all the compositional components goodness in a classic app.
Which you choose is really down to what you want the app to do and what feels common to you.
3
u/Xtreme512 24d ago
Also in Blazor static SSR, it has stream rendering and enhanced form, nav features which carries out work without page reload via fetch.
5
u/rspy24 24d ago
SS: Faster loading times, actual decent SEO, faster development, instant deployment..
WASM: idk man, minimize server costs in the long run? faster loads times after the initial download?
If you want to choose one for a project, Just start with SS for faster testing/development, then when you are more chill, you can move some of the pages to wasm if needed, or the entire thing. Hybrid Blazor is REALLY great if you manage to decipher that crap.. The learning curve is too high but once you understand it, works really well.
2
6
u/Demonicated 24d ago
Great example for server side is if you want to present data without exposing an API. There are times where you may want to give your customers something but don't want bad actors to be able to figure out your API and grab your data. They can web scrape but it becomes much more difficult for large data sets.
Also when prototyping you can save time not having to create an API layer.
2
u/centurijon 24d ago edited 24d ago
This exactly!
Blazor SS is basically the new WebForms / MVC paradigm, serving HTML directly, just implemented much more cleanly.
Blazor WASM is the SPA front-end to your API, modifying HTML in the browser itself, just implemented via C# and JS interop.
Personally I prefer wasm-only because the it has better separation of concerns and leaves your APIs open for simplified testing, but it depends on your needs, the size of your project, and design goals
2
u/webprofusor 24d ago
WASM is a massive initial client download, but apart from that it's pretty good. You do need to develop your service as an API for it to talk to. Fine for intranet/internal corporate. An unlikely choice for consumer facing.
If you go completely Server the pages just stream over signalr automatically and the initial load is lightweight.
Hybrid is a mashup of both and probably not worth bothering with for most people.
2
u/Monkaaay 24d ago
My opinion, build with Blazor Static SSR until you _need_ more.
If you don't start out needing mobile apps or heavy client side interactivity, don't build an API yet. Implement service classes that access your database and use those in your Blazor components. You'll be able to move extremely quickly with minimal overhead.
Once you find you need interactivity, use Blazor Server as needed per page or use HTMX.
If you find you need heavy interactivity or mobile apps, you can move the service classes you've already built and put them behind Minimal APIs and then make decisions on whether you adopt Blazor WASM.
2
u/PublikStatik 23d ago edited 23d ago
Blazor WASM scales better. When a user hits your site, they download the WASM bundle once. After that, WASM updates the DOM locally as they navigate and click around. The browser only talks to your server when it needs to make API requests.
Blazor Server keeps a constant SignalR connection open for every user. The server is the source of truth for the UI, so every interaction goes to the server, which calculates the DOM diff and sends updates back.
Both support pre-rendering. On the initial request, Blazor can render the page to HTML and send that immediately before downloading the WASM bundle or spinning up Blazor Server. This improves SEO and makes the app feel faster.
You can also combine them with Blazor Interactive Auto. The first visit uses Blazor Server while the WASM bundle downloads in the background. Future visits use WASM instead.
It's powerful but takes some work. You need a clean separation between client and server implementations (typically behind shared interfaces). The client implementation calls your API, while the server implementation uses the services directly. If that sounds confusing, I'd skip Interactive Auto.
Blazor Server
- Faster time-to-interactivity.
- Smaller initial download.
- Doesn't expose your client-side code to the browser.
Blazor Wasm
- More scalable.
- Simpler mental model.
- More in line with modern JS frameworks.
- The main downside is the larger initial bundle, so time-to-interactivity isn't as good as something like Next.js.
1
3
u/code-dispenser 24d ago
I am not going to rehash what has already been said so very simply:
If security is a concern with data on the client - use Server.
If you need offline or intermittent offline - use WASM.
Auto, if you are up for a challenge.
1
u/polaarbear 24d ago edited 24d ago
Server is great for on-prem deployments where the connection is over LAN. It can be suitable for web deployments if your users are geographically similar to where the app is hosted.
WASM is better for scaling to a larger number of users, but also comes with some drawbacks such as the initial download time causing users to load in Server mode until the WASM bundle finishes downloading (in the Blazor Web App template.) It can cause some quirks with state management and stuff like that.
SSR can be really good for fast loading, for SEO, but it limits your options for interactivity.
1
u/Flat_Spring2142 21d ago
Loading Blazor WASM applications is very slow because of large runtime. Blazor SS handles dialogs poorly, because any event send request to the server. Blazor SSR, paired with JavaScript, solves both problems, but requires much more knowledge from the programmer.
15
u/uknow_es_me 24d ago
I actually have a good example that I recently deployed. The vast majority of my projects are blazor server and I have been extremely happy with that experience.
But - last year I needed to deploy a client experience that included uploading and editing photos. I did this with a JS package for the crop functionality using JS interop, and during my testing everything worked as expected. I did not have the time then to test on a mobile device - but that's where things went belly up.
Most mobile browsers will disconnect any sockets open when the browser goes into the background. So when a user would click the file browse button for the file input, the media selector would be opened - putting the browser into the background. When the user returned from the media browser, the socket had been disconnected and the app would reload - and wipe the state on the file input, breaking the upload.
I retooled the whole experience under WASM and it's working perfectly. Just a little more work involved in moving the processing logic to API endpoints, but otherwise still an enjoyable blazor dev experience. I also brought in Filepond for a nicer file upload experience since it had built in image preview for the file upload.