.NET Blazor
dusted.codes
dusted.codes
You can build really rich interactive experiences in Blazor at a fraction of the time required to build the same thing with the standard JavaScript SPA architecture. However, now that we have many customers using the application in production, we're starting to see some of the not-so-pleasant side of Blazor Server. When experiencing a lot of requests, the experience is degraded for all users of the app. In addition, it's not very good at re-establishing the WebSocket connection if it fails, giving a poor impression to the user. Though, I'm impressed with the latency—we're hosted in Europe and have customers in New Zealand who use the app without any latency issues whatsoever.
I'm excited about the auto-rendering mode, which looks pretty straightforward. I don't really buy the author's argument that it introduces an extra layer of complexity—we're still light years away from the complexity that a modern JavaScript SPA involves. For small teams with just a couple of full-stack developers, Blazor is still one of the best and most productive stacks, in my opinion.
I'm optimistic about the auto-rendering mode, which will serve the app via Blazor Server (using a WebSocket connection) the first time the user hits the app. It will download the WebAssembly DLLs in the background so that the next time the user comes by, they will get the WebAssembly-hosted version. It's an interesting mix combining the best of both worlds (hopefully).
Blazor Server renders the DOM at the server and sends it to the browser. The server also holds on to some state for each client - notably the "current DOM" - so that it can calculate diffs on changes and only send the diffs to the browser.
Blazor Webassembly does the rendering in Webassembly in the browser. The .NET stack runs in the browser. Here, the code renders and diffs in the browser and the the diffs are applied to the DOM as well.
This also means that the same components can run either server-side or client-side. They basically all end up computing DOM diffs and applying those diffs to the actual DOM. Pretty neat, actually.
Each model has it's pro and cons. Blazor Server initialized really quickly and relies on minimal Javascript in the browser. But it creates load and server affinity on the server. Blazor Webassembly offloads all rendering to the browser, but at the cost of an initial load of the code.
In .NET 8 these can now be blended, and a new "auto" mode allows a component to be initially server-side and then client-side when the webassembly code has downloaded.
In addition to that is now (.NET 8) also the static server side rendering (and "enhanced navigation") which you could say is server side components without the "circuit" server affinity and server state of each client. Static server side rendering has some limitations on how interactive they can be - i.e. changing the DOM.
If this is how Blazor is architected. Then I have no interests in using this and really anyone doing any type of web development shouldn't bother with this. Internal apps eventually need to be used externally. This is a time bomb waiting to explode on the users and the developers.
I use VueJS with Asp.net Core with multi-page single load architecture. Meaning once a page is loaded all other data is loaded through ajax. But the app is made of multiple pages. Over 10 years of being a web developer has brought me to this setup. Client UI state should stay on the client. All other state should be saved to the server. All communication should be stateless.
I'm just saying a lot of the target they are aiming to replace is VBA applications slapped on top of Access DBs, and Lovecraftian nightmares born out unholy fornication of Batch scripts and unintelligible spreadsheet formula.
I'm not saying your wrong, just pointing out that even if this is a ticking time bomb it's a ticking time bomb that is using conventional explosives replacing a cesium based nuclear time bomb that is already counting down the seconds.
I don’t understand this. I’ve used v2 since before release and it’s never been anything more than an initial setup of 5m and then build your app?
Interested on how many concurrent users you have for Server to be a problem. Can you elaborate more on your performance issues?
Well if you want to make small fast loading html pages with a minimal js library, and end up at a few hundred KB that you can understand, profile and optimize, then that is impossible with blazor. So it's a very real problem.
If you want 5mb blobs and do not care about what is going on inside, how to optimize or reduce the memory and bandwidth usage, then it's not a problem, works just as well as the websites you have seen, with 200 node dependencies.
Oh, hey, I have something relevant to say about this setup. Currently I'm bootstrapping a platform with .NET Core on the back end and Vue 3 on the front end.
In short:
- .NET is one of those boring workhorse choices, like Java - it's pretty stable, the performance is good, the type system is decent, IDEs are as good as it gets (Rider, VS), can run on Windows or Linux with no issues, there is an ecosystem that feels very coherent (more focus on ASP.NET than something like Spring in Java, because there's fragmentation around that, Dropwizard, Quarkus, VertX and so on)
- Vue feels really nice to work with, the Composition API feels simpler than React, the developer ergonomics are fine, the documentation is nice, packages like Pinia, VueUse and VueRequest keep things simple, in addition to something like PrimeVue giving lots of UI components that you can use to iterate out of the box
- however, while I think that the SPA approach can be nice to keep the front end separate from whatever technology you use on the back end, it comes at a cost of duplicating your data model and the interfaces between them (REST endpoint and client, for example), in addition to needing to think about how to deploy it all (separate domains vs context paths on the same domain, CSP, CORS etc.), though it's mostly doable
- I did definitely run into problems with Vue not being the single most popular choice out there, for example I wanted to integrate Mapbox maps and the VueMapbox package is for Vue 2 only, whereas Vue 3 Mapbox GL breaks when you try to integrate it with mapbox-gl-directions. Eventually I switched over to Vue Map (Leaflet based) with leaflet-control-geocoder and leaflet-routing-machine but even those tended to break, because adding markers for a calculated route makes the map break when you zoom in/out, due to it losing a reference to the map JS object; in the end I just used patch-package to fix a few lines of code that didn't work in the offending packages instead of forking/building them myself, but that's a bit of a dirty hack
Honestly, it sometimes feels like picking anything that's not React is shooting yourself in the foot because everyone's building their libraries/packages/integrations for React. At the same time, I don't really enjoy React much at all.
Can you elaborate on this? I'm not sure I get it, because once you have your view model in asp.net, it seems like it should be easy to derive a JS/TS model from it using various techniques (reflection, source generators, etc.).
Yes, you do need to set up some rather strong governance around it for it to work for multiple teams, but you should really be doing that with any technology, and once you do, it’s just excellent. Part of the reason for this is that it’s basically designed from the ground up to require that you build and maintain “template” projects, have strong linting, testing and pipeline governance, so there is a lot of freedom to make it work easily for your organisation exactly the way you want it to. Typescript is obviously not alone in this, but it’s far less opinionated than something like .Net.
The main reason is that .Net always becomes burdensome once you start using it’s included batteries. This isn’t really an issue with C# as much at it is an issue with it’s libraries. Take OData and Entity Framework as an example, the .Net magic behind them sort of share the same model builder, but they do so differently. What this means is that a lot of the cool OData features like patch doesn’t actually work with EF, meaning you’ll either have to rewrite a lot of the model builder (don’t) or have to work around it. .Net has always sort of been like that. It variates between being 50-90% “done” but it never really gets there until it moves on. Like EF, much of the EF 7 road map isn’t implemented yet, but here we are, moving on to EF8.
I think for a lot of use cases it’s a wonderful technology, and Blazor will probably be awesome until Microsoft moves on, but at least around here, it’s also a technology that doesn’t really see adoption in anything but small-midsized companies, and in my opinion, .Net is part of what hinders growth. Obviously not a huge contributor, but once you step out of where it excels, you’re just going to have to fight .Net so much harder than you will with Typescript. Which is sort of interesting considering they are both Microsoft products which align more and more. That being said, it’s not like it’s bad either.
The tldr of both the previous and this posts is OData being bad yet the author extends his grievances regarding it to the entirety of ecosystem.
You could also point back to other posts like this one: https://news.ycombinator.com/item?id=37538333&p=3#37541652
Where I also point out other, similar issues with other parts of the .Net batteries.
https://docs.servicestack.net/typescript-add-servicestack-re...
OpenAPI client generators are probably what's popular today.
There are other options too, I'd just stay away from "_the_ openapi generator" (https://openapi-generator.tech/) which does a pretty poor job IMO.
Disclaimer: I'm the founder of a company doing SDKs commercially, but we don't focus on the frontend right now, and our free plan is still in beta.
Not the case if you use graphql.
I share the article's fear of overloading the technology, but do not see it overall that negative.
We've been using Blazor server for ~3 years now and have had similar experience. We only use it for internally-facing administration sites, and even then it's still quite annoying to hear team members complain about the inevitable reconnecting to website warning, even when everyone knows exactly why its happening.
This experience with using websockets to move state between client and server has pushed us away from the idea that the client could ever be made responsible for any meaningful amount of state. In our current stack, we return final server-side rendered HTML and handle multipart form posts. There are no more websockets in our stack. Everything is stateless HTTP interactions - the client only manages a session token.
SPA was a fun experiment, but I am completely over it. If you are trying to fix some weird UX quirk, reach for a little bit of javascript. Don't throw away everything else that works over something small. There was a time when I would have agreed that you need frameworks, but that time has long since passed.
In 2023, approaches like PHP feel more valid than ever. I know way more about what doesn't work than what does these days. If you want something like PHP but you don't know where to start, you should think really deeply about what PHP is actually doing and if your preferred programming language does not also have a similar string interpolation concept.
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.
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).
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.
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!).
And I am not even talking about the language itself YET. ANd no, why should I be forced to use Typescript ? Yet another layer.
And I did I get to the 100s of config files that need to be set just so I can run "npm build" ? Webpack, Vite, blah blah.
And you are even generous, if you force upgrade every package you have in a month, I'm pretty sure you will have broken stuff.
Skill issue. Like I do that regularly. And I'm not even particularly great at frontend tech, so after 3 months I need to hit the docs to actually change anything. But the build pipeline works just fine.
> And I did I get to the 100s of config files that need to be set just so I can run "npm build" ?
..."webpack.config.ts", "package.json" and "package-lock.json" is not 100s. I mean I've seen places with, like, _a dozen_, but those folks could do the same to bash scripts and Python, some people are just messy about it.
I'm not trying to convince you to change technologies, but if you're familiar with a specific process, it's always going to be easier to follow that process than something you're not familiar with. This is coming from someone that still uses Grunt for their front-end build pipeline. It's not the newest, but it's still well supported, and I know it very well and can pull off a lot with it.
What front-end tech, everything is typescript.
Also not upgrading. I need to read the readme file because I didn't run the software in 3 months. Point is, it will _still run_. It might need a few updates for security reason, but it will _not_ magically stop working.
> It just sounds like you are more familiar with working with front-end tech,
No. I'm a full-stacker, but very much focused on backend, and actually mostly in Python. But nodejs + typescript actually works well enough that, even with _decades_ of Python experience, I now need a proper reason to pick it over typescript for a new thing.
> I'm not trying to convince you to change technologies, but if you're familiar with a specific process, it's always going to be easier to follow that process than something you're not familiar with.
Yep. Maybe the reason why some folks struggle so hard with running their old JS stacks, rather than some .net superiority?
Asp.netbwas great, asp.net cire was a good upgrade, and minimal apis are an optional way to get an asp project up and running with less boilerplate.
Not sure how that constitutes a cluster.
Funny you say that. JS..cough..JS.
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.
Why do you think this will be the case?
Couple that with the fact that interoping with JS can be a lot more annoying than just using JS
It's a one-time download that's smaller than the initial load of the Facebook feed
Facebook loads a lot of information. I don't think we should be comparing the download size of a hello world app with loading dozens of images on a facebook feed.
> And dont forget business workstations are usually connected via at least 1GBit Ethernet.
NOPE! More likely they are WiFi connected Dell shitboxes running Windows 11 with 8GB of memory, half of which is taken up by all the browser tabs, Teams, Office, and the 30 horrible little programs that IT deploys via group policy.
Speed matters. The user is probably running your code + 30 other things. Don't assume your page is the only thing they care about.
https://learn.microsoft.com/en-us/dotnet/core/deploying/trim...
And some of what I wrote is about the programming model itself - by now my experience is that domain models should generally stay on a whiteboard - it's quite rare that's actually what's more convenient in any specific place in the codebase. Trying to "streamline" that tends to end up just introducing even more complexity due to poor abstraction match.
Unless your interactivity is at the level of Gmail or Google Docs, or you really care about designing for very high latency flakey connections then LiveView is great and works very reliably with a good user experience. Even on a phone with a cellular connection going through tunnels it's actually better than a lot of JS apps because it handles the reconnection (and visualisation) much more cleanly than most JS apps.
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.
I only do VueJS when I do use JS but man I can't wait to not write any code in JS.
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.
Does this mean the JS-interop performance penalty goes away?
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.
Your "question" is non-sequitur.
If you were to include your business logic directly into your Blazor application, then you are setting yourself up to run into the exact same issues that you faced with WebForms, if Blazor were to be discontinued. You stated, "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)." Blazor is what you put in front. Blazor gets discontinued, you put a standard JavaScript framework in front. The amount of code written and the amount of tests written should be the same whether you use Blazor or React/Vue/Angular/Svelte/JS Framework of the week. What you get with Blazor is the ability to do all your front-end in C#. I think you are going at it as if you build old WebForms or Silverlight, and I just don't see why you would do that knowing full well that front-end tech changes rapidly.
That’s…literally the downside of frontend/backend separation of concerns…
It does require you to faff about with toolchains for building frontend code though (WebPack and the like), and it's not always completely seamless, but if you want to invest in a shared domain model it's the most compatible I've been able to go at least.
You call decade a substantial longevity?
Is this some kind of a joke?
Is your ability to assess being held hostage by js ecosystem expererience?
But seriously - I expect a bit more from platform that could potentially waste my life and my venture. I am still happily supporting some Java (and JSF) code that I have written for clients 15 years ago (don't you just love that sweet support fees that you get mostly for being alive and breathing ?). Meanwhile my friend that build whole company around product written in silverlight almost went bankrupt. Now after few years working in AI (going into it a bit too soon) he is trying to create same product in ... yes you guessed it, Blazor.
Maybe some people do not learn from their mistakes :)?
Maybe some people do learn, and in this case it's Microsoft, who are not repeating the same thing with Blazor as they did with Silverlight.
Silverlight was somewhat of a unique situation, as it was a platform where it heavily relied on the platform that was phasing out. (And to clarify, that "decade" is the period that Microsoft was committed to support for latest Silverlight 5. Their first version was released in 2007, so it had about 14 years of history.)
As with Java or any other languages, you can still run it if the environment it runs can be resurrected. (I would not connect that to the internet, though) And many parts of what actually powered Silverlight still thrive in a form of .Net.
I mean where they can support, Microsoft tends to keep its compatibility fairly intact, for instance modern Windows still can run many of the 32-bit binaries from early days. (And you even could do the same for 16-bit apps on a 32-bit platform, not sure if that's still possible, though.)
Silverlight came when flash was being dismantled shortly after.
Different days back then.
10 years is pretty amazing, all told, IMO.
And yes, the current state of affairs is kinda sad.
And i am afraid blazer may be next.
ActiveX - same, but 27! Years ago
Those were not failures. But have replacements.
Those are terrible examples tbh. A lot of businesses would sign immediately if they knew something was going to be supported for > 20 years. Additionally, vbscript owners should have long migrated to eg. Powershell
All dead.
And those are just the ones I can think of from the top of my head.
Plus the terrible excel VBA replacement they made, then abandoned, and now it's some fiddly javascript mess.
I'm sure there's a ton more people can add. Those are just the ones I personally wasted time on.
And let's not forget Window Mobile!
Edit: They've also gone through a stupid amount of changes in the asp.net MVC model in quite a short time. Plus constantly seem to overhaul their consistently overcomplicated authentication/authorization system. The state it's in at the moment is shockingly bad.
The difference is that they stop talking about it, their presence fades away in conference and developer blogs, and eventually from Visual Studio installation workloads.
Also had to wire a custom touchscreen event system for WPF because the Microsoft method would latch on to UI components with quick taps and press with sliding. This caused buttons to stay pressed while no fingers where on the screen.
I cannot recommend WinForms or WPF or UWP. Microsoft is bad at GUI application frameworks. It was recently that they finally shipped VS2022 with proper WinForms designer support and the ability to move away from VS2019. I still need to close and reopen VS2022 daily for WinForms and WPF development.
QT, GTK or some other framework gives the ability for cross platform solutions without being anchored to Window OS. Non Microsoft GUI frameworks are also faster and better when deterministic response time is needed and ability to run on low powered computers.
I think it's pretty safe to be optimistic at this point.
Aint is easy already?
> 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.
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.
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.
It’s funny, because you can continue the analogy and compare optionally typed languages (like TypeScript) to adding wood/rebar to a brick building, allowing it to go vertical.
A good example: the Chrysler building sports 3 million specially made bricks for its facade. By blending both materials, you receive the thermal and maintenance benefits of brick with structural integrity of steel.
For client side components C# code is compiled into WebAssembly that manipulates the DOM just like JS.
Today with Blazor Server, the main drawback is the slight delay you can get when you click something. .NET8 essentially blends Server and WebAssembly and solves the problem, even giving you the best of both worlds since WebAssembly has high first load times, .NET8 Blazor loads initially with Server side and provides client side after it loads all resources.
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.
I have a small write-up here: 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.
https://github.com/RicoSuter/NSwag might be a better choice for a new project. It look much more maintained and active than Swashbuckle
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.
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.
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.
The reasons are varied, many of which are well articulated in the article, but the most notable throughout various workplaces I've worked at, there's been a hesitance to jump on MS web frameworks in fear of a repeat of silverlight.
Silverlight burned a lot of small businesses hard, almost everywhere I've worked has had a silverlight horror story of a project they experimented in it with only for it to languish. So now they either have some outdated dependencies they'll never update or had to re-write it back into something else.
Even without silverlight concerns, most .net places I've worked have very much been legacy focused. This might be my own culture fit at interviews so I end up with places with lots of legacy of course.
But these giant legacy systems already have a plethora of mixed web technologies from ASP.net webforms, asp.net MVC, through .net core MVC, and many others. The willingness to add another different technology into the mix isn't relished.
For small companies, the cost of migrating older projects to new technologies is a significant burden which gets ignored for as long as it can be reasonably done so.
That's not really fair to MS since all the web frameworks which were born in that era (Adobe's AIR, JavaFX as a web tech, etc.) died because IE died. And also because Apple killed off browser plugins since they didn't work on the iPhone. Chrome and Firefox took over and there was no longer a need to use browser plugins for SPA's. HTML, CSS and Javascript finally got the features needed to create a proper SPA.
While JavaFX did live on outside of the browser both Adobe RIA and Silverlight were far worse positioned for life outside of the browser (even though both claimed to be usable outside of the browser). Simply because JavaFX was meant to replace Java Swing.
Oracle isn't a GUI company, beyond the stuff needed for their database products and IDEs, so they also didn't invest that much into it.
Thus most of the Java ecosystem, kept targeting Swing, and for the extent native desktop applications are still around, Swing is good enough.
Android is its own thing, so even one less reason to care about JavaFX.
Forever burnt into my mind from Programming 1008. And in fairness, much easier to get off the ground than the legions of XML required for JavaFX.
Ok, MS says this: https://dotnet.microsoft.com/en-us/platform/support/policy/x...
> Xamarin.Android, Xamarin.iOS, Xamarin.Mac are now integrated directly into .NET (starting with .NET 6) as Android, iOS, and Mac for .NET. If you're building with these project types today, they should be upgraded to .NET SDK-style projects for continued support.
> Xamarin.Forms has evolved into .NET Multi-platform App UI (MAUI) and existing Xamarin.Forms projects should be migrated to .NET MAUI.
So to those of you using Xamarin: how painful it is? How compatible Xamarin.Forms or not is with .NET MAUI? Are they totally different tech?
How easy/hard it is to go from Xamarin.{Android,iOS,Mac} to .NET6+ ?
Maui on the other hand is a turd. It’s such a pain to work with, workloads just plain suck. And if you install . Net 7 and your project targets 6, It will download .net 7 workloads and fail to build. Then 8 comes out and same problem. Have to pin the SDK.
The reason Java and JavaFX survived is that they went Open Source, with a large FOSS ecosystem, targetting FOSS operating systems as well, all while there still was interest. And their maintenance and evolution continued. Adobe RIA and Flash were proprietary platforms, just like Silverlight.
In fairness, projects that survive tend to be FOSS, and AFAIK, .NET Blazor is open source. OTOH, the .NET ecosystem tends to prefer Microsoft's solutions, with alternatives languishing, they basically killed Xamarin's projects, and they have had several noteworthy conflicts with the FOSS community. So the jury is still out on whether Microsoft's projects can escape the deprecation curse.
---
The lesson here, for all, if you want for your knowledge and work to stay relevant, look towards Open-Source platforms and open standards. If seeking stability, the older, the better, actually. FOSS platforms age like fine wine.
Who could have foreseen that hitching your horse to derpy, single-vendor RIA frameworks that were closed source proprietary and worked on the basis of shoving foreign content into the browser to get it to do non-Web things was a bad idea? Oh wait, anyone.
In that vein, in response to the earlier remarks by the original commenter:
> Silverlight burned a lot of small businesses hard, almost everywhere I've worked has had a silverlight horror story of a project they experimented in it with only for it to languish. So now they either have some outdated dependencies they'll never update or had to re-write it back into something else.
Yeah, good. That pain is well-deserved. Almost self-inflicted, even.
.NET (and Blazor) has been open source for at least 7 years now
By far, the most devastating one, was Flash.
One good thing came out of Silverlight, and it's not really getting the credit it deserves: MVVM.
As far as I know, Silverlight brought that pattern to light, before that, it was MVC and OO hell. And MVVM paved the way to modern paradigms, imho.
Flash was always going to die someday though, as HTML/JS caught up with it. In the end it was killed (arguably) prematurely, but it probably wouldn't have lasted more than another 5-6 years anyway.
Silverlight, I think, was worse - only a few years between initial launch and discontinuation. Pretty much every client app based on Silverlight would have had to have been rewritten from the ground up within a couple of years of completion.
I try to learn lessons, in life. One of them is to not rely much on any Microsoft technology that's less than 10 years old.
I'm not sure that would happen. I think Flash would evolve to just "compile" to HMTL/JS. IOS/Android could be other targets as well, once they found a way that would not upset the Eye of Apple.
Now, it’s possible that some of that could’ve improved (battery life would’ve been hard due to the scene timing model) but Adobe just isn’t a platform company. They didn’t even want to fix the security problems, much less all of their half-assed APIs - they were even worse than Sun for announcing ambitious frameworks duplicating built-in OS features, shipping the easiest 40%, and then letting it stagnate because there was no way fixing the hard stuff would get them a second keynote.
I've been working on a large-ish Blazor (Server) application for about a year. The choice to use Blazor was not mine, but I went into it with an open mind. For context, I have used React and Angular in the past.
I will never used Blazor again.
Performance is not good, with CPU always at some base level, even when idle. My machines fan is always cranking while developing it. Hot reload does not work consistently (on like 25% of the time), and when it does, it is slow, so it might as well not work at all. Everything in Blazor just feels half-baked.
I'm old enough to remember things like "ActiveX Documents" and Silverlight, where were other attempts by Microsoft to provide a way for people not to have to learn and use a proper front end framework, and I think Blazor will end up on the scrap heap with them.
Microsoft has a bad habit of touting the next big thing for developers to use and then abandoning it several years later. This feels like that to me.
Do you think a WASM approach has merit or do you think it is doomed?
I still think there is a rug-pull risk by Microsoft, so not sure I would choose it for that reason alone.
I have a completely difference experience but then again I'm creating business apps and do not anything 'new'.
What it doesn't really tackle is the productivity from the developer perspective, very little mental context switching, code re-use/sharing with backend models etc (api models, validation etc) and the surprisingly productive nature of the Razor templating language. It's a combination that makes sense for developers, less so for end users. Most end users for these apps will be corporate intranets (love that the article mentions SEO, yeah right). When these same corporate users were using monolithic WPF apps, did anyone care then? If you're replacing a shared spreadsheet cooked up by Tim on the data analytics team, how much does JS really matter.
Consider if the same Devs opted for react or angular etc, would the end users actually care?
Ultimately it's up to the businesses to decide if this makes sense and the technology is driven mainly by developer sentiment, which circles back. If this is an easy way to make corporate apps, then why not.
http://boringtechnology.club/ 's slides show the problem pretty well. I'm not saying companies should stick to one technology, since the "golden hammer" is also not a good idea, but that the technology choices should be taken with care and consideration of things like hiring.
- Unknown unknowns (since it hasn't been out for as long and battle-tested by as many people)
- Shiny new tech (one could argue that C# is old, but that's a small part of the experience of a new and shiny API)
> If you're replacing a shared spreadsheet cooked up by Tim on the data analytics team, how much does JS really matter.
It was such a joy to work with. Productivity was so high. You add Blazor Radzen components[1] or Syncfusion[2] and suddenly feels like magic. Super complex grid tables can filter, re-order columns, aggregate them and much more functionality for free in 10 lines or fewer.
I cannot recommend enough to people to give it a try. This technology enabled me to do a repair shop software in 1-2 month on my spare time. From customers to emitting bills in PDF. Zero JS and just using the basics grids from bootstrap CSS to make it responsive. As a non frontend developer, this was heaven.
[1] https://blazor.radzen.com/ [2] https://www.syncfusion.com/blazor-components
Interestingly enough Google's crawlers don't even choke on it: my fully SignalR based site was indexed soon after getting a spike in traffic without an issue.
Does it annoy me that leaving the tab and coming back can kill the app? Sure. But often times I reach for it when I otherwise wouldn't have built a thing at all.
Most normal people will take an app with hair edges they can use over nothing so I'm going to keep reaching for it from time to time
Javascript seems downright lightweight and unbloated compared to shipping an entire dot net runtime for a crud form app. For what it's worth, I don't care about turning off javaScript or even bloat in general, but this is extreme.
Of the tens of thousands of people who found my tool useful, the only people who ever complained where Hacker News users, and the tool simply would not exist if I had gone and wasted my time spinning up Next, realizing the app router is garbage, RSC has no place in most React apps, then going back to pages router, then rediscovering how awful NextAuth is, then...
Which is exactly how some of my otherwise interesting side projects die too.
Native desktop development is another matter, though.
Clearly. And that's exactly where the most salient criticism of it comes from: prioritizing the pleasure of the programmer during the development process over everything else, including the experience of the person who actually has to put up with using the thing—all while providing cover for the vendor who bid on the job to argue that they've fulfilled all the requirements so what are you upset about if it's a little janky? Classic enterprise crapware mindset.
I switched to Blazor Server for the last year in a new company and it has a montrous amount of benefits.
First of all, do not pretend that you are Google or Facebook. This is a repeated mental illness that developers suffer from. No won't face any performance issues. The contrary, Blazor is blazing fast.
However, there are couple of issues when it comes to interactivity with javascript frameworks. Until .net 7 you could use every JsRuntime.JsInvoke... something like that to invoke JS function. In .net 8 they changed something and you cannot use it like that anymore or you get strange subtle errors when you get "too" dynamic. I'm figuring it out right now. But other than that you have a gigantic .net stack with build-in support ORM, RateLimiter, Caching, Distributed-Caching, MVC, WebAPI, ... The list of features is infinite.
I like the Leptos approach more. Smaller binaries,lessoverhead, website already works completely during loading WASM and turns on client side rendering once it is loaded.
I think like most MS products it suffered from being not quite ready for production when they claimed. We started using it in dotnet 6 and there were a lot of features that I ended up implementing or rough edges I worked around myself that were subsequently included / fixed in the dotnet 7 version.
I am hopeful that WASM GC + dotnet linking & trimming + the auto thing mentioned in the article will make it an acceptable choice for public-facing websites as currently I'm not sure how well I could justify it despite my personal feelings on JS vs C#.
I am eager to try Fable at some point though, probably on a personal project first.
I was short on Blazor before .NET 8 and could only seriously recommend it for Internal Apps since the compromises for using either of Blazor's Server or WASM Interactivity delivered a poor UX for Intranet hosted Apps as covered by this post.
However that's changed in .NET 8 Blazor's default Static Rendering where you're effectively able to develop traditional Server Rendered Apps like Razor Pages/MVC but with Blazor's superior component model, advanced features like Streaming Rendering and its built-in (smart) Enhanced Navigation which gives simple Server Rendered App's SPA-like responsiveness without any of npm's build tool complexity, need to manage separate client routing, heavy client state, npm dependencies, large JS bundles, etc.
Even better is that you no longer need to use Blazor Interactivity for any Web App features, e.g. which we avoid in our "Blazor Vue" (100% SSR) Tailwind template that progressively enhances statically rendered Blazor content with Vue.js. I cover this approach in detail in our ".NET 8's Best Blazor" [1] blog post.
As it embraces the simplicity of "No Build" JavaScript Modules (i.e. avoiding npm deps + build tools) it's now become my preferred approach for most .NET Web Apps.
Blazor Diffusion [2] is an example App built using this template, originally developed in Blazor Server, deployed as WASM but now converted to "Blazor SSR + Vue", source code available at [3].
[1] https://servicestack.net/posts/net8-best-blazor
Razor pages with JavaScript on the front end and automatic diffing on the backend is definitely appealing. As much as I don't like the idea in general of serverside session state.
By the way, I think if you used a light-dom framework like alpine or petite-vue you would avoid most of the issues with the page not recalculating the front-end state on navigation.
Unfortunately it's how Blazor Enhanced Navigation works where it compares the rendered content of the new page and diffs in the changes so I'm not expecting it to work by default (i.e. without adopting a workaround) with any JS FX that dynamically generates the UI as it'll get replaced back into an empty div when Blazor patches in the new page elements.
Also I wouldn't recommend "lite-dom" FX's like PetiteVue which has basically been unmaintained since 2021, has poor composition/component model and pretty glaring bugs/limitations you're likely to hit very quickly for any complex UI. We ended up having to rewrite all our Built-in UIs [1] with Vue 3 [2] to overcome its limitations. The 40kb increase in minified/compressed .js size vs vue.min.js is not worth the pain of working within its limitations.
[1] https://servicestack.net/auto-ui
[2] https://docs.servicestack.net/releases/v6_07#new-locode-api-...
I did that same rewrite (alpinejs to vue3) in a project of mine. I did it for CSP reasons rather than performance/behaviour limitations despite spending quite a while getting recursive generation to work.
The next project has less untrusted input and a simpler datamodel so I went with alpine again and I've not had any issues whatsoever.
Good to know about the bugs/abandonment of petit-vue. Admittedly, I probably shouldn't have recommended it above without having used it.
I'm sorry, but WTF? You spend 5 paragraphs talking about how great Blazor Server-Side Rendering is and then throw a "+ Vue" right at the end? WTF? So it's not SSR at all!? How are you avoiding npm and JavaScript builds when you're literally using Vue? That little example app you showed has ~3500 lines of JavaScript in it ...
It is 100% using Blazor SSR, i.e. uses Blazor Static Rendering on all Blazor Pages and never uses Blazor Server or WebAssembly Interactive render modes.
> How are you avoiding npm and JavaScript builds when you're literally using Vue?
Because all interactivity is implemented by progressively enhancing Blazor Static Rendered pages with an ESM build of vue.min.js, which doesn't require any npm dependencies or any build tools. Vue.js is a dependency-free 60kb gzip download loaded directly by browsers using its native JavaScript Modules and Import Maps support, i.e. same approach DHH has moved to [1] for all his new Rails Apps precisely because it lets you develop modern Web Apps without any npm dependencies or build tools since it uses the Browsers native module support for loading JavaScript modules.
> That little example app you showed has ~3500 lines of JavaScript in it ...
https://blazordiffusion.com is an example of how you can build highly interactive Web Applications without ever needing to resort to Blazor Web Assembly or Blazor Server Sockets for any interactivity features. For a more traditional Web Application that's primarily server rendered, including a markdown powered Blog and Auto CRUD UIs which uses pockets of Vue.js for any components requiring interactivity, checkout a Live Demo of the empty (100% SSR) blazor-vue template [2]:
https://blazor-vue.web-templates.io
[1] https://world.hey.com/dhh/you-can-t-get-faster-than-no-build...
I find this rather strange. I can understand that people specialize, but it's not like typical application front-end or back-ends are rocket science and require a PhD or something. I have seen back-end developers create ugly, near unusable, user interfaces, and I have seen front-end developers write Hello, World!s that would deadlock. However, if both would take some time to pick up a few hints here and there, would they not turn into proficient full-stack developers?
Am I this misguided? Or is there another reason for these full-stack frameworks to never get the traction they deserve?
The parent comment asked:
> However, if both would take some time to pick up a few hints here and there, would they not turn into proficient full-stack developers?
...and the answer depends on what 'proficient' means to you.
Are you a small scale startup, prototyping, indie -> everyone does everything, when it fails, its not big deal. Then probably yes, that level of proficiency is ok.
However, at a larger scale, where failure has a tangible cost, is it ok if a 'fullstack' developer (ie. javascript dev) breaks the database and people can't buy things any more? What about if a DBA with a smattering of js makes it so that mobile safari doesn't work anymore and people can't login?
It's probably not OK.
If you want reliable output, you have to partition responsibility to people who know what they're doing.
That means specialization.
Of course, learning a smattering of other tools / technologies and ways of working is great for personal development, but at some point, someone has to be responsible for making sure that things don't explode.
...and, if you're prepared to be the guy responsible on paper for making sure no security incidents ever happen, that's cool if you have those skills; but it's fair to say that expecting a designer who spent 1/2 a day reading the OWASP website is maybe not the best choice for that role.
They are simply not an expert in that field.
It's not a matter of opinion; it's a matter of risk management. It is fundamentally risky not to partition responsibility to domain experts. Every company has to decide how to manage that risk... but it does exist; and companies that don't acknowledge it usually seem to suddenly be much more interested in it after they have an incident.
Don't be one of those companies.
However that doesn't mean I can't do JS/TS and manipulate DOM.
My point is, I've done front-end for most of my career without having to do design work.
These two things are completely tangential. Translating a design into well structured HTML/CSS should not require any UX or design experience. In the same way, you don’t need to know HTML/CSS to create a good design and UX.
You also need to distinguish between larger frameworks and compile-to-js/wasm languages here.
As for the rest, I think the bigger reason they don't get traction is that one one hand they don't work well for incremental adoption and on the other they introduction friction when integrating with the wider ecosystem. This hampers adoption for both new and established codebases.
If I am starting a greenfield project from scratch, I am likely working with uncertain/changing requirements and need to move fast. If I choose something like Blazor/Vaadin etc., I am not sure how much effort will be needed if I need to integrate a third party Gantt component, or a month calendar view, or a leaflet map etc. in future. Unless I am already super-sold on said language/tech, it is likely not the best use of my time to do a comprehensive evaluation right now because I don't entirely know the scope of the project - I'd rather want to spend that time building something minimal that I can push out and get some user feedback. But when the need arises I don't want to get locked into a scenario where suddenly I need to spend a few days dedicatedly writing a custom integration or manually declare types for a complex third party library. So I end up writing a TS SPA because every notable UI library at this point is known to work well with it.
In contrast, if I am evolving a brownfield project which already has quite a bit of legacy, I am constrained by the set of choices already made in past. Eg. I am likely not going to introduce a C# layer in a large java application to take advantage of blazor. It makes sense only if I have a C# app, and the frontend developers of said app (who may or may not be same as the backend developers) are equally enthusiastic about C#.
Even if I have multiple microservices and each of them can use whatever tech the maintainers of said service want, in order to use Blazor the team still has to be enthusiastic about adopting not just Blazor and C# but also the wider C# ecosystem including ORMs, caching, logging libraries etc. and all of that ends up being a substantial learning curve for a team with deadlines. Each of these constraints funnels down the developer subset likely to adopt this tech further down and down.
So all in all, adopting a large fullstack framework is not just a matter of willingness to learn - it is also about how much work I need to do for integrating third party libraries, how much does my write-compile-preview feedback time suffers, how may I have to adjust my dependency system, what other choices the said framework imposes upon me etc.
In contrast, if I want to try out a small self-contained reusable library/component it is much easier to incrementally adopt or experiment with in a new or old project.
Just like nowadays Spring and JakartaEE, alongside stuff like SAP Hybris and Adobe Experience Manager rule on the Java side.
Not everyone is doing conferences and putting code in github, and thankfully not everything is a SPA.
It's about learning C# .NET and working at the many, many companies who use .NET in some capacity for their various needs like desktop apps, data processing services, etc, and of course web with Blazor. I can take my existing skillset in C# .NET and apply it to many different things.
I find no lack of companies hiring C# .NET devs in the midwest.
JS replacements like Blazor clearly serve backend engineers who don't want to deal with JS. That's fine, and it's a valid way of developing, but it's clear that using JS with C# is a more holistic way of developing.
Doing nothing is not an option either, because that bites you in the ass as well because that newer Node runtime turns out not to support a deprecated md5 hash function the outdated Webpack in this project, which only gets a few weeks attention per year, relied on.
Now I only have Blazor for my frontend with a little bit of gulp to compile some dart-sass with design tokens and do some minification on some glue javascript.
I think the threat to Blazor is that productivity in general in organizations is not enough prioritized in comparison to dogmas or current trends. For example that now a days you “should” have a separate front end team and that front end team “loves” technology X (for example React).
This also depends on your backend engineers or whoever ends up maintaining the internal tools, are they comfortable using Blazor or not?
If you need frontend engineers and designers then going with React and the mainstream is wiser.
In fact that has happened, see JSIL (http://jsil.org/, which compiles .NET bytecode to JS) and also SharpKit (https://github.com/SharpKit/SharpKit which is built on Roslyn).
But this will not necessarily be any better than compiling to wasm. It avoids the .NET interpreter, which decreases the download, but it will still need to bundle a lot of library support code. And getting the language semantics exactly right - including features like C# finalizers which do not have direct support in JS - is tricky, unlike with wasm. And it won't benefit from the speed of the wasm implementation in AOT mode (which Blazor supports), which can be much faster than JS.
Compiling to JS definitely still makes sense in some cases, but it isn't an idea that Microsoft or the .NET community has somehow overlooked. It has been done and it has its own tradeoffs.
Like the article suggests right at the end, I want a C#-compile-to-wasm with new language structures for common web browser features such as shadow DOM. Perhaps also without the .NET core lump unless you really need it - and even then importing only the dependencies you need. I almost love Typescript but only because I spend my life wishing it was really C#.
Blazor looks cool but it's not quite native enough to client/server. I've been burnt by Silverlight and have a lots of ReactJS at work so the benefit isn't quite worth the cost and risk. I wonder if in a future role I might be tasked with a greenfield app for which it's a brilliant fit but I can't see that in any of the SME roles I've had so far.
It's wise to decouple the front and back-ends. Run away from tools that pretend you can do everything within one single framework. Run away from tools that make it more complicated to decouple both. Manage front and back separately. Develop them separately. If it takes a full article to explain a technology, it's probably too complicated.
Since other web frameworks struggle with performance optimizations for a decade (see Angular, React), Blazor seems like something you wouldn't pick unless you didn't care much about performance (mostly network traffic I suppose)
But for teams that already have invested in .NET and need to migrate desktop apps to the cloud, this seems pretty reasonable. There are millions of boring corporate apps that need something like that, and most of us work on those boring companies, rather than "on the edge" of tech...
Also it's much harder to reverese engineer WASM than de-obfuscate JS so maybe there's another use case for Blazor (and WASM in general)..?
I would not recommend using it for anything other than smaller applications where users are expected to have a steady connection though. But for smaller applications it’s a nice alternative, cutting some of the effort required to get an application out there.
I wonder what the practical scalability difference there is between streaming updates over a web-socket connection and streaming updates over a long-lived HTTP connection. It sounds like the same exact thing.
Hopefully it can keep the complexity of auto mode under the hood.. I don't think app devs want to deal with code that behaves differently depending on whether webassembly files are cached or not.
Performance:
Blazor WASM lags behind traditional JavaScript frameworks in terms of performance. The WebAssembly runtime is still generally slower than optimised JavaScript code for compute-intensive workloads.
I'm not using it in production yet for many of the reasons discussed in this article although I may revisit it again in .NET 8. The newest modes might actually push it over the top for applications that I develop. I wish there were no downsides because it just is so very nice to code in.
We then hired a front end architect who replaced all widgets with react components, changed our checkout to full CSR React, our latency raised for all users, we lost 5% conversion on checkouts that never recovered, then the next step was to build a React service to help render the React, and moved CSR React to SSR React service.
We now have 2 teams to support this. I get there are a list of other tradeoffs but I really miss JSPs.
1. Antivirus scans — it will take a lot more time for an antivirus to scan the tens of thousands of files in node_modules than whatever dotnet is doing. Especially on Windows
2. Corporate proxy support — the story of proxy support and importing custom certificates for the MITM proxy is still pretty much horrible (although improved since middle-2010s) in the Javascript ecosystem. dotnet is not perfect here and still has some warts in some specific tools, but much much better.
If you really want you can cut Defender out of the picture too: https://learn.microsoft.com/en-us/windows/dev-drive/#underst...
State management is pain in React, until you install 3rd party libraries (Jotai, Zustand etc.), each value needs to be bound individually.
Dotnet command line felt very snappy compared to npm/pnpm.On my crappy company laptop, when a nextjs application dev server starts, my blazor server app has already opened a browser tab with website running locally. efcore is also good.
Overall working with blazor felt like working with Vue/Svelte, but with faster performance on backend. Nowadays I only touch React if strictly necessary.
For the last year, amongst other things, we have been building a high-performance online trading platform using Blazor, Spring Boot and GCP. No insurmountable issues so far!
Tbh, I’ve never understood the appeal of server side blazor. High latency is too risky and you may never know that your clients are experiencing it. This hybrid approach in .net 8 is interesting but for a business app, initial load time is a once off thing and only a few seconds anyway. Kind of like an installer in a way.
I have a few criticisms though. I work almost exclusively on Linux now and it was extremely painful to try get an old .net project up and running because Microsoft aggressively sunset old .net versions. 4 years is not that long ago and I didn’t want to go through the pain of upgrading to the latest to make a few minor changes. So I had to dust off an old pc and use that. I understand that the .net core era was a turbulent time for change so maybe that’s why. But dammit, at least leave the old SDK’s up for a decade for this very reason!
Ironically, the slowest part of the system is the hosted sql server instance that is prohibitively expensive to run at a half decent speed with laughably low volumes of data. What a captured market that is when you can simply spin up a free PostgreSQL instance on the same vm and be done with it.
Anyway, to answer your question. Yes, it can be used in production. This one has 3 production instances and is used by about 30 people on a daily basis.
You can get .NET Framework 4.8 from the Visual Studio installer, no problem. It's not even marked as deprecated. If you know where to look, all the other versions are available, too.
==>> "As I reach the end of this blog post I want to finish on a positive note. I dare to say it, but could C# learn another thing from F#? Thanks to Fable, an F# to JavaScript transpiler, F# developers have been able to create rich interactive SPAs using F# for quite some time. Developed in 2016, Fable was originally built on top of Babel, an ECMAScript 2015+ to JavaScript compiler. Wouldn't something similar work for C#? As I see it this could pave the way for a very appealing C# framework that circumvents the complexities around WASM and SignalR."
https://github.com/theolivenbaum/h5
https://www.dice.com/career-advice/exploring-bridge-net-c-ja...
https://www.infoq.com/news/2015/02/duocode-csharp-javascript...
I wonder if the community just isn't interested in this approach.
The functional approach uses entire different structure. It isn't just a transpiler.
You can trivially build something that looks exactly like elm/elmish on top of blazor if you just organize your code that way.
Also, I like fable but you have to be careful about what .net features you use because it's transpiled and the standard library is reimplemented (there's lots of stuff that hasn't been implemented). Blazor has better compatibility and you can use pretty much anything in .net and even native code that has been compiled to WASM.
So 1) there's no good reason to abandon blazor for something more like fable in terms of being transpiled to javascript, since wasm will only be more mature, and 2) if you want something that looks more functional like f# with elmish you can easily get that on top of blazor.
(There is even something similar to fable/elmish on top of blazor for f# (Bolero) but you could do the same thing in c# too).
In the end I moved on, started working with Rails and not long ago we got Hotwire, which fares pretty well with Blazor, or Liveview...
Regardless, I’m pleased to see more contestants try to wrest mindshare away from JS culture. Cambrian explosion or something!
Then the user should be able to click a button and the additional text editor should disappear.
> Oh for that you need this custom language called hyperscript, it's so easy to get st...
no.
Like desktop app development in a browser or an actual good version of Silverlight.
There are some plans to support DOM directly from WASM, but at the pace Webassembly features get into the browsers, it is years away if it ever gets done.
The ability to run anything without having to do your own memory management is only just landing now (already in Chrome, next release of Firefox announced today and Safari as per usual is nowhere to be seen and is behind the curve again).
So when you think about what that very first generation of frameworks is going to even look like, it’s safe to say that most of them don’t yet exist.
The only one I know of is Flutter which is going all in on a path that’s genuinely independent of HTML and CSS and going straight to canvas and WebGPU via WASM.
But even that is still a few months away. Blazor takes an interesting approach in that it’s basically one foot in both camps in that it sticks to HTML/CSS and uses DOM rendering to handle the UI while still letting developers stick the overwhelming majority of their application logic in C#.