12 ms·

All the dis-advantages are not relevant for enterprise LOB apps, which Blazor is best suited for. Millions of .NET developers across the enterprise world are h

All the dis-advantages are not relevant for enterprise LOB apps, which Blazor is best suited for. Millions of .NET developers across the enterprise world are heaving a sigh of relief to never have to touch JS and be cozy and comfortable in their .NET ecosystem. With the latest addition of fully SSR, Blazor is also well suited for CMS, Blogs, Content Mills, small web apps, portfolio sites, etc. But, as a developer who has done exactly one complex web app for a client, let me tell you, the ability to use C# models, directly from your domain, in web app markup code, using Razor components is a god send. I don't have to maintain the cognitive overhead of translating domain models into JSON models and vice versa.

louthy 3y ago
It's still relevant when MS decide to drop it and focus on yet another new shiny web-framework, like the 10 - or whatever number previous they've built - in the past 20 years. And, let's face it, they're not very good at it. If they were they wouldn't need to shelve so many previous attempts. Or, they decide to completely upend the entire ecosystem (Framework → Core) which then makes all previous web-frameworks (built by them) defunct. Enterprises with sense would either roll their own, that they can then have complete control of forever, or try and find a framework that has staying power (although I realise even that is difficult). I think running C# in the browser has benefits, for sure, but they should just stick to making that. And get out of the web-framework game for good to allow the community to create something exceptional - and, you know, play nice with others (other frameworks).
- kumarvvr 3y ago
  When it comes to web, MS has been focused on ASP.NET since forever. With evolution of the web, ASP.NET too has evolved quite a bit. Building a simple web app with Razor pages is incredibly easy and the output is fast and scalable. Their WebAPI in ASP.NET is very good. Blazor is an additional way to do web apps, but very much in line with the structure and core of ASP.NET. In the desktop world, MS has jumped a lot of hoops, mostly because there is no one to chide them on their own platform. But the web is different.
  - louthy 3y ago
    > When it comes to web, MS has been focused on ASP.NET since forever. What's your definition of 'forever'? Are you talking about ASP, or ASP.NET, or ASP.NET Core? Or, Web Forms, MVC1, MVC2, MVC3, Silverlight, 'minimal APIs'? ... Honestly, it's just one clusterfuck after another. --- EDIT: There's a number of sub-comments here that seem to be missing the point. So, I'll expand here: * For those who are questioning my right to have an opinion on this and doubting my expertise: I have used .NET since version 1. I founded a company in 2004 and have been responsible for building an enormous web-app product in the .NET world (since before jquery era, basically). I've seen all these frameworks come and go. * For those who are saying "whatabout JS". Am I not allowed to have an opinion on the ever changing landscape of .NET web-app development without first criticising the 1000s of open-source developments? * For those saying they've done migrations in the past. I'm pleased for you. Now try it with an application of over 500 pages when you have other things to be getting on with. Especially if you're not eager to jump to the latest and greatest every time a new one comes out, then you have a big problem of jumping multiple steps. Or, especially when they rip the entire ecosystem away (.NET Framework → .NET Core) meaning a big fix-up job for those migrating. I'd love to know what the collective economic impact of MS changing their minds every few years is. But, finally, this is not about migration per se. This is about the poor quality of the frameworks themselves. Microsoft just follow the latest trends once they get going and then build half-assed versions that try to completely lock you into their world. They try to destroy everything that is the web so they can stop you leaving their ecosystem. This has profound problems for the consumer of these frameworks when MS drop it and go after something else. The Minimal APIs is a good example of bandwagon jumping, they've seen the trends to more functional-style APIs, and then they go and implement it in a horrible half-functional/half-OO ugly way. There are so many gaps in it due to its design that it's already obvious that it won't last (in its current form at least). In 'JS land' it may not be the prettiest of ecosystems to work with, but JS written 20 years ago will probably still run today. Frameworks written 20 years ago can still be used. Support may go away, but that doesn't precipitate a rewriting of your UI layer. Anyone developing software for the long-term, which is professional software houses, should be wary of relying on anything MS build (outside of the language itself and its tooling, which is excellent). Personally, I'd never bet the house on a MS web framework again. We ended up rolling our own, which was much more advanced than most web-frameworks (at the time) and stayed written (well, until .NET Core came along!).
- codegeek 3y ago
  " yet another new shiny web-framework" Funny you say that. JS..cough..JS.
LaGrange 3y ago
> All the dis-advantages are not relevant for enterprise LOB apps, which Blazor is best suited for. The disadvantages: the _actual user_ is going to have a horrible time with the application. It will load slowly, work slowly, probably break the moment you inevitably will have to touch JS, and if the browser the user hates anyway is out of sync with the forced updates, the entire thing will blow up. But enterprise LOB don't care. > I don't have to maintain the cognitive overhead of translating domain models into JSON models and vice versa. Every single time I've seen this attitude, it turned out that actually it just meant you're going to have a worse time when you inevitably had to do that translating. Java web applets aren't new. "Using models directly from the domain" is not new. Even when the runtime is friendly, the latter is a bad idea.
- brtkdotse 3y ago
  > It will load slowly, work slowly Why do you think this will be the case?
  - Capricorn2481 3y ago
    Well for Blazor Webassembly at least, you need to download the entire .NET runtime and WebAssembly isn't quite as fast as JS in browsers yet. Couple that with the fact that interoping with JS can be a lot more annoying than just using JS
    - brtkdotse 3y ago
      > Well for Blazor Webassembly at least, you need to download the entire .NET runtime It's a one-time download that's smaller than the initial load of the Facebook feed
      - littlecranky67 3y ago
        plus in LOB apps very likely to be in the browsers cache already. And dont forget buisness workstations are usually connected via at least 1GBit Ethernet.
brtkdotse 3y ago
> I don't have to maintain the cognitive overhead of translating domain models into JSON models and vice versa. I’m more happy about not having to maintain working knowledge of two sets of IDEs, build tools, CI/CD pipelines, hosting models and testing framework and conventions.
codegeek 3y ago
For me, just the fact that I don't have to deal with JS bullshit and ecosystem including node/npm hellhole is a win for me. Before these shiny JS frameworks came along, .NET already had great UI component libraries as well including syncfusion (my favorite) and many others. I only do VueJS when I do use JS but man I can't wait to not write any code in JS.
- mdasen 3y ago
  Yea, I've been using Blazor in .NET 8 through the previews and it's really nice. The Server Side Rendering is fast like any server-rendered stuff. Enhanced Navigation means that pages load even faster since they're just using `fetch` to get the next page and swapping the content (like Turbo in Rails). When I need some interactivity, the page still renders from the server and then the browser downloads the WASM in the background. With .NET 8, Blazor is really ready. It isn't perfect, but it's so productive for me and the downsides are really minimal. Plus, it'll likely get a lot better with .NET 9 in a year because of WASM-GC (and post-MVP improvements to WASM-GC). With WASM-GC, .NET won't need to ship a garbage collector and WASM-based stuff won't need to copy between WASM and JS for DOM manipulations. Since people might want the "minimal" downsides, I'll put them here. If you're using Blazor SSR with WASM, after the first interactive page renders for the first time, there's a second or two before the interactivity is actually available while it downloads the WASM (on interactive components, not links or anything). If you were making a Facebook clone, it'd mean that the "like" button on posts wouldn't work for a second or two. This is pretty minimal for two reasons. First, it's just the first page load of the first interactive page. After that, the WASM is cached in the browser. Second, most of the time people need a few seconds to read the content before using an interactive bit. All of the navigation and such works instantly, but an interactive bit like a "like" button takes a second or two. If you want to get rid of that, you can use interactive-auto. This means that the first interactive page load will use a web socket and the interactive bits will be done with Blazor Server. It'll download the WASM in the background and switch to WASM for future page loads so you don't need the web socket for the vast majority of your stuff. However, web sockets do create a certain amount of hassle since you need to make sure that any proxies in-between handle web sockets and that you consistently route the user to the correct backend if you're load balancing. To me, those downsides are minimal and don't have a lot of user impact for me. This is in contrast with Blazor in .NET 7 where I'd have to choose using a web socket all the time or having a big WASM payload that meant the page didn't render for a few seconds and gave users a crappy experience. If you're primarily creating something that would be server-rendered (like Rails or Django), Blazor offers that with the additional nicety that you can add interactive elements without needing to deal with JS. That isn't meant as a "JS is crappy" comment, but to note that having to deal with another ecosystem where you need to duplicate your models and keep them in sync, having to deal with another build system or glue things together yourself, etc. is a pain when it isn't your main focus. So many sites end up with a full front-end stack and all the hassle involved because they need a couple pages or want to keep a consistent component system. Blazor means that you don't have to go that route.
osigurdson 3y ago
The problem is, all of this stuff will probably be dead in a few years. I think they would be better off working within established paradigms rather than trying to do something completely new. How about, for example, making it as easy as possible to use React with a C# backend?
- pier25 3y ago
  React will die too, eventually. Or at least stop becoming the default.
  - osigurdson 3y ago
    Agree, but a dying star creates new life and pathways from old to new. A dying snowflake, just evaporates.
    - seti0Cha 3y ago
      I used to be a frontend coder, but am no longer. In part this is because I couldn't bring myself to keep up with the constant ecosystem churn of the JS world. I recently worked at a company that was trying to migrate from Vue 2 to Vue 3. It was not going quickly. Is Vue going to even be around in a few years, or will React eat it entirely? Or will react itself be eaten by Svelte? I have no idea, I'm not involved in these things. But after watching how such things play out for a couple of decades, my conclusion is that if you are building for the web, you should use whatever you are comfortable with and what provides the features you want now, because there's no way to know what things will look like a few years down the road. Even if the framework you chose sticks around, you may end up doing a rewrite because of other concerns or throw the whole thing away altogether.
  - Someone1234 3y ago
    Let's say it does: It leaves behind a WebAPI backend that [new hotness] can utilize. WebAPI is an agnostic protocol. What does Blazor leave behind? Nothing reusable at all. It is a proprietary server hosting proprietary connections via proprietary pipeline. Plus sometimes inscrutable WebAssembly. Just go ask all the companies STILL stuck on Web Forms or Silverlight how that worked out for them the last times? Exactly. Friends don't let friends buy into proprietary backends that muddy the water between UI/API layers. Stick to WebAPI and put whatever you want in front. That way you can migrate either front OR back independently of one another (and or do piecemeal migrations). PS - This has nothing to do with "Microsoft bad." This has to do with standard protocols between front/back Vs bespoke stuff. I'd also criticize the short-sightedness if another company offered the same thing.
george_sp 3y ago
I feel like your comment touched a million different places so I'll try to compose my arguments in a compact manner, hopefully to make some sense. > All the dis-advantages are not relevant for enterprise LOB apps, which Blazor is best suited for. Where does this conclusion come from? At least from my humble experience,I've been doing them for ~10 years with various tools, both JS and Blazor/Razor Pages and the fact that they "work" does not mean they stand on solid ground. I've written apps in Blazor, yet I don't understand its existence. Most apps, even LOB as you said, Razor Pages are more than enough. Razor Pages are amazing. What seems to me to be the source of the problem is the whole mentality: > But, as a developer who has done exactly one complex web app for a client, let me tell you, the ability to use C# models, directly from your domain, in web app markup code, using Razor components is a god send... You can ship server side generated HTML with Razor and just LEARN a bit of JS. I don't understand the allergy of the so called "back end" developers with JS. Yes it's shitty. Yes it feels better writing C#. I also like my bike more than my car. Will I take my bike to drive 500km? No. There's a time and place for everything. I feel efforts like Blazor just fight against the (unfortunate yet inevitable) current that JS is the only language that can manipulate DOM. I really think all of us should be open to use whatever makes sense for the job, even if it occasionally makes us feel uncomfortable. This is the dev community I want to be a part of.
- gedy 3y ago
  > I don't understand the allergy of the so called "back end" developers with JS I think what many people are complaining about is that they actually dislike UI development and all the ambiguity and complexity. "JS" just catches blame for this. Modern JS and esp. TypeScript are pretty good languages, or at least comparable. A lot of these server side UI toolkits avoid some of the complexity by supporting basic UIs and flows, e.g. List/Show/Edit (which is fine in many cases), but to do complex UIs that many modern apps need, it's a huge pain. Worse situation to dev is forcing 80% of the functionality via server side, then the last 20% you ask "front end" to wedge in with jQuery style development.
  - uticus 3y ago
    As someone who suffers from this allergy, I'll chime in with 2 additional thoughts: It's not just that UI development is more ambiguous, it is the fact that it is difficult to make text-based code fit it. This is doubly (or maybe logarithmicaly) so when responsive (same code fit different screens). HTML, XAML, HAML, etc all require a lot of code. Reusability mechanisms (like components, etc) help this but it is a world of difference from what BE devs are comfortable with. Thought #2: I'd guess BE devs like to just code, and the FE frameworks have a reputation of getting in the way of that. This is a less certain thought, so welcome opposition, but seems at least like part of the emotional reaction a BE dev would have to FE work.
JackMorgan 3y ago
I use swashbuckle and swagger-typescript-api to automatically scrape my controllers and generate API calls and TS types every time I rebuild. No hassle or overhead at all. No need for converters or anything. I've been using this now for several projects, it's a great way to have all the power of TS for client side and C# for server side. https://www.npmjs.com/package/swagger-typescript-api https://www.npmjs.com/package/swagger-typescript-api https://www.nuget.org/packages/Swashbuckle https://www.nuget.org/packages/Swashbuckle
- CharlieDigital 3y ago
  I do the same. I have a small write-up here: https://chrlschn.dev/blog/2023/10/end-to-end-type-safety-with-dotnet7-webapis-typescript-openapi/ https://chrlschn.dev/blog/2023/10/end-to-end-type-safety-wit... You get end-to-end type safety (even better once you connect it to EF Core since you get it all ways to your DB). With this setup with hot-reload (currently broken in .NET 8 [0]), productivity is really, really good. Like tRPC but with one of the most powerful ORMs out there right now. [0] https://github.com/dotnet/sdk/issues/36918 https://github.com/dotnet/sdk/issues/36918
- aerhardt 3y ago
  I do the same in Django with drf-spectacular. I have a precommit hook that autogenerates (fairly thin) TypeScript schemas and routes on commit. This is not take merit from LOB devs who want to use C# back-to-front. I will use it as an argument to those who say that this is why you should go full TypeScript on any new web project though.
- switch007 3y ago
  N.B. the last commit/release for Swashbuckle was Jan this year. https://github.com/RicoSuter/NSwag https://github.com/RicoSuter/NSwag might be a better choice for a new project. It look much more maintained and active than Swashbuckle
  - dustymcp 3y ago
    yeah nswag has been pretty consistent i can recommend aswell.
SantiagoElf 3y ago
BBBBBBBBBBBBBBINGOOOOOOOOOOOOOOOOOO! Yes, at the end of the day, businesses use software in LOB apps. Period. Get shit done. WebForms/ASP.NET MVC/.NET Core MVC/Blazor will outlive ANY js framework.
- uticus 3y ago
  Agreed. I mean really in the spirit of get er done the AS400 is the pinnacle of UI for these sorts of things. I've worked with other things, even WinForm apps, Access things, Excel sheets that were turned into portable apps, and of course web pages. Green screen allowed 99% of things to get done faster with 1000% less fuss. https://en.wikipedia.org/wiki/Computer_terminal https://en.wikipedia.org/wiki/Computer_terminal
  - yCombLinks 3y ago
    My first job required maintaining a very old informix 4gl app. The trained users could fly in that thing! Seeing clunky webapps with a bunch of clunky laggy UI components doesn't seem worth it for trained internal users
    - uticus 3y ago
      At my old job non-technical people would navigate about as well as they would with a mouse and a graphical-based interface, because the graphical interface didn't provide any additional value. For those people it took the same time whether read instructions and press key or read instructions and click button. Trained people were definitely faster, and often the user would type ahead of the terminal (with no ill effects) because they were inputting data close to their speed of thought about the process [0]. The point is, for this situation a text-based terminal offered no downsides and many benefits compared to a graphical UI. I suspect the same is true for a lot of other business solutions. I've heard it argued before that graphical systems are easier to use, but in my day-to-day experience in the trenches with others who actually used the systems this argument was simply not true. I've also seen it hinted that graphical systems seemed more modern, so they got less emotional disdain. That rings more true to me. And really if I were in charge of such things I would acknowledge emotional disdain - even misplaced - may well count for something in the overall business picture. Also, and maybe most importantly, if the green screen needed a new feature or bugfix, there was one person at corporate that would do that. They had about a half dozen devs working on other things but she was the go-to for the green screen features. So I imagine it's harder to hire people for those sorts of systems nowadays. However it was also interesting for me to note that one person didn't seem stressed out or overly busy and the system never had a major crash or bugfix. So, tradeoffs. [0] The terminal was actually hosted inside a wrapper app inside Windows 7. So I ended up using AutoHotKey to great effect to get even more efficiency gains. * edit: added footnote explaining how AutoHotKey could be talked about in same breath as green-screen dumb terminals.
skrowl 3y ago
[dead]
_5hxt 3y ago
This may help if you'd like to keep front and backend(s) separated: https://quicktype.io/ https://quicktype.io/
yread 3y ago
I consider myself more of a backend person but I feel I can deal with JS much easier than CSS. I learnt both in 15 yrs ago so compatibility with IE was crucial. Slap jquery on, stick to style guidelines so that variables are named consistently, avoid dependencies and it feels okish. There isn't anything like that to help with CSS though.
- renegade-otter 3y ago
  As a backend dev primarily, learning CSS Grid really helped me filter out a lot of the BS. It's a UI framework that is 20 years too late, and with "lean" JS frameworks that are emerging, a lot of this UI development legacy can die a horrible death as far as I am concerned.
zerr 3y ago
So is it like ASP.NET WebForms?
- abrookewood 3y ago
  More like Elixir/Phoenix's Live View I would think.

louthy 3y ago

It's still relevant when MS decide to drop it and focus on yet another new shiny web-framework, like the 10 - or whatever number previous they've built - in the past 20 years. And, let's face it, they're not very good at it. If they were they wouldn't need to shelve so many previous attempts. Or, they decide to completely upend the entire ecosystem (Framework → Core) which then makes all previous web-frameworks (built by them) defunct. Enterprises with sense would either roll their own, that they can then have complete control of forever, or try and find a framework that has staying power (although I realise even that is difficult). I think running C# in the browser has benefits, for sure, but they should just stick to making that. And get out of the web-framework game for good to allow the community to create something exceptional - and, you know, play nice with others (other frameworks).

kumarvvr 3y ago
When it comes to web, MS has been focused on ASP.NET since forever. With evolution of the web, ASP.NET too has evolved quite a bit. Building a simple web app with Razor pages is incredibly easy and the output is fast and scalable. Their WebAPI in ASP.NET is very good. Blazor is an additional way to do web apps, but very much in line with the structure and core of ASP.NET. In the desktop world, MS has jumped a lot of hoops, mostly because there is no one to chide them on their own platform. But the web is different.
- louthy 3y ago
  > When it comes to web, MS has been focused on ASP.NET since forever. What's your definition of 'forever'? Are you talking about ASP, or ASP.NET, or ASP.NET Core? Or, Web Forms, MVC1, MVC2, MVC3, Silverlight, 'minimal APIs'? ... Honestly, it's just one clusterfuck after another. --- EDIT: There's a number of sub-comments here that seem to be missing the point. So, I'll expand here: * For those who are questioning my right to have an opinion on this and doubting my expertise: I have used .NET since version 1. I founded a company in 2004 and have been responsible for building an enormous web-app product in the .NET world (since before jquery era, basically). I've seen all these frameworks come and go. * For those who are saying "whatabout JS". Am I not allowed to have an opinion on the ever changing landscape of .NET web-app development without first criticising the 1000s of open-source developments? * For those saying they've done migrations in the past. I'm pleased for you. Now try it with an application of over 500 pages when you have other things to be getting on with. Especially if you're not eager to jump to the latest and greatest every time a new one comes out, then you have a big problem of jumping multiple steps. Or, especially when they rip the entire ecosystem away (.NET Framework → .NET Core) meaning a big fix-up job for those migrating. I'd love to know what the collective economic impact of MS changing their minds every few years is. But, finally, this is not about migration per se. This is about the poor quality of the frameworks themselves. Microsoft just follow the latest trends once they get going and then build half-assed versions that try to completely lock you into their world. They try to destroy everything that is the web so they can stop you leaving their ecosystem. This has profound problems for the consumer of these frameworks when MS drop it and go after something else. The Minimal APIs is a good example of bandwagon jumping, they've seen the trends to more functional-style APIs, and then they go and implement it in a horrible half-functional/half-OO ugly way. There are so many gaps in it due to its design that it's already obvious that it won't last (in its current form at least). In 'JS land' it may not be the prettiest of ecosystems to work with, but JS written 20 years ago will probably still run today. Frameworks written 20 years ago can still be used. Support may go away, but that doesn't precipitate a rewriting of your UI layer. Anyone developing software for the long-term, which is professional software houses, should be wary of relying on anything MS build (outside of the language itself and its tooling, which is excellent). Personally, I'd never bet the house on a MS web framework again. We ended up rolling our own, which was much more advanced than most web-frameworks (at the time) and stayed written (well, until .NET Core came along!).
codegeek 3y ago
" yet another new shiny web-framework" Funny you say that. JS..cough..JS.

LaGrange 3y ago

> All the dis-advantages are not relevant for enterprise LOB apps, which Blazor is best suited for. The disadvantages: the _actual user_ is going to have a horrible time with the application. It will load slowly, work slowly, probably break the moment you inevitably will have to touch JS, and if the browser the user hates anyway is out of sync with the forced updates, the entire thing will blow up. But enterprise LOB don't care. > I don't have to maintain the cognitive overhead of translating domain models into JSON models and vice versa. Every single time I've seen this attitude, it turned out that actually it just meant you're going to have a worse time when you inevitably had to do that translating. Java web applets aren't new. "Using models directly from the domain" is not new. Even when the runtime is friendly, the latter is a bad idea.

brtkdotse 3y ago
> It will load slowly, work slowly Why do you think this will be the case?
- Capricorn2481 3y ago
  Well for Blazor Webassembly at least, you need to download the entire .NET runtime and WebAssembly isn't quite as fast as JS in browsers yet. Couple that with the fact that interoping with JS can be a lot more annoying than just using JS
  - brtkdotse 3y ago
    > Well for Blazor Webassembly at least, you need to download the entire .NET runtime It's a one-time download that's smaller than the initial load of the Facebook feed
    - littlecranky67 3y ago
      plus in LOB apps very likely to be in the browsers cache already. And dont forget buisness workstations are usually connected via at least 1GBit Ethernet.

brtkdotse 3y ago

> I don't have to maintain the cognitive overhead of translating domain models into JSON models and vice versa. I’m more happy about not having to maintain working knowledge of two sets of IDEs, build tools, CI/CD pipelines, hosting models and testing framework and conventions.

codegeek 3y ago

For me, just the fact that I don't have to deal with JS bullshit and ecosystem including node/npm hellhole is a win for me. Before these shiny JS frameworks came along, .NET already had great UI component libraries as well including syncfusion (my favorite) and many others. I only do VueJS when I do use JS but man I can't wait to not write any code in JS.

mdasen 3y ago
Yea, I've been using Blazor in .NET 8 through the previews and it's really nice. The Server Side Rendering is fast like any server-rendered stuff. Enhanced Navigation means that pages load even faster since they're just using `fetch` to get the next page and swapping the content (like Turbo in Rails). When I need some interactivity, the page still renders from the server and then the browser downloads the WASM in the background. With .NET 8, Blazor is really ready. It isn't perfect, but it's so productive for me and the downsides are really minimal. Plus, it'll likely get a lot better with .NET 9 in a year because of WASM-GC (and post-MVP improvements to WASM-GC). With WASM-GC, .NET won't need to ship a garbage collector and WASM-based stuff won't need to copy between WASM and JS for DOM manipulations. Since people might want the "minimal" downsides, I'll put them here. If you're using Blazor SSR with WASM, after the first interactive page renders for the first time, there's a second or two before the interactivity is actually available while it downloads the WASM (on interactive components, not links or anything). If you were making a Facebook clone, it'd mean that the "like" button on posts wouldn't work for a second or two. This is pretty minimal for two reasons. First, it's just the first page load of the first interactive page. After that, the WASM is cached in the browser. Second, most of the time people need a few seconds to read the content before using an interactive bit. All of the navigation and such works instantly, but an interactive bit like a "like" button takes a second or two. If you want to get rid of that, you can use interactive-auto. This means that the first interactive page load will use a web socket and the interactive bits will be done with Blazor Server. It'll download the WASM in the background and switch to WASM for future page loads so you don't need the web socket for the vast majority of your stuff. However, web sockets do create a certain amount of hassle since you need to make sure that any proxies in-between handle web sockets and that you consistently route the user to the correct backend if you're load balancing. To me, those downsides are minimal and don't have a lot of user impact for me. This is in contrast with Blazor in .NET 7 where I'd have to choose using a web socket all the time or having a big WASM payload that meant the page didn't render for a few seconds and gave users a crappy experience. If you're primarily creating something that would be server-rendered (like Rails or Django), Blazor offers that with the additional nicety that you can add interactive elements without needing to deal with JS. That isn't meant as a "JS is crappy" comment, but to note that having to deal with another ecosystem where you need to duplicate your models and keep them in sync, having to deal with another build system or glue things together yourself, etc. is a pain when it isn't your main focus. So many sites end up with a full front-end stack and all the hassle involved because they need a couple pages or want to keep a consistent component system. Blazor means that you don't have to go that route.

osigurdson 3y ago

The problem is, all of this stuff will probably be dead in a few years. I think they would be better off working within established paradigms rather than trying to do something completely new. How about, for example, making it as easy as possible to use React with a C# backend?

pier25 3y ago
React will die too, eventually. Or at least stop becoming the default.
- osigurdson 3y ago
  Agree, but a dying star creates new life and pathways from old to new. A dying snowflake, just evaporates.
  - seti0Cha 3y ago
    I used to be a frontend coder, but am no longer. In part this is because I couldn't bring myself to keep up with the constant ecosystem churn of the JS world. I recently worked at a company that was trying to migrate from Vue 2 to Vue 3. It was not going quickly. Is Vue going to even be around in a few years, or will React eat it entirely? Or will react itself be eaten by Svelte? I have no idea, I'm not involved in these things. But after watching how such things play out for a couple of decades, my conclusion is that if you are building for the web, you should use whatever you are comfortable with and what provides the features you want now, because there's no way to know what things will look like a few years down the road. Even if the framework you chose sticks around, you may end up doing a rewrite because of other concerns or throw the whole thing away altogether.
- Someone1234 3y ago
  Let's say it does: It leaves behind a WebAPI backend that [new hotness] can utilize. WebAPI is an agnostic protocol. What does Blazor leave behind? Nothing reusable at all. It is a proprietary server hosting proprietary connections via proprietary pipeline. Plus sometimes inscrutable WebAssembly. Just go ask all the companies STILL stuck on Web Forms or Silverlight how that worked out for them the last times? Exactly. Friends don't let friends buy into proprietary backends that muddy the water between UI/API layers. Stick to WebAPI and put whatever you want in front. That way you can migrate either front OR back independently of one another (and or do piecemeal migrations). PS - This has nothing to do with "Microsoft bad." This has to do with standard protocols between front/back Vs bespoke stuff. I'd also criticize the short-sightedness if another company offered the same thing.

george_sp 3y ago

I feel like your comment touched a million different places so I'll try to compose my arguments in a compact manner, hopefully to make some sense. > All the dis-advantages are not relevant for enterprise LOB apps, which Blazor is best suited for. Where does this conclusion come from? At least from my humble experience,I've been doing them for ~10 years with various tools, both JS and Blazor/Razor Pages and the fact that they "work" does not mean they stand on solid ground. I've written apps in Blazor, yet I don't understand its existence. Most apps, even LOB as you said, Razor Pages are more than enough. Razor Pages are amazing. What seems to me to be the source of the problem is the whole mentality: > But, as a developer who has done exactly one complex web app for a client, let me tell you, the ability to use C# models, directly from your domain, in web app markup code, using Razor components is a god send... You can ship server side generated HTML with Razor and just LEARN a bit of JS. I don't understand the allergy of the so called "back end" developers with JS. Yes it's shitty. Yes it feels better writing C#. I also like my bike more than my car. Will I take my bike to drive 500km? No. There's a time and place for everything. I feel efforts like Blazor just fight against the (unfortunate yet inevitable) current that JS is the only language that can manipulate DOM. I really think all of us should be open to use whatever makes sense for the job, even if it occasionally makes us feel uncomfortable. This is the dev community I want to be a part of.

gedy 3y ago
> I don't understand the allergy of the so called "back end" developers with JS I think what many people are complaining about is that they actually dislike UI development and all the ambiguity and complexity. "JS" just catches blame for this. Modern JS and esp. TypeScript are pretty good languages, or at least comparable. A lot of these server side UI toolkits avoid some of the complexity by supporting basic UIs and flows, e.g. List/Show/Edit (which is fine in many cases), but to do complex UIs that many modern apps need, it's a huge pain. Worse situation to dev is forcing 80% of the functionality via server side, then the last 20% you ask "front end" to wedge in with jQuery style development.
- uticus 3y ago
  As someone who suffers from this allergy, I'll chime in with 2 additional thoughts: It's not just that UI development is more ambiguous, it is the fact that it is difficult to make text-based code fit it. This is doubly (or maybe logarithmicaly) so when responsive (same code fit different screens). HTML, XAML, HAML, etc all require a lot of code. Reusability mechanisms (like components, etc) help this but it is a world of difference from what BE devs are comfortable with. Thought #2: I'd guess BE devs like to just code, and the FE frameworks have a reputation of getting in the way of that. This is a less certain thought, so welcome opposition, but seems at least like part of the emotional reaction a BE dev would have to FE work.

JackMorgan 3y ago

I use swashbuckle and swagger-typescript-api to automatically scrape my controllers and generate API calls and TS types every time I rebuild. No hassle or overhead at all. No need for converters or anything. I've been using this now for several projects, it's a great way to have all the power of TS for client side and C# for server side. https://www.npmjs.com/package/swagger-typescript-api https://www.npmjs.com/package/swagger-typescript-api https://www.nuget.org/packages/Swashbuckle https://www.nuget.org/packages/Swashbuckle

CharlieDigital 3y ago
I do the same. I have a small write-up here: https://chrlschn.dev/blog/2023/10/end-to-end-type-safety-with-dotnet7-webapis-typescript-openapi/ https://chrlschn.dev/blog/2023/10/end-to-end-type-safety-wit... You get end-to-end type safety (even better once you connect it to EF Core since you get it all ways to your DB). With this setup with hot-reload (currently broken in .NET 8 [0]), productivity is really, really good. Like tRPC but with one of the most powerful ORMs out there right now. [0] https://github.com/dotnet/sdk/issues/36918 https://github.com/dotnet/sdk/issues/36918
aerhardt 3y ago
I do the same in Django with drf-spectacular. I have a precommit hook that autogenerates (fairly thin) TypeScript schemas and routes on commit. This is not take merit from LOB devs who want to use C# back-to-front. I will use it as an argument to those who say that this is why you should go full TypeScript on any new web project though.
switch007 3y ago
N.B. the last commit/release for Swashbuckle was Jan this year. https://github.com/RicoSuter/NSwag https://github.com/RicoSuter/NSwag might be a better choice for a new project. It look much more maintained and active than Swashbuckle
- dustymcp 3y ago
  yeah nswag has been pretty consistent i can recommend aswell.

SantiagoElf 3y ago

BBBBBBBBBBBBBBINGOOOOOOOOOOOOOOOOOO! Yes, at the end of the day, businesses use software in LOB apps. Period. Get shit done. WebForms/ASP.NET MVC/.NET Core MVC/Blazor will outlive ANY js framework.

uticus 3y ago
Agreed. I mean really in the spirit of get er done the AS400 is the pinnacle of UI for these sorts of things. I've worked with other things, even WinForm apps, Access things, Excel sheets that were turned into portable apps, and of course web pages. Green screen allowed 99% of things to get done faster with 1000% less fuss. https://en.wikipedia.org/wiki/Computer_terminal https://en.wikipedia.org/wiki/Computer_terminal
- yCombLinks 3y ago
  My first job required maintaining a very old informix 4gl app. The trained users could fly in that thing! Seeing clunky webapps with a bunch of clunky laggy UI components doesn't seem worth it for trained internal users
  - uticus 3y ago
    At my old job non-technical people would navigate about as well as they would with a mouse and a graphical-based interface, because the graphical interface didn't provide any additional value. For those people it took the same time whether read instructions and press key or read instructions and click button. Trained people were definitely faster, and often the user would type ahead of the terminal (with no ill effects) because they were inputting data close to their speed of thought about the process [0]. The point is, for this situation a text-based terminal offered no downsides and many benefits compared to a graphical UI. I suspect the same is true for a lot of other business solutions. I've heard it argued before that graphical systems are easier to use, but in my day-to-day experience in the trenches with others who actually used the systems this argument was simply not true. I've also seen it hinted that graphical systems seemed more modern, so they got less emotional disdain. That rings more true to me. And really if I were in charge of such things I would acknowledge emotional disdain - even misplaced - may well count for something in the overall business picture. Also, and maybe most importantly, if the green screen needed a new feature or bugfix, there was one person at corporate that would do that. They had about a half dozen devs working on other things but she was the go-to for the green screen features. So I imagine it's harder to hire people for those sorts of systems nowadays. However it was also interesting for me to note that one person didn't seem stressed out or overly busy and the system never had a major crash or bugfix. So, tradeoffs. [0] The terminal was actually hosted inside a wrapper app inside Windows 7. So I ended up using AutoHotKey to great effect to get even more efficiency gains. * edit: added footnote explaining how AutoHotKey could be talked about in same breath as green-screen dumb terminals.

skrowl 3y ago

[dead]

_5hxt 3y ago

This may help if you'd like to keep front and backend(s) separated: https://quicktype.io/ https://quicktype.io/

yread 3y ago

I consider myself more of a backend person but I feel I can deal with JS much easier than CSS. I learnt both in 15 yrs ago so compatibility with IE was crucial. Slap jquery on, stick to style guidelines so that variables are named consistently, avoid dependencies and it feels okish. There isn't anything like that to help with CSS though.

renegade-otter 3y ago
As a backend dev primarily, learning CSS Grid really helped me filter out a lot of the BS. It's a UI framework that is 20 years too late, and with "lean" JS frameworks that are emerging, a lot of this UI development legacy can die a horrible death as far as I am concerned.

zerr 3y ago

So is it like ASP.NET WebForms?

abrookewood 3y ago
More like Elixir/Phoenix's Live View I would think.