19 ms·

This is very backend-centric. It can't compare to a framework like SvelteKit or NEXT or NUXT, where the primary benefit is also shipping your tightly-integrate

by pevey 4y ago

This is very backend-centric. It can't compare to a framework like SvelteKit or NEXT or NUXT, where the primary benefit is also shipping your tightly-integrated frontend code to the browser. .NET apps are old school, full refresh apps unless you are also using a separate frontend framework like React or Vue standalone. And that adds a lot of time and overheard. Everything you described in terms of easy migrations and querying is exactly what Prisma gives you in the stack the OP described.

stetrain 4y ago
They are describing using .NET as an API providing a typed OpenAPI contract (aka swagger). Nothing about that is “full refresh” and you can use whichever frontend framework you like.
arcturus17 4y ago
> .NET apps are old school Microsoft has invested massively in modernizing .NET and C#. It is also widely praised by devs - .NET is ranked 4th most loved framework in the SO 2022 dev survey. You have built-in scaffolding to get a React + .NET app right from the CLI, with hot-reload and all the facilities you'd expect. Hardly old school at all. Personally, if I had to build a website with a thin API layer I'd reach for NextJS (or equivalent) alone, but anything beyond that I'd go for .NET Core any time of day.
brushfoot 4y ago
Exactly. 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. With Next, there's true code reuse between client and server. Next is smart about shipping your code where it needs to run, server, client, both. You can even mix and match from page to page: Server-side render one page per request; statically generate another at build time. As much as I like ASP.NET, Next has leapfrogged it for web apps.
- arcturus17 4y ago
  > As much as I like ASP.NET, Next has leapfrogged it for web apps. Look, I like NextJS as much as the next guy - I'd say it's my main working technology right now. And I've never built anything on .Net - I know its characteristics from watching tutorials and reading docs. My take however is that "web apps" is a very broad world. NextJS gives you a thin API layer. There is no model layer to speak of. You're left fending for yourself in the wild, wild world of JavaScript. .Net Core, on the other hand, offers a batteries-included, heavy-lifting, opinionated framework, with an immense toolbox and many conventions to guide you. There has to be a reason why people speak such wonders of it. If I had to build something enterprise-y with more than handful of devs it would probably be my choice.
  - bottlepalm 4y ago
    If anything the model layer in Next.js is superior because you can use the same model layer to build the page SSR, and then Next.js will gracefully transfer the entire model layer over to the client where your app can continue to work against it.
  - brushfoot 4y ago
    > I've never built anything on .Net The grass isn't greener. I've built in both - I have a .NET Core/Angular SaaS app that I created and sell, and I've been building greenfield in Next. I much prefer Next. The duplication in .NET/Angular has never been worth it...not once. And having network calls for everything is unnecessarily painful. I started the app in 2019, when RESTful SPAs were all the rage. I bought into the hype that you should have API endpoints for everything no matter what, because you'd soon have a mobile app and daemons and this and that. Turns out, YAGNI. It would've been better to server-side render and only create API endpoints when necessary. That's what I like about Next: Static generate where you can, server-side render per request where you can't, SPA where necessary - and the layers are as flat as can be. It's the best of all worlds. That being said, I've worked in .NET for ~16 years now, and I like it more than JavaScript/TypeScript. But I'd still rather develop a web app in Next and put any background services elsewhere in .NET if needed.
    - arcturus17 4y ago
- kcartlidge 4y ago
  > 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.
- stetrain 4y ago
  That sounds nice for the main user interaction, but what about when you need more heavy lifting of async tasks and side effects? Like I get a shared model being accessed "directly" for the things that the UI displays and manipulates. But once you click an Order button you have transactions to process, ledgers to update, notifications to dispatch. That kind of code doesn't float between client and server, it needs to happen once the order has been received regardless of the client state. You can offload that to other services, lambdas, etc. but that's the sort of thing that you can just do all-inclusive in a standalone backend be it Node, .NET, Go, etc.
- Double_a_92 4y ago
  If you need to create a more complex application, you still would do that as a separate API project that your NextJS application would query...
deleted 4y ago
[deleted]
CharlieDigital 4y ago
If you have .NET 6/7 installed, give this a try: dotnet new webapi -minimal dotnet run I know there's been a lot of discussion about whether .NET/C# are faster than X or Y or Z based on TechEmpower benchmarks, but this will give you a backend that looks more or less like Express with an OpenAPI schema built-in (generate TS bindings for frontend) and a runtime that is going to be higher thoughput than Express or Node. dotnet watch And you get hot reload.
- brushfoot 4y ago
  That's not what GP is talking about, though. I like the new .NET minimal APIs, but what GP is talking about is the frontend/backend _integration_ with a framework like Next.js. Next isn't really like Angular in that you don't need an API layer (though you can have one if needed). It's more like ASP.NET Core MVC. The difference is the frontend code is truly integrated with the backend. It all lives in the same project. It's just React components. You can render them statically on the server at build time, per request at runtime, or on the client. And you can mix and match. Next only ships the client the JavaScript it needs. You don't need an API unless you want SPA parts of the app. Where you do want that, it's simple to implement, because you're already in JavaScript and all your other code plays nicely with it. It's a really nice way to organize and consolidate the different pieces of web dev IMO.

by pevey 4y ago

stetrain 4y ago

They are describing using .NET as an API providing a typed OpenAPI contract (aka swagger). Nothing about that is “full refresh” and you can use whichever frontend framework you like.

arcturus17 4y ago

> .NET apps are old school Microsoft has invested massively in modernizing .NET and C#. It is also widely praised by devs - .NET is ranked 4th most loved framework in the SO 2022 dev survey. You have built-in scaffolding to get a React + .NET app right from the CLI, with hot-reload and all the facilities you'd expect. Hardly old school at all. Personally, if I had to build a website with a thin API layer I'd reach for NextJS (or equivalent) alone, but anything beyond that I'd go for .NET Core any time of day.

brushfoot 4y ago

Exactly. 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. With Next, there's true code reuse between client and server. Next is smart about shipping your code where it needs to run, server, client, both. You can even mix and match from page to page: Server-side render one page per request; statically generate another at build time. As much as I like ASP.NET, Next has leapfrogged it for web apps.

arcturus17 4y ago
> As much as I like ASP.NET, Next has leapfrogged it for web apps. Look, I like NextJS as much as the next guy - I'd say it's my main working technology right now. And I've never built anything on .Net - I know its characteristics from watching tutorials and reading docs. My take however is that "web apps" is a very broad world. NextJS gives you a thin API layer. There is no model layer to speak of. You're left fending for yourself in the wild, wild world of JavaScript. .Net Core, on the other hand, offers a batteries-included, heavy-lifting, opinionated framework, with an immense toolbox and many conventions to guide you. There has to be a reason why people speak such wonders of it. If I had to build something enterprise-y with more than handful of devs it would probably be my choice.
- bottlepalm 4y ago
  If anything the model layer in Next.js is superior because you can use the same model layer to build the page SSR, and then Next.js will gracefully transfer the entire model layer over to the client where your app can continue to work against it.
- brushfoot 4y ago
  > I've never built anything on .Net The grass isn't greener. I've built in both - I have a .NET Core/Angular SaaS app that I created and sell, and I've been building greenfield in Next. I much prefer Next. The duplication in .NET/Angular has never been worth it...not once. And having network calls for everything is unnecessarily painful. I started the app in 2019, when RESTful SPAs were all the rage. I bought into the hype that you should have API endpoints for everything no matter what, because you'd soon have a mobile app and daemons and this and that. Turns out, YAGNI. It would've been better to server-side render and only create API endpoints when necessary. That's what I like about Next: Static generate where you can, server-side render per request where you can't, SPA where necessary - and the layers are as flat as can be. It's the best of all worlds. That being said, I've worked in .NET for ~16 years now, and I like it more than JavaScript/TypeScript. But I'd still rather develop a web app in Next and put any background services elsewhere in .NET if needed.
  - arcturus17 4y ago
kcartlidge 4y ago
> 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.
stetrain 4y ago
That sounds nice for the main user interaction, but what about when you need more heavy lifting of async tasks and side effects? Like I get a shared model being accessed "directly" for the things that the UI displays and manipulates. But once you click an Order button you have transactions to process, ledgers to update, notifications to dispatch. That kind of code doesn't float between client and server, it needs to happen once the order has been received regardless of the client state. You can offload that to other services, lambdas, etc. but that's the sort of thing that you can just do all-inclusive in a standalone backend be it Node, .NET, Go, etc.
Double_a_92 4y ago
If you need to create a more complex application, you still would do that as a separate API project that your NextJS application would query...

deleted 4y ago

[deleted]

CharlieDigital 4y ago

If you have .NET 6/7 installed, give this a try: dotnet new webapi -minimal dotnet run I know there's been a lot of discussion about whether .NET/C# are faster than X or Y or Z based on TechEmpower benchmarks, but this will give you a backend that looks more or less like Express with an OpenAPI schema built-in (generate TS bindings for frontend) and a runtime that is going to be higher thoughput than Express or Node. dotnet watch And you get hot reload.

brushfoot 4y ago
That's not what GP is talking about, though. I like the new .NET minimal APIs, but what GP is talking about is the frontend/backend _integration_ with a framework like Next.js. Next isn't really like Angular in that you don't need an API layer (though you can have one if needed). It's more like ASP.NET Core MVC. The difference is the frontend code is truly integrated with the backend. It all lives in the same project. It's just React components. You can render them statically on the server at build time, per request at runtime, or on the client. And you can mix and match. Next only ships the client the JavaScript it needs. You don't need an API unless you want SPA parts of the app. Where you do want that, it's simple to implement, because you're already in JavaScript and all your other code plays nicely with it. It's a really nice way to organize and consolidate the different pieces of web dev IMO.