3 ms·

The fact that you have to interface between different teams/languages is often a big part of the slowdown. The productivity improvements are real. Not having t

The fact that you have to interface between different teams/languages is often a big part of the slowdown. The productivity improvements are real. Not having to design and expose an API for the frontend and instead just reuse the same classes and services is a massive shortcut. Running Blazor on the server is even easier because there's no serialization at all and you can directly call database queries in response to UI events. I suggest watching some of the Blazor presentations to see just how much complexity can be built in minutes compared to more traditional frontend frameworks: https://www.youtube.com/watch?v=CEjqhTGrqDY https://www.youtube.com/watch?v=CEjqhTGrqDY

nirav72 6y ago
Isn't load balancing still an issue with server side blazor? Because of SignalR for the delta between server and client?
- manigandham 6y ago
  Yes. A single-server can scale to thousands of concurrent users however it's not recommend for massive public sites. Works great for admin backends though where the usage is known.
cjblomqvist 6y ago
Then why didn't Meteor take off fully? Because that was the promise of universal JS, about 10 years ago...
- lgessler 6y ago
  Meteor's problems were around performance and features (or the lack of them) IMO, which are not in principle ones that will crop up if you try to unite a stack around a single language.
- manigandham 6y ago
  Javascript is still struggling to be fully capable server-side today, let alone 10 years ago. Going in reverse is much more functional.
dragonwriter 6y ago
> The fact that you have to interface between different teams/languages is often a big part of the slowdown Different teams is a business organization problem, and if you have that problem, you just aren’t going to choose the kind of server-side-code-with-generated-frontend framework that Blazor is (and of which there are several besides Blazor), so it doesn’t solve any problem there. Different languages without different teams is a much smaller problem.

nirav72 6y ago

Isn't load balancing still an issue with server side blazor? Because of SignalR for the delta between server and client?

manigandham 6y ago
Yes. A single-server can scale to thousands of concurrent users however it's not recommend for massive public sites. Works great for admin backends though where the usage is known.

cjblomqvist 6y ago

Then why didn't Meteor take off fully? Because that was the promise of universal JS, about 10 years ago...

lgessler 6y ago
Meteor's problems were around performance and features (or the lack of them) IMO, which are not in principle ones that will crop up if you try to unite a stack around a single language.
manigandham 6y ago
Javascript is still struggling to be fully capable server-side today, let alone 10 years ago. Going in reverse is much more functional.

dragonwriter 6y ago

> The fact that you have to interface between different teams/languages is often a big part of the slowdown Different teams is a business organization problem, and if you have that problem, you just aren’t going to choose the kind of server-side-code-with-generated-frontend framework that Blazor is (and of which there are several besides Blazor), so it doesn’t solve any problem there. Different languages without different teams is a much smaller problem.