4 ms·

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 cam

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.
- halfcat 3y ago
  > 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. Does this mean the JS-interop performance penalty goes away?
  - mgh95 3y ago
    It would both improve the performance of c# performance, reduce alloc overhead for javascript interop and reduce download size. It's an absolute win.
- legulere 3y ago
  Wasm-GC isn’t compatible with .NET allowing references to fields among other issues. So I doubt that we will see integration soon https://github.com/WebAssembly/gc/issues/77 https://github.com/WebAssembly/gc/issues/77
  - evntdrvn 3y ago
    I have faith that it'll happen eventually, in some form

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.

halfcat 3y ago
> 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. Does this mean the JS-interop performance penalty goes away?
- mgh95 3y ago
  It would both improve the performance of c# performance, reduce alloc overhead for javascript interop and reduce download size. It's an absolute win.
legulere 3y ago
Wasm-GC isn’t compatible with .NET allowing references to fields among other issues. So I doubt that we will see integration soon https://github.com/WebAssembly/gc/issues/77 https://github.com/WebAssembly/gc/issues/77
- evntdrvn 3y ago
  I have faith that it'll happen eventually, in some form