5 ms·

> With ASP.NET, a React/Angular project is separate, there's a separate model layer, and you have to keep that in sync with the .NET models. The separation of

> With ASP.NET, a React/Angular project is separate, there's a separate model layer, and you have to keep that in sync with the .NET models. The separation of models is indeed inevitable when there is JS on the client and not-JS on the server. That's a 'problem' common to all non-JS back-ends. However there are three points I'd make. 1. That's often a good thing, not a flaw, in that it enforces a mapping boundary between what the server and the client know and therefore strongly discourages leakage of data. 2. Mapping requirements of this type are much too trivial to base a tech stack choice on. It's barely worth considering given that mappings only need doing once and updating once per change. They are also very good protection against accidentally exposing new stuff precisely because changes in models don't automatically impact the client. 3. If this model syncing was really an issue (it usually isn't) you could try Blazor. By doing C# on the client as well as the server you get to share the same code/models. As per point 2 I don't think that's a good enough reason to switch tech stacks, but Blazor also has its place.

brushfoot 4y ago
> 1. That's often a good thing, not a flaw, in that it enforces a mapping boundary That just sounds like mandatory busywork that may or may not prevent poor programming practices. I'd rather pick a framework for productivity. > 2. Mapping requirements of this type are much too trivial to base a tech stack choice on. Trivial for large corporations with money to burn, maybe. A huge time-waster for my startup. > 3. If this model syncing was really an issue (it usually isn't) you could try Blazor. Blazor is cool, but the bundle sizes are still too large right now, and it doesn't have the ecosystem of web components that JavaScript does. Sure, you can integrate, but you're just making life more complicated for yourself. It feels like too little, too late.
- mst 4y ago
  One man's mandatory busywork is another man's separation of concerns.
- kcartlidge 4y ago
  > That just sounds like mandatory busywork that may or may not prevent poor programming practices. I'd rather pick a framework for productivity. Mandatory busywork implies stuff with no real purpose. I specifically pointed out the purpose. You may not agree with the cost/benefit involved in doing it, but that's a preference and doesn't automatically make someone else's way of working busywork. And personally I find it increases productivity by eliminating a whole range of security concerns. > Trivial for large corporations with money to burn, maybe. A huge time-waster for my startup. This largely depends upon if you accept that the work itself is of benefit. If you believe it's just busywork, then whilst my own opinion differs, your conclusion is reasonable for your situation. > Blazor is cool, but the bundle sizes are still too large right now, and it doesn't have the ecosystem of web components that JavaScript does. You're right on the sizes and the ecosystem (though that is not Blazor-specific and is something no non-JS client-side tech will ever be able to compete with). I do ASP.NET and Blazor (alongside Node, Go, Python, Rails etc) and TBH whilst personally I see great value in Blazor it feels like that's mostly for back-office or enterprise applications where you get the incredible productivity (that much is true) and don't need to worry about the sizes or, depending on how you implement it as this is optional, the need for a persistent web-socket connection.

brushfoot 4y ago

> 1. That's often a good thing, not a flaw, in that it enforces a mapping boundary That just sounds like mandatory busywork that may or may not prevent poor programming practices. I'd rather pick a framework for productivity. > 2. Mapping requirements of this type are much too trivial to base a tech stack choice on. Trivial for large corporations with money to burn, maybe. A huge time-waster for my startup. > 3. If this model syncing was really an issue (it usually isn't) you could try Blazor. Blazor is cool, but the bundle sizes are still too large right now, and it doesn't have the ecosystem of web components that JavaScript does. Sure, you can integrate, but you're just making life more complicated for yourself. It feels like too little, too late.

mst 4y ago
One man's mandatory busywork is another man's separation of concerns.
kcartlidge 4y ago
> That just sounds like mandatory busywork that may or may not prevent poor programming practices. I'd rather pick a framework for productivity. Mandatory busywork implies stuff with no real purpose. I specifically pointed out the purpose. You may not agree with the cost/benefit involved in doing it, but that's a preference and doesn't automatically make someone else's way of working busywork. And personally I find it increases productivity by eliminating a whole range of security concerns. > Trivial for large corporations with money to burn, maybe. A huge time-waster for my startup. This largely depends upon if you accept that the work itself is of benefit. If you believe it's just busywork, then whilst my own opinion differs, your conclusion is reasonable for your situation. > Blazor is cool, but the bundle sizes are still too large right now, and it doesn't have the ecosystem of web components that JavaScript does. You're right on the sizes and the ecosystem (though that is not Blazor-specific and is something no non-JS client-side tech will ever be able to compete with). I do ASP.NET and Blazor (alongside Node, Go, Python, Rails etc) and TBH whilst personally I see great value in Blazor it feels like that's mostly for back-office or enterprise applications where you get the incredible productivity (that much is true) and don't need to worry about the sizes or, depending on how you implement it as this is optional, the need for a persistent web-socket connection.