3 ms·

> I have been able to implement things in 4 hours that would easily have taken 4 weeks if I had to argue with other developers about the shape of a JSON blob on

> I have been able to implement things in 4 hours that would easily have taken 4 weeks if I had to argue with other developers about the shape of a JSON blob on the wire. I can’t comment on your specific circumstances because I don’t know the details, but this reads like someone who is drinking the blazer coolaid. It’s a technology like any other, with specific trade offs. If you have a front end team who lacks the basic competence to do something that takes four hours in blazor in less than 4 weeks, then maybe it’s a good trade off. ...but in most cases, for most people, that won’t be the case. It’s also quite slow, hard to integrate with existing js technology (ie bridge) and very difficult to debug production issues with in my experience.

ithrow 6y ago
I haven't use Blazor but they mentioning about avoiding the json API with all the encoding/deconding that entails sounds nice, plus only doing routing in the backend. These frameworks (liveview, blazor, hotwire, etc...) seem like a nice compromise that can serve well most webapps out there.
manigandham 6y ago
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.
bob1029 6y ago
The entire point is to avoid javascript as much as possible and to force the few edge cases into an interop shim. We have a very complex Blazor webapp and the JS interop shim is fewer than 200 lines of code. This is 100% of the custom javascript for the entire application. Front and back. We do things like GetClientRect, Get/Set/Delete cookies, keyboard/mouse event subscription, etc. There is little-to-no context switching when operating with one of these codebases. The notion of "front-end" and "back-end" is completely meaningless here. The "back-end" is literally an F12 keystroke away from the "front-end". > and very difficult to debug production issues with in my experience What sort of production issues have you been encountering that were difficult to track down? I rather enjoy being able to set breakpoints in my view templates to confirm the state of affairs in local testing.
- mumblemumble 6y ago
  > The notion of "front-end" and "back-end" is completely meaningless here. So to start with, a disclaimer: I carry some baggage here, from working occasionally on 10+ year old GWT app that's developed into quite a tangled mess. Having said that -- this sort of thing doesn't seem like an obvious win to me. The notion of "front end" and "back end" represents a real-world distinction that you want to pay attention to. Making it too hard to see, or too easy to communicate across, brings some risk of losing track of which is which, and putting logic that belongs on the server into the client or vice versa. Or having the two communicate with each other much too often, which may not cause any noticeable problems during development, but, in production, can cripple the site for users with higher-latency Internet connections.
  - sk5t 6y ago
    Ditto, I've no desire at all for web applications--or heaven forbid clients--to poke directly at a database or cache, or otherwise obviate the need for APIs. One will need to deploy, scale, monitor, and secure those things very differently from one another.
    - bob1029 6y ago
      We use SQLite for storage of all things. The entire application lives on a single machine. OurApp.exe: SQLite <-> C# Services <-> Razor Components When you have a stack like this, Blazor goes into additional dimensions of productive. Every F5 of the app is a complete stack running without any frustration in setting up databases, containers, message buses, etc. None of the concerns regarding scalability apply when you plan to go vertical. I would not currently argue for developing blazor server apps as a replacement for 100% of web applications. But, there are situations where you have a constrained user base and predictable performance characteristics which provides enough confidence to go all-in on a single fast box.

ithrow 6y ago

I haven't use Blazor but they mentioning about avoiding the json API with all the encoding/deconding that entails sounds nice, plus only doing routing in the backend. These frameworks (liveview, blazor, hotwire, etc...) seem like a nice compromise that can serve well most webapps out there.

manigandham 6y ago

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.

bob1029 6y ago

The entire point is to avoid javascript as much as possible and to force the few edge cases into an interop shim. We have a very complex Blazor webapp and the JS interop shim is fewer than 200 lines of code. This is 100% of the custom javascript for the entire application. Front and back. We do things like GetClientRect, Get/Set/Delete cookies, keyboard/mouse event subscription, etc. There is little-to-no context switching when operating with one of these codebases. The notion of "front-end" and "back-end" is completely meaningless here. The "back-end" is literally an F12 keystroke away from the "front-end". > and very difficult to debug production issues with in my experience What sort of production issues have you been encountering that were difficult to track down? I rather enjoy being able to set breakpoints in my view templates to confirm the state of affairs in local testing.

mumblemumble 6y ago
> The notion of "front-end" and "back-end" is completely meaningless here. So to start with, a disclaimer: I carry some baggage here, from working occasionally on 10+ year old GWT app that's developed into quite a tangled mess. Having said that -- this sort of thing doesn't seem like an obvious win to me. The notion of "front end" and "back end" represents a real-world distinction that you want to pay attention to. Making it too hard to see, or too easy to communicate across, brings some risk of losing track of which is which, and putting logic that belongs on the server into the client or vice versa. Or having the two communicate with each other much too often, which may not cause any noticeable problems during development, but, in production, can cripple the site for users with higher-latency Internet connections.
- sk5t 6y ago
  Ditto, I've no desire at all for web applications--or heaven forbid clients--to poke directly at a database or cache, or otherwise obviate the need for APIs. One will need to deploy, scale, monitor, and secure those things very differently from one another.
  - bob1029 6y ago
    We use SQLite for storage of all things. The entire application lives on a single machine. OurApp.exe: SQLite <-> C# Services <-> Razor Components When you have a stack like this, Blazor goes into additional dimensions of productive. Every F5 of the app is a complete stack running without any frustration in setting up databases, containers, message buses, etc. None of the concerns regarding scalability apply when you plan to go vertical. I would not currently argue for developing blazor server apps as a replacement for 100% of web applications. But, there are situations where you have a constrained user base and predictable performance characteristics which provides enough confidence to go all-in on a single fast box.