4 ms·

All I want is for dotnet watch to behave in a predictable way. In .NET 9, even when using —no-hot-reload, sometimes CSS changes to components are not picked up

All I want is for dotnet watch to behave in a predictable way. In .NET 9, even when using —no-hot-reload, sometimes CSS changes to components are not picked up on Blazor components. It’s so aggravating because ASP.NET with server side Blazor components really has it all: type safety, server-side components ala Astro, fantastic ORM model, great runtime perf. But this little issue makes dev quite tedious at present: did I mistype a Tailwind class name, or did dotnet watch miss the change?

whoknowsidont 1y ago
[flagged]
- zbentley 1y ago
  Say more?
  - PathOfEclipse 1y ago
    .NET perf can be great in the sense that it provides more tools to write C-like code while still taking advantage of safe memory management, as compared to Java. On the downside, both their JIT and their GC seem to be far less sophisticated than the JVM. Why, for instance, does the CLR GC not have something like TLABs? The result is that it seems like .NET devs have to worry a lot more about the expense of small, short-lived allocations, while in Java these things are much cheaper. Overall, I think it's easier to program idiomatically in Java and get decent performance out-of-the-box, while C# may provide more opportunities for optimization without having to rely on something equivalent to sun.misc.Unsafe and offheap allocations.
    - pjmlp 1y ago
      And it does, how I wish for Valhala to become a reality, and finally having structs, spans, and all the other C++ like capabilities C# enjoys, and Java lacks.
    - Capricorn2481 1y ago
      > On the downside, both their JIT and their GC seem to be far less sophisticated than the JVM I've always heard this, but does it actually manifest in noticeably worse performance than the JVM? Go has a much simpler GC, but it's not terribly slower than Java (I do know they are optimized for different things). It seems like C# is within bounds of Java while also having great performance escape hatches.
  - whoknowsidont 1y ago
    Why does his statement not require more substance? Why do I have to provide it? The burden is the other way around. Blazor's architectural model makes it impossible to be "performant." It's not even debatable. What you gain in DevEx you lose substantially in user experience.
    - mattgreenrocks 1y ago
      I'm speaking of static server-side components, thus no JS or WASM. Wouldn't touch any other Blazor mode for a public facing app.
      - whoknowsidont 1y ago
        What do you gain from implementing in Blazor at that point?
    - zbentley 1y ago
      > Why do I have to provide it? The burden is the other way around. Well, it sounds like you have an axe to grind, but I didn’t ask to “prove” anything; I was curious to learn what was meant by the bad-performance claim. I don’t program in any of these technologies; I don’t have a horse in this race. Let’s try this again: > Blazor's architectural model makes it impossible to be "performant." Say more?
      - whoknowsidont 1y ago
        It sounds like you're just baiting.
bob1029 1y ago
> It’s so aggravating because ASP.NET with server side Blazor components really has it all Agreed. I bailed on Blazor over the tooling experience. Editing components in VS2022 was so janky for me. Syntax highlighting and intellisense never worked correctly.
- jabart 1y ago
  We have had great success with Maui Blazor Hybrid. Each release hot reload gets better with fewer edge cases. I also found that having a separate .cs file instead of in one file helps with highlighing and intellisense.
- MortyWaves 1y ago
  I don’t think there’s ever been any good tooling for the entire collection of ASP.NET DSLs. Be that MVC, Razor, or Blazor. Genuinely the same problems I had in VS2010 still happen in VS2022. There’s been some changes and improvements, but I really have to ask what the editor tooling team within that team are doing. I know there are some very difficult problems involved in parsing and formatting and highlighting bastardised mixtures of HTML, C#, and JavaScript all in the same file but if anything I think that perhaps suggests it was a bad idea to begin with. Consider the tooling for desktop and mobile apps with XAML (WPF, Avalonia) or even WinForms - they all have code behind support. Meaning there is no need (or ability) to mix all three in the same file.
shortrounddev2 1y ago
Are you using Visual Studio or another tool (vscode, vim, rider)? I found hot reload works a lot better in Visual Studio than any other IDE
- deburo 1y ago
  That's true, but even in Visual Studio, Hot Reload breaks too often to be comfortable. It seems the intermediate .g.cs handling is a bit error prone.
- mattgreenrocks 1y ago
  Rider, but I'm on Mac, so I can't use the real VS. I run dotnet watch from a terminal separately.
rafaelmn 1y ago
I inherited an MVC app that has a bunch of jQuery rendering crap and I would like to move to server side components - since you seem to be into Blazor Server side - have you heard of HTMX ? What would you say would be the benefit of Blazor vs HTMX and Razor Pages for subviews ? My experience with Microsoft UI toolkits after winforms, is that they are all janky over-engineered stuff (Silverlight/WPF/Xamarin/Maui) terrible tooling and support compared to alternatives. And Blazor using websockets makes me believe it is the same. The compile to WASM idea is a typical example of this. So what would be the selling point of Blazor ? It feels like you are just bundling stuff into Blazor magic when you could KISS with something simple like HTMX ?
- doomroot13 1y ago
  As of today (and going forward), there are two different flavors of Blazor server-side rendering. There is the original version where the component is rendered on the server and interactivity is provided via websockets. Now there is also static server-side rendering, which works very similarly to razor pages, pages/components are rendered on the server and there is no interactivity. You can then, of course, add interactivity wherever you'd need it with server-interactive or webassembly interactive sub-components. I wouldn't necessarily say there's any benefit of Blazor over HTMX, it just depends on what you're most comfortable with and what works for you in your project. But you could architect your front-end in a similar way where you have small blazor components in your pages with interactivity. I think Blazor is in a nice state now, where I can iterate very quickly on projects with just static server side rendering and add interactivity whenever it's needed. It gives me a very fast website, rendered on the server, and the option to add some interactivity whenever I need.
- WorldMaker 1y ago
  I still haven't found a use-case for the websocket Blazor Hybrid and it still smells so much like the worst mistakes of the original ASP (before .NET) and the `runat="client"` versus `runat="server"` confusions. Blazor WASM makes some sense if Silverlight ever made sense for a project: it's a way to ship C# directly to the browser for maximal code sharing with other C# projects in a C# ecosystem. It's basically "what if Angular/React was just Razor Pages running on the browser?" It's absolutely the opposite of KISS, it's lifting and shifting the entire .NET runtime in WASM to the client. Outside of corporate networks and packaged apps like Electron or Tauri, I'm not sure it makes any sense. But if you like writing Razor Pages and wished they ran closer to the client metal, and you can afford the bandwidth of an entire .NET application soup-to-nuts as your SPA framework, there is a sense to it. If all you think you need is Razor Pages with HTMX that's probably all you need.
edtech_dev 1y ago
I hear a lot of complaints about dotnet watch, but my experience doesn't match. I just use it from the terminal (instead of running it from an IDE) and it mostly just works.

whoknowsidont 1y ago

[flagged]

zbentley 1y ago
Say more?
- PathOfEclipse 1y ago
  .NET perf can be great in the sense that it provides more tools to write C-like code while still taking advantage of safe memory management, as compared to Java. On the downside, both their JIT and their GC seem to be far less sophisticated than the JVM. Why, for instance, does the CLR GC not have something like TLABs? The result is that it seems like .NET devs have to worry a lot more about the expense of small, short-lived allocations, while in Java these things are much cheaper. Overall, I think it's easier to program idiomatically in Java and get decent performance out-of-the-box, while C# may provide more opportunities for optimization without having to rely on something equivalent to sun.misc.Unsafe and offheap allocations.
  - pjmlp 1y ago
    And it does, how I wish for Valhala to become a reality, and finally having structs, spans, and all the other C++ like capabilities C# enjoys, and Java lacks.
  - Capricorn2481 1y ago
    > On the downside, both their JIT and their GC seem to be far less sophisticated than the JVM I've always heard this, but does it actually manifest in noticeably worse performance than the JVM? Go has a much simpler GC, but it's not terribly slower than Java (I do know they are optimized for different things). It seems like C# is within bounds of Java while also having great performance escape hatches.
- whoknowsidont 1y ago
  Why does his statement not require more substance? Why do I have to provide it? The burden is the other way around. Blazor's architectural model makes it impossible to be "performant." It's not even debatable. What you gain in DevEx you lose substantially in user experience.
  - mattgreenrocks 1y ago
    I'm speaking of static server-side components, thus no JS or WASM. Wouldn't touch any other Blazor mode for a public facing app.
    - whoknowsidont 1y ago
      What do you gain from implementing in Blazor at that point?
  - zbentley 1y ago
    > Why do I have to provide it? The burden is the other way around. Well, it sounds like you have an axe to grind, but I didn’t ask to “prove” anything; I was curious to learn what was meant by the bad-performance claim. I don’t program in any of these technologies; I don’t have a horse in this race. Let’s try this again: > Blazor's architectural model makes it impossible to be "performant." Say more?
    - whoknowsidont 1y ago
      It sounds like you're just baiting.

bob1029 1y ago

> It’s so aggravating because ASP.NET with server side Blazor components really has it all Agreed. I bailed on Blazor over the tooling experience. Editing components in VS2022 was so janky for me. Syntax highlighting and intellisense never worked correctly.

jabart 1y ago
We have had great success with Maui Blazor Hybrid. Each release hot reload gets better with fewer edge cases. I also found that having a separate .cs file instead of in one file helps with highlighing and intellisense.
MortyWaves 1y ago
I don’t think there’s ever been any good tooling for the entire collection of ASP.NET DSLs. Be that MVC, Razor, or Blazor. Genuinely the same problems I had in VS2010 still happen in VS2022. There’s been some changes and improvements, but I really have to ask what the editor tooling team within that team are doing. I know there are some very difficult problems involved in parsing and formatting and highlighting bastardised mixtures of HTML, C#, and JavaScript all in the same file but if anything I think that perhaps suggests it was a bad idea to begin with. Consider the tooling for desktop and mobile apps with XAML (WPF, Avalonia) or even WinForms - they all have code behind support. Meaning there is no need (or ability) to mix all three in the same file.

shortrounddev2 1y ago

Are you using Visual Studio or another tool (vscode, vim, rider)? I found hot reload works a lot better in Visual Studio than any other IDE

deburo 1y ago
That's true, but even in Visual Studio, Hot Reload breaks too often to be comfortable. It seems the intermediate .g.cs handling is a bit error prone.
mattgreenrocks 1y ago
Rider, but I'm on Mac, so I can't use the real VS. I run dotnet watch from a terminal separately.

rafaelmn 1y ago

I inherited an MVC app that has a bunch of jQuery rendering crap and I would like to move to server side components - since you seem to be into Blazor Server side - have you heard of HTMX ? What would you say would be the benefit of Blazor vs HTMX and Razor Pages for subviews ? My experience with Microsoft UI toolkits after winforms, is that they are all janky over-engineered stuff (Silverlight/WPF/Xamarin/Maui) terrible tooling and support compared to alternatives. And Blazor using websockets makes me believe it is the same. The compile to WASM idea is a typical example of this. So what would be the selling point of Blazor ? It feels like you are just bundling stuff into Blazor magic when you could KISS with something simple like HTMX ?

doomroot13 1y ago
As of today (and going forward), there are two different flavors of Blazor server-side rendering. There is the original version where the component is rendered on the server and interactivity is provided via websockets. Now there is also static server-side rendering, which works very similarly to razor pages, pages/components are rendered on the server and there is no interactivity. You can then, of course, add interactivity wherever you'd need it with server-interactive or webassembly interactive sub-components. I wouldn't necessarily say there's any benefit of Blazor over HTMX, it just depends on what you're most comfortable with and what works for you in your project. But you could architect your front-end in a similar way where you have small blazor components in your pages with interactivity. I think Blazor is in a nice state now, where I can iterate very quickly on projects with just static server side rendering and add interactivity whenever it's needed. It gives me a very fast website, rendered on the server, and the option to add some interactivity whenever I need.
WorldMaker 1y ago
I still haven't found a use-case for the websocket Blazor Hybrid and it still smells so much like the worst mistakes of the original ASP (before .NET) and the `runat="client"` versus `runat="server"` confusions. Blazor WASM makes some sense if Silverlight ever made sense for a project: it's a way to ship C# directly to the browser for maximal code sharing with other C# projects in a C# ecosystem. It's basically "what if Angular/React was just Razor Pages running on the browser?" It's absolutely the opposite of KISS, it's lifting and shifting the entire .NET runtime in WASM to the client. Outside of corporate networks and packaged apps like Electron or Tauri, I'm not sure it makes any sense. But if you like writing Razor Pages and wished they ran closer to the client metal, and you can afford the bandwidth of an entire .NET application soup-to-nuts as your SPA framework, there is a sense to it. If all you think you need is Razor Pages with HTMX that's probably all you need.

edtech_dev 1y ago

I hear a lot of complaints about dotnet watch, but my experience doesn't match. I just use it from the terminal (instead of running it from an IDE) and it mostly just works.