A lot of people seem to think that front-end and back-end developers are intrinsically different people. This would be the reason why full-stack frameworks (Kotlin for JavaScript, Scala.js, JavaScript backends, and now Blazor) never really take off.
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?
Yeah and then why don’t devs learn to administer their own databases as well. While they’re at it, writing some QA test cases can’t be all that hard. Continuous integration is pretty straightforward to set up so that as well. To be fair, it’s rather formulaic to come up with UI designs as well. Also security, load balancing and requirement docs just take a little dabbling to learn.
And are you hiring? Does your situation represent the bulk of available opportunities for developers looking for work? I think it's not, which is why these frameworks don't gain traction relative to javascript, which is portable to any backend stack.
Why stop there? Programmers are the ones most familiar with the software, they should be selling it. If they don’t have time they can hire more programmers, HR is easy… also they can automate the salary and procurement systems.
Here's a blunt truth: No one can be an expert at everything.
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.
They are worth while to learn but if you work for a corporation and they gradually cut people while loading you up with more and more work you’d get sour too.
That's my issue as well; over the years I've developed some insight in visual design and UX, but it's not my strong point and I don't want to be responsible for design. Luckily, I've always worked with designers and people who are better at CSS.
My point is, I've done front-end for most of my career without having to do design work.
> over the years I've developed some insight in visual design and UX … Luckily, I've always worked with designers and people who are better at CSS
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.
I don't know why you would consider JS/TS backends to be niche - they are fairly mainstream by this time.
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.
Because I can learn javascript, and work at myriad companies using any backend language. Or I can learn Blazor and work at the half dozen firms deploying it to production (maybe there are more in Europe).
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.
We've created the need front-end and back-end developer distinction by creating overly complex front-end build systems, and overly complex SPA frameworks.
I have the complete opposite view. I'm a fullstack dev, so I'm comfortable using Javascript and a backend language.
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.
I'm comfortable with Javascript. I'm not comfortable with constantly having to change and upgrade my code or build system for the next breaking change in Webpack or in an unreadable complex Typescript typing, or the spider web of React libraries.
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.
Despite working with .Net for decades, I've not jumped to blazor.
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.
I was helping to maintain an Adobe Flex system a few years back. It really sucks when your framework is simply obsolete like that. I don't know how to protect against that with the rate of change.
> there's been a hesitance to jump on MS web frameworks in fear of a repeat of silverlight.
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.
JavaFX never really became a thing, because even at Sun it had a bumpy start with the scripting based language before it got rebooted into Java, just before Sun went down.
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.
> 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.
And by the time Maui starts to mature and work, they will announce a new framework and the cycle starts again. I still don’t understand why they couldn’t keep working on WPF instead of cranking out a new framework every three years.
You can say that, but at the same time, whenever people complain about technology changing, leaving them behind, they usually mean tech by Microsoft.
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.
> 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.
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.
It's not just web frameworks - it's all MS UI frameworks. On the desktop there WinForms, WPF, UWP, WinUI, Blazor, MAUI... it's really seems like a mess with no clear direction.
I like .NET, and I believe Blazor represents an unique capability for that tech stack, but using Blazor essentially means eschewing all the traditional web stack tooling that was built up around TS/JS during the past decade for proprietary Microsoft weirdness.
Call it Blazor weirdness then. This obviously wasn’t a swipe at Microsoft being closed, just a point that Blazor stuff is not general standard web stuff.
Oh, me too. So much now-obsolete knowledge accumulated!
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.
> Flash was always going to die someday though, as HTML/JS caught up with it.
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.
Not if Adobe was developing it. Flash was terrible for performance and battery life, and it was wedded to the classic fixed-size window with a keyboard and mouse. Even Android users who had access hated it.
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 have to disagree. What you describe is every legacy stack and 20 years evolvement. Java with how many EE systems. JS with how many SPA frameworks. Python I know too little. Go/Rust are too young to have history.
Silverlight was an obvious bust from the beginning, no one with longevity in mind jumped on that ship and fought against anyone pitching it at the time (mostly inexperienced devs, sales people, and tech companies looking to make a quick buck). Anything plug-in based was already on the chopping block by the time it came out. Blazor WASM is, at least, as safe a bet as any popular JS framework. If .NET was still a Windows only thing, I'd stick with the JS frameworks, but now that it's cross platform, I've got no problem choosing Blazor over any other UI framework that just as easily might need a full rewrite in a few years.
I’ve worked with Blazor for about a year. It can be extremely productive for writing real internal business applications. “Backend” people can easily make interactive user interfaces and utilize their C# skills.
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).
That's my experience too, it's near perfect for internal tools like admin panels, where you don't necessarily need to hire dedicated front-end engineers. UI might be a bit ugly, but that's okay for internal use. Usually, admin panels end up having a weird assortment of buttons the real frontend doesn't even need, so creating REST API dedicated for that, and then React frontend to go with it is not time well spent.
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.
Although it is not that difficult for a front end dev to spend a week of time or so to create a custom styled component library in Blazor for your company and get things looking good and branded by default.
You might be confusing it with another part of ASP.NET Core like web APIs, which are generally super fast. Performance has never been a strong point for Blazor, except for the recent AOT support which has its own issues.
The article (which basically says Blazor is a bit cumbersome and pointless) has plenty of truth (and a few half-truths) to it but it's assuming that you're using it in a context where pure js + html would just be much better for the end user (wait, isn't pure native better for the end user..).
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.
Coming from the other side, this compatibility is why NodeJS is still very popular on the back-end. It makes sense for companies to try and stick to one programming language and / or ecosystem, else you end up with two disciplines within your company.
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.
Blazor is the definition of boring technology through and through. Use it in MVC mode and get ergonomics that date back to the early 2000s with a hiring pool so deep you can't ever find the bottom of it
Thanks for your feedback. It sounds like you are saying that Blazor was created mainly for internal corporate apps on their intranet, but I don't think that is quite what Microsoft envisions when they market Blazor. Perhaps that is where you concluded that Blazor has its only real place, possibly for the exact reasons which I've listed in the article?
> If you're replacing a shared spreadsheet cooked up by Tim on the data analytics team, how much does JS really matter.
I take your point, but from my experience replacing an internal spreadsheet which most non engineers know exactly how it works and does mostly everything they need/want with a custom SPA so 5 people in an organisation can do a task differently has never been a good use of developer resources or improved productivity.
People don't realize this. Blazor is about the developer. I am a `DevOps/Backend` guy and in my previous job some internal tools were made with Blazor.
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.
It's funny you're being downvoted, I've used Blazor on less important side projects and I love it for the same reasons, but a subset of HN hates it because their uBlock Origin no-Js anti-tracker cookieless oddball browsers choke on it.
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
No, people hate it because it's a massive downgrade in UX, especially the wasm variant, just because backend devs don't want to use the right tools for the job. I'm fine with it in internal apps, but public facing apps using blazor would be horrible for the users, which is why it is thankfully very rare to see.
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.
That's not how the right tool for the job works: the tool that results in the smallest bundle size and the most impressive web metrics is absolutely worthless if 99% of the value in what you're making is it existing and the creator of said tool doesn't feel like building out a SPA.
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.
Same role, this is exactly why have I kept myself focused on .NET and Java frameworks for Web development, or CMS in those platforms, and mostly leave SPA stuff for the FE team.
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.
Blazor Server is even better for corporate intranet applications. Building monitoring/operations apps is insanely easy when you can just connect your UI components directly to a singleton state on the backend. I wouldn't even consider anything else if my job was to make an app for a group of users who all sit in the same room.
Anyone tried Blazor in production? I checked it out (BRIEFLY) back when it was released, and it looked pretty cool - but there was really not a whole lot of info back then. It's been 4-5 years now, so I'm curious if anyone has actually integrated it into prod
I knocked up a quick prototype for a friend about 4 years ago (client side blazor wasm .net core 3.0) and he turned it into a successful small business. About 15 simple screens communicating with restful services all in one solution. He found some cheap developers to hack on it for some extra screens but he eventually unpicked their work. The amazing thing is the system is so simple that he, a someone new to programming, could make sense of it and change it without help. I took a look at it the other day and the entire app just ticks along without a problem.
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.
> But dammit, at least leave the old SDK’s up for a decade for this very reason!
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.
Downloading older builds remains an option, and scaffolding the environment for your chosen version is simplified by their scripts. I've successfully installed six versions, ranging from 2 to 8, side by side using this method.
I had quite a lot of faith in Blazor back in 2017, at the time I was still working mainly with C#, but then instead of getting better and more robust it went down the tangent of trying to do everything, all at once... But not in the "batteries-included" sense, instead more like in the bloated, unwieldy, and poorly documented.
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...
In my previous job, I was on a team using Vue.js for the frontend and ASP.NET Core for the backend. I quickly got tired of the internal plumbing, package management, build configuration, and all the other things not related to the actual functionality of the app that Vue (v2) required at the time. So, when I started my own company last year, I quickly jumped on Blazor Server, which has been an absolute joy from a developer productivity perspective.
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.
Isn't a Blazor application a giant blob of WASM/Javascript? I understand that Blazor is more designed for internal line-of-business applications that require porting to the web (and would otherwise be a .net application running on windows xp), but it seems pretty untenable to use it as a framework for the web.
It can be hosted by either WebAssembly or by the server (in which case the server will render the DOM and send diffs to the client over a WebSocket connection). Blazor Server probably isn't the best choice for a popular SaaS app, mainly because of its dependency on WebSocket connections and less-than-perfect reconnection logic.
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 - until .NET 8 - came in Blazor Server and Blazoe Webassembly variants.
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.
"The server also holds on to some state for each client"
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.
> This is a time bomb waiting to explode on the users and the developers.
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 quickly got tired of the internal plumbing, package management, build configuration, and all the other things not related to the actual functionality of the app that Vue (v2) required at the time.
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?
As a backend dev, I love the technology. The problem is that you have to choose between a not-so-scalable solution (Server, signalR) or a minimum 2mb initial payload (WASM) that can easily go to 5mb.
Interested on how many concurrent users you have for Server to be a problem. Can you elaborate more on your performance issues?
Is 5MB a real problems? Theoretically it may look big, but I have seen many websites much bigger, not to mention all video/image we download are already skewing download by a lot. Considering runtime is cached for long time, I don't see a real blocker. First page render would be an issue but SSR solves that.
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.
I may have made a mistake in designing the architecture of our app. Since we're a small team, I opted for a big ol' monolith, hosting our APIs on the same server as our Blazor Server app. We normally serve a few hundreds requests per second on our APIs, which is totally fine. However, sometimes we got some spikes up to thousands of requests per second, which has the unfortunate consequence that our Blazor Server app becomes laggy and starts to drop WebSocket connections frequently. So, now, we are in the process of moving our API controllers to another project, which will be hosted on a separate server.
Sounds like you did everything right then. Started off simple, now your business is taking off, failures aren't catastrophic (they're grey, not black, from what it sounds like) and splitting out a component shouldn't be too hard, so you'll be ready for more scale soon. All while maintaining the business!
.NET 8 solves that exact problem as far as I can see. You can opt into auto mode and it uses server side Blazor until the client downloads all assets, then in subsequent visits it uses the WASM runtime. Seems to be a good compromise.
> In my previous job, I was on a team using Vue.js for the frontend and ASP.NET Core for the backend. I quickly got tired of the internal plumbing, package management, build configuration, and all the other things not related to the actual functionality of the app that Vue (v2) required at the time.
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
In short, I think that .NET is pretty good, Vue is pretty good, but the JS ecosystem feels like it works well only sometimes, even for reasonably popular solutions. On that note, I'm all for trying out things like Blazor, but then again my past experiences with Java and something like JSP/JSF/PrimeFaces/Vaadin have soured my perspective a bit (which is also why I prefer to keep the front end decoupled from the back end as much as possible, sometimes to my own dismay).
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.
> 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
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.).
I spent a decade with C# and .Net and even in its current form which is easily the best it’s ever been I vastly prefer to work with Typescript.
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.
It seems a little disingenuous of you not to mention how I never hide the fact that it's an issue with the batteries. I'd also say that considering how great OData's patch is with the modelbuilder it's actually EF that's being bad in this case.
I enjoyed using ServiceStack. Write your data model in the C# API, run a tiny CLI command and it spits out Typescript definitions to match your data model.
I share your perspective. It is the most productive environment I have seen in many years. Blazor WASM for internal company applications, PWA or Blazor Hybrid (basically Cordova/Electron Shell just with C#) is just awesome.
I share the article's fear of overloading the technology, but do not see it overall that negative.
> 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.
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.
In my experience, long polling is more stable and you can enable transfer compression. Maybe it would be good in Blazor to disable the persistent connection completely, having only requests and responses. Often we just want to call a backend method and update the view in response.
Strange discussion here. I'm a developer in everything for 20 years and the last 7 probably in large JS/TS applications.
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.
The whole discussion around why a .NET shop might choose Blazor over Javascript ecosystem misses these critical things when it comes to developer experience:
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.
Windows Defender handles node_modules fine, and if you're dumb enough to choose something other than Windows Defender on ... Windows ... that's on you.
Sorry, but you seem to be missing the context here — this is an environment where these kind of decisions are not made by the developers, but are in the hands of other departments. So the choice of antivirus or other corpoware or disabling the antivirus is not something that the development team has any say in.
Yes, how dumb of me to not make a completely weird request to interview the corporate IT department of my job after I had been laid off for two months and was struggling to find anything in my area.
If antivirus scanners come up at any point when the topic is things that are "critical" to the developer experience (let alone as the very first thing), that's a really telling baseline—the tip of the iceberg as far as indicators of organizational dysfunction go. You might as well be speaking from a place where every employee starts the day with a nailgun fired through the palm of their hand and then they spend their time gushing over lunch about how Acme Co. has the best woodsaws out of all the woodsaws because theirs are the ones that let you really get in there and cut away most of the plank—so you're just walking around with a medium chunk of wood fixed to the back of your hand, of course, instead of the whole board. Nuts.
Not sure that I follow... From what I have understood, a lot of corporations have these kind of set ups in place to avoid downloading malicious software, limit the possible impact of malware, monitor employees and so on. And it is clear that no development team can change policy for whole organization — so why shouldn't developers choose the kind of tooling which allows them to deliver within the constraints of the organization?
You are taking it as a given that developers are making these choices at organizations where it is normal for them to have to fire a nailgun through the palms of their hands at the beginning of the day. I'm saying that when developers are making these choices they should be doing so at organizations where it is a given that they don't have to do that.
It is impossible currently, as WASM only allows for compute, everything else relies on the host, and exported functions to be called by the WASM code.
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.
Probably worth keeping in mind where WASM itself actually is.
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#.
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)..?
At a previous job we adopted Blazor WASM in order to rewrite an interal React-based app that was basically a hardware test ticketing system + asset tracker. It was very productive, ended up feeling more responsive to users (after the initial page load which was definitely worse) and allowed us to share some code from the WPF app it integrated with. Adding more complex features was much easier than it would have been with React (the years of C# experience on the team was much higher than the JS/TS experience).
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 take the opposite view, as a recent Blazor convert since the just released .NET 8 we're now recommending Blazor for any new .NET Web App (excl. CDN Hostable, SSG websites).
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].
Very interesting, and the first time I might have been nearly sold on it. Maybe next new project I'll try it out.
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.
> 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.
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]:
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.
Almost correct. compute-intensive workloads are (often/theoretically) faster in wasm, but the horrible js marshaling which is still required kills most/all benefits. Current wasm GC implementations don't fix this.
I'll take this opportunity to plug one of my personal projects, a graphical (node-based) regex editor written Blazor WASM: https://github.com/jcparkyn/nodexr
===>>> YES. It takes a bit to wrap your head around, but functional programming is actually very good for UI's.
==>> "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."
There actually are several C# to JavaScript transpilers out there but none are well-maintained with a strong following (compared to Fable). Some examples are...
It's not really different. If you use .razor files it hides the way state mutation works so it superficially looks more imperative (I guess so it isn't scary to people who are used to server rendered razor templates in asp.net) but it's basically the same as MVU/react/elmish/whatever in f#/fable just without explicit update messages.
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).
Trying to program the web front end like you do the API backend feels like an antipattern. I'm all for productivity but you eventually hit issues that cannot be resolved because the client/serverness of your solution has been abstracted away from you. Those of us with WebForms scars remember those days.
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.
I believe there is a simple lesson to be learned from all ambitious frameworks of the past that now lie in ruins covered in sand.
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.
There was a sort of a equivalent - GWT. And it was really good and ahead of the time: it covered intermediate API out of the box, provided quite nice way to develop FE in plain Java, it was async, it allowed common BE and FE codebase.
Having maintained both JavaScript SPAs and Blazor apps for the past 4 years, I disagree with the article's point about Blazor being more complex. I've had way more issues keeping JS tooling running and having to spend time fixing issues when I upgrade packages. Things really get fun when you have to produce an SBOM for security audit. You can generally get by with way fewer dependencies in a Blazor app and the build process starts simple and can get as complex as you want it to be.
Another point not mentioned in the article is that Blazor can also run directly on local hardware - desktop or mobile. This doesn't use WASM or web sockets and runs at full native speed. This is a big deal where I work since we can run the exact same UI on kiosks as well as on a web site, with essentially the backend swapped out.
In the one illustration, there's just an extra disembodied hand sitting on the one guy's laptop. Another one has one finger branching from another instead of connecting to the palm. Is your illustrator okay?
I used Blazor Server to build a hobby project of mine [1] and must say I am pleasantly surprised. Not having to build a separate client and duplicating code and models is really nice. I use my project daily and it is surprisingly fast to use, and the dropped connection does not bother me too much.
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.
301 comments
[ 2.4 ms ] story [ 185 ms ] threadI 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.
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 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.
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)
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.
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.
https://dotnet.microsoft.com/en-us/download/dotnet
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...
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:
In short, I think that .NET is pretty good, Vue is pretty good, but the JS ecosystem feels like it works well only sometimes, even for reasonably popular solutions. On that note, I'm all for trying out things like Blazor, but then again my past experiences with Java and something like JSP/JSF/PrimeFaces/Vaadin have soured my perspective a bit (which is also why I prefer to keep the front end decoupled from the back end as much as possible, sometimes to my own dismay).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.
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.
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...
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#.
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 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
[2] https://blazordiffusion.com
[3] https://github.com/NetCoreApps/BlazorDiffusionVue
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...
[2] https://github.com/NetCoreTemplates/blazor-vue
==>> "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...
http://jsil.org
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).
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.
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.
[1] https://github.com/eliasson/quarter