22 ms·

.NET Blazor

308 points by dustedcodes 3y ago

smokel 3y ago
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?
- huytersd 3y ago
  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.
  - siquick 3y ago
    There are many of us working at smaller companies who do all of the above.
    - ttymck 3y ago
      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.
      - siquick 3y ago
        That was not the context the OP was addressing.
  - catmanjan 3y ago
    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.
  - throwuxiytayq 3y ago
    What a weird post. How is that not your actual attitude? All of these things are worthwhile to learn. (I'm assuming you're being sarcastic.)
    - wokwokwok 3y ago
      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. Don't be one of those companies.
    - huytersd 3y ago
      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.
  - yread 3y ago
    Being a solo founder is then completely impossible for you, right? Cause you need to throw in fund raising, accounting, marketing, sales and hiring
- superb_dev 3y ago
  Some people just don’t enjoy front end work, and vice versa
  - jve 3y ago
    Frontend implies layout which I ain't good at. More less come up with design myself. The result isn't pretty, but functional. However that doesn't mean I can't do JS/TS and manipulate DOM.
    - cm2187 3y ago
      Front is also very tedious. Lots of reinventing the wheel every time, obscure css bugs, etc.
    - Cthulhu_ 3y ago
      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.
      - _gabe_ 3y ago
        > 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.
        UK-AL 3y ago
        I think sometimes there's often gaps where you have to fill in for the designer.
- lf-non 3y ago
  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.
- pjmlp 3y ago
  WebForms took off in the enterprise space, JSF as well, and now Blazor is basically the upgrade path fro WebForm folks. 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.
- ttymck 3y ago
  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).
  - SirMaster 3y ago
    It's not about learning Blazor per say. 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.
- deleted 3y ago
  [deleted]
- mhfu 3y ago
  [dead]
- pacifika 3y ago
  Picking up full stack is a long way from innovating in it.
  - sebazzz 3y ago
    Innovation in the technology is not something every company has to do.
- sebazzz 3y ago
  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.
  - Capricorn2481 3y ago
    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.
    - sebazzz 3y ago
      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.
      - Capricorn2481 3y ago
        Why are you using md5 functions on the frontend? We're talking about using javascript for frontend
        sebazzz 3y ago
        Read again, Webpack used that.
        Capricorn2481 3y ago
xnorswap 3y ago
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.
- xupybd 3y ago
  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.
- jsiepkes 3y ago
  > 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.
  - 3y ago
havkom 3y ago
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).
- Ciantic 3y ago
  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.
  - havkom 3y ago
    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.
jimsimmons 3y ago
I thought it was one of the fastest web frameworks but this article completely destroys that image. What gives
- jcparkyn 3y ago
  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.
webprofusion 3y ago
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.
- Cthulhu_ 3y ago
  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/ 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.
  - BoorishBears 3y ago
    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
    - banashark 3y ago
deleted 3y ago
[deleted]
TrackerFF 3y ago
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
- davidhyde 3y ago
  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.
  - moron4hire 3y ago
    > 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.
pelagicAustral 3y ago
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...
sebastianbk 3y ago
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.
- xupybd 3y ago
  As someone in New Zealand that's crazy. The ping to Europe is terrible. To the point that video calls to the UK are painful.
  - chrisdbanks 3y ago
    I regularly have video calls from the UK to NZ with no issues at all. Might be your provider.
- madeofpalk 3y ago
  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.
_s_a_m_ 3y ago
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.
- tcfhgj 3y ago
  It's fast if you have fast internet and CPUs. 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.
- deleted 3y ago
  [deleted]
bragh 3y ago
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.
- taspeotis 3y ago
  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. If you really want you can cut Defender out of the picture too: https://learn.microsoft.com/en-us/windows/dev-drive/#understanding-security-risks-and-trust-in-relation-to-dev-drive https://learn.microsoft.com/en-us/windows/dev-drive/#underst...
  - bragh 3y ago
    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.
    - taspeotis 3y ago
      I hassled my IT guys to get rid of Symantec Endpoint Protection on my PC and leave me with Defender. You can too.
      - moron4hire 3y ago
        Trust me, there are environments in which you can't. Keywords: "DoD" and "consulting".
ChicagoDave 3y ago
I honestly thought some version of WASM would be popular, performant, and easy to use by now, and not reliant on js/html/css. Like desktop app development in a browser or an actual good version of Silverlight.
- pjmlp 3y ago
  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.
- mdhb 3y ago
  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#.
ktsangop 3y ago
Nice article, very well researched. 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)..?
BitterAmethyst 3y ago
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.
mythz 3y ago
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]. [1] https://servicestack.net/posts/net8-best-blazor https://servicestack.net/posts/net8-best-blazor [2] https://blazordiffusion.com https://blazordiffusion.com [3] https://github.com/NetCoreApps/BlazorDiffusionVue https://github.com/NetCoreApps/BlazorDiffusionVue
- jddj 3y ago
  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.
  - mythz 3y ago
    > 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 https://servicestack.net/auto-ui [2] https://docs.servicestack.net/releases/v6_07#new-locode-api-explorer-admin-uis-now-in-vue-3 https://docs.servicestack.net/releases/v6_07#new-locode-api-...
lostmsu 3y ago
I expected something to back the claims in the article, but found none. For instance, there are no performance numbers.
- oaiey 3y ago
  I think the mentioned performance aspects are quite believable and are well recognized without the need to show evidence. Even for mean as a fanboy.
singularity2001 3y ago
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.
jcparkyn 3y ago
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 https://github.com/jcparkyn/nodexr
- banashark 3y ago
  Very cool project!
FrustratedMonky 3y ago
===>>> 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."
- mastry 3y ago
  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... https://github.com/theolivenbaum/h5 https://github.com/theolivenbaum/h5 https://www.dice.com/career-advice/exploring-bridge-net-c-javascript https://www.dice.com/career-advice/exploring-bridge-net-c-ja... https://www.infoq.com/news/2015/02/duocode-csharp-javascript/ https://www.infoq.com/news/2015/02/duocode-csharp-javascript... http://jsil.org http://jsil.org I wonder if the community just isn't interested in this approach.
  - FrustratedMonky 3y ago
    It is far beyond just using C# to javascript. That would just maintain the same way of thinking. The functional approach uses entire different structure. It isn't just a transpiler.
    - resoluteteeth 3y ago
      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).
brainwipe 3y ago
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.
rbanffy 3y ago
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.
zyl1n 3y ago
As a java backend dev, I am envious that Java doesn't have a modern equivalent of Blazor.
- kmac_ 3y ago
  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.
nu5500 3y ago
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.
Tao3300 3y ago
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?
- peheje 3y ago
  I smelled AI on the first Frankenstein image. I'm sure it's AI, look at how the needles (bottom 3/4' column) melt together with the vial holder.
eliasson 3y ago
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. [1] https://github.com/eliasson/quarter https://github.com/eliasson/quarter
jadbox 3y ago
Honestly I'm pretty happy with just the stack: server html jsx templates + htmx boost + css view transitions. It's simple, easy to troubleshoot, fast to build, and crucially provides most of the important benefits of a SPA (seamless updates) without hardly any frontend JS.
- patates 3y ago
  Wanted to give htmx a try. I have a form, in which multiple text editors can be added. Apparently here we need an endpoint to deliver the extra field and I can tell htmx where to append it, so some extra work but okay. Then the user should be able to click a button and the additional text editor should disappear. > Oh for that you need this custom language called hyperscript, it's so easy to get st... no.
  - citizenkeen 3y ago
    You don't need hyperscript, you can just do it with Javascript.
    - patates 3y ago
      If I'm writing JS for something as simple as removing an element, then I can keep writing. Alpine.js would make more sense in that case.
kumarvvr 3y ago
All the dis-advantages are not relevant for enterprise LOB apps, which Blazor is best suited for. Millions of .NET developers across the enterprise world are heaving a sigh of relief to never have to touch JS and be cozy and comfortable in their .NET ecosystem. With the latest addition of fully SSR, Blazor is also well suited for CMS, Blogs, Content Mills, small web apps, portfolio sites, etc. But, as a developer who has done exactly one complex web app for a client, let me tell you, the ability to use C# models, directly from your domain, in web app markup code, using Razor components is a god send. I don't have to maintain the cognitive overhead of translating domain models into JSON models and vice versa.
- louthy 3y ago
  It's still relevant when MS decide to drop it and focus on yet another new shiny web-framework, like the 10 - or whatever number previous they've built - in the past 20 years. And, let's face it, they're not very good at it. If they were they wouldn't need to shelve so many previous attempts. Or, they decide to completely upend the entire ecosystem (Framework → Core) which then makes all previous web-frameworks (built by them) defunct. Enterprises with sense would either roll their own, that they can then have complete control of forever, or try and find a framework that has staying power (although I realise even that is difficult). I think running C# in the browser has benefits, for sure, but they should just stick to making that. And get out of the web-framework game for good to allow the community to create something exceptional - and, you know, play nice with others (other frameworks).
  - kumarvvr 3y ago
    When it comes to web, MS has been focused on ASP.NET since forever. With evolution of the web, ASP.NET too has evolved quite a bit. Building a simple web app with Razor pages is incredibly easy and the output is fast and scalable. Their WebAPI in ASP.NET is very good. Blazor is an additional way to do web apps, but very much in line with the structure and core of ASP.NET. In the desktop world, MS has jumped a lot of hoops, mostly because there is no one to chide them on their own platform. But the web is different.
klysm 3y ago
I had a terrible time with blazor. It’s semantics are clunky
bsuvc 3y ago
Here is my personal experience. I've been working on a large-ish Blazor (Server) application for about a year. The choice to use Blazor was not mine, but I went into it with an open mind. For context, I have used React and Angular in the past. I will never used Blazor again. Performance is not good, with CPU always at some base level, even when idle. My machines fan is always cranking while developing it. Hot reload does not work consistently (on like 25% of the time), and when it does, it is slow, so it might as well not work at all. Everything in Blazor just feels half-baked. I'm old enough to remember things like "ActiveX Documents" and Silverlight, where were other attempts by Microsoft to provide a way for people not to have to learn and use a proper front end framework, and I think Blazor will end up on the scrap heap with them. Microsoft has a bad habit of touting the next big thing for developers to use and then abandoning it several years later. This feels like that to me.
- andsoitis 3y ago
  > a proper front end framework Do you think a WASM approach has merit or do you think it is doomed?
  - bsuvc 3y ago
    Not sure. We haven't used the WASM version, but it is possible that it works better. I still think there is a rug-pull risk by Microsoft, so not sure I would choose it for that reason alone.
  - kittoes 3y ago
    Am using Blazor WASM in our shop and absolutely loving it once deployed. The hot reload and other development headaches are -really- painful, but just being able to use our existing C# libraries everywhere has been a game-changer for us.
- isbvhodnvemrwvn 3y ago
  Sounds a bit like Adobe Flex.
- avgDev 3y ago
  I have a large blazor project and do not have fan cranking at all. Hot reload is VS issue. I have a completely difference experience but then again I'm creating business apps and do not anything 'new'.
TheRealDunkirk 3y ago
This feels like a move to be more like Rails, and I'm there for it. The problem with Microsoft is that, every time I think, hey, this new thing might be useful for such-and-such kind of app or problem, by the time I get around to trying to use it, they've moved on to something else.
azakai 3y ago
At the very end of the blogpost the author asks why not compile C# to JavaScript, like F# (Fable) does? The author thinks that would be the best solution overall, and is surprised it has not happened yet. In fact that has happened, see JSIL (http://jsil.org/ http://jsil.org/, which compiles .NET bytecode to JS) and also SharpKit (https://github.com/SharpKit/SharpKit https://github.com/SharpKit/SharpKit which is built on Roslyn). But this will not necessarily be any better than compiling to wasm. It avoids the .NET interpreter, which decreases the download, but it will still need to bundle a lot of library support code. And getting the language semantics exactly right - including features like C# finalizers which do not have direct support in JS - is tricky, unlike with wasm. And it won't benefit from the speed of the wasm implementation in AOT mode (which Blazor supports), which can be much faster than JS. Compiling to JS definitely still makes sense in some cases, but it isn't an idea that Microsoft or the .NET community has somehow overlooked. It has been done and it has its own tradeoffs.
girafffe_i 3y ago
I miss SSR JSPs. I worked on a b2b2c marketplace, the caching and performance of SSR for routine pages was a godsend. We also used a "widget" architecture pattern with reusable components. We then hired a front end architect who replaced all widgets with react components, changed our checkout to full CSR React, our latency raised for all users, we lost 5% conversion on checkouts that never recovered, then the next step was to build a React service to help render the React, and moved CSR React to SSR React service. We now have 2 teams to support this. I get there are a list of other tradeoffs but I really miss JSPs.
poszlem 3y ago
Tangentially to the topic of the blogpost, has anyone else noticed that many recent articles on Hacker News feature AI-generated illustrations? They seem to have a unique, AI-specific style and that weird "uncanny valley" like quality where you can easily tell it was, in fact, a machine generated thing?
- dustedcodes 3y ago
  I used DALL-E 3 to generate the images. I always wanted to include more images in my blog posts, because I personally (and I might be wrong) feel like it sometimes helps to better tell a story or explain a sentiment which you hold as the author. But as a hobby blogger you don't get to have nice illustrations or graphics without paying an arm and leg for something which is just a free blog post. So yeah, I used AI for it and I love it. Also I'm not a native English speaker and I'll admit that I use AI a lot in recent months where I type up my badly worded text ridden with a lot of grammar mistakes and then feed it into a prompt to help me smoothen things out. I actually think I'd be stupid not to do it and I don't see it much different to a book author writing a book and then sending the script to a team of editors who do exactly the same thing, just that now it's a computer doing it faster. I have no shame in admitting this :)
withinrafael 3y ago
I find it hard to justify/invest the time needed to really dig into Blazor. Everywhere I go/look, buisnesses are stuck on mature solutions utilizing ASP.NET MVC 4 or 5 + Entity Framework (non-core). Just upgrading beyond that requires a lot of migration work, let alone rearchitecting for the new and shiny Blazor.
johnfn 3y ago
This article is really odd. The long lists of disadvantages feel a lot like the lists of disadvantages that ChatGPT produce, where relevant disadvantages will be placed right next to things that are wildly inapplicable to whatever I'm doing. And the whole list is extremely impersonal - there isn't a single reference to the product(s) that the author worked on, so it's impossible to tell if the downsides are even real downsides or not.
JohannesH 3y ago
I'm still weary of using Blazor in anything serious/long term. I've been burnt before by MS, leaving me with a tech that's both hard to continue using and hard to get rid of if need be.
jmull 3y ago
Seems like an awful lot of complexity and significant compromises just to get to use C# instead of TS or JS. I wonder what the practical scalability difference there is between streaming updates over a web-socket connection and streaming updates over a long-lived HTTP connection. It sounds like the same exact thing. Hopefully it can keep the complexity of auto mode under the hood.. I don't think app devs want to deal with code that behaves differently depending on whether webassembly files are cached or not.
- barryrandall 3y ago
  People are willing to compromise and put up with a lot of complexity if it gets them out of having to engage with JavaScript and its supporting ecosystems.
wvenable 3y ago
I think that's missing from this discussion is why so much effort is being put into Blazor. Why would anyone use or even build a framework with 4 rendering modes? The answer is that the on the ground developer experience of writing interactive applications in Blazor is extremely nice. In an ideal world, Blazor feels like how web development should be. If you've never used it then you'll have no idea what I mean. I'm not using it in production yet for many of the reasons discussed in this article although I may revisit it again in .NET 8. The newest modes might actually push it over the top for applications that I develop. I wish there were no downsides because it just is so very nice to code in.
psadri 3y ago
Shameless plug: https://skymass.dev https://skymass.dev is a js/ts version of Blazor. It is a batteries-included, code-first solution for creating high quality business web apps by simply writing a single-dependency backend process. Please be gentle as it’s in beta.
grounder 3y ago
Trying to understand Blazor better. Is it a similar idea to what GWT tried to do with Java?
mattgreenrocks 3y ago
Curious to try SSR to see if it can dethrone SvelteKit for me. SK is pretty great, though the backend side feels under-baked a bit compared to FastAPI. Regardless, I’m pleased to see more contestants try to wrest mindshare away from JS culture. Cambrian explosion or something!
tankmohit11 3y ago
I develop company's internal tooling using Blazor Server, and have developed moderately complex and data intensive applications. As a former React Developer who has spent most of his time working with Node.js and JavaScript tooling, Using Blazor WA and Server felt like a breath of fresh air. C# is joy to write and everything fits very well with existing enterprisy Microsoft services. State management is pain in React, until you install 3rd party libraries (Jotai, Zustand etc.), each value needs to be bound individually. Dotnet command line felt very snappy compared to npm/pnpm.On my crappy company laptop, when a nextjs application dev server starts, my blazor server app has already opened a browser tab with website running locally. efcore is also good. Overall working with blazor felt like working with Vue/Svelte, but with faster performance on backend. Nowadays I only touch React if strictly necessary.
zawarq 3y ago
A couple of observations: Blazor plays well with any back-end technology, not just a .NET server-side. That should be a no-brainer for developers, but its an assurance that non-devs need. Secondly, performance issues apart, JS-interop is really easy to pull off. That is good news for the non-puritan, pragmatic programmer. We understand that it will take a while before Blazor libraries catch up to the large number of options available for Angular and React. Until then, Blazor + JS-interop is a great solution that covers all scenarios in the vast majority of cases. For the last year, amongst other things, we have been building a high-performance online trading platform using Blazor, Spring Boot and GCP. No insurmountable issues so far!

308 points by dustedcodes 3y ago

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?

huytersd 3y ago
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.
- siquick 3y ago
  There are many of us working at smaller companies who do all of the above.
  - ttymck 3y ago
    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.
    - siquick 3y ago
      That was not the context the OP was addressing.
- catmanjan 3y ago
  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.
- throwuxiytayq 3y ago
  What a weird post. How is that not your actual attitude? All of these things are worthwhile to learn. (I'm assuming you're being sarcastic.)
  - wokwokwok 3y ago
    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. Don't be one of those companies.
  - huytersd 3y ago
    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.
- yread 3y ago
  Being a solo founder is then completely impossible for you, right? Cause you need to throw in fund raising, accounting, marketing, sales and hiring
superb_dev 3y ago
Some people just don’t enjoy front end work, and vice versa
- jve 3y ago
  Frontend implies layout which I ain't good at. More less come up with design myself. The result isn't pretty, but functional. However that doesn't mean I can't do JS/TS and manipulate DOM.
  - cm2187 3y ago
    Front is also very tedious. Lots of reinventing the wheel every time, obscure css bugs, etc.
  - Cthulhu_ 3y ago
    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.
    - _gabe_ 3y ago
      > 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.
      - UK-AL 3y ago
        I think sometimes there's often gaps where you have to fill in for the designer.
lf-non 3y ago
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.
pjmlp 3y ago
WebForms took off in the enterprise space, JSF as well, and now Blazor is basically the upgrade path fro WebForm folks. 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.
ttymck 3y ago
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).
- SirMaster 3y ago
  It's not about learning Blazor per say. 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.
deleted 3y ago
[deleted]
mhfu 3y ago
[dead]
pacifika 3y ago
Picking up full stack is a long way from innovating in it.
- sebazzz 3y ago
  Innovation in the technology is not something every company has to do.
sebazzz 3y ago
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.
- Capricorn2481 3y ago
  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.
  - sebazzz 3y ago
    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.
    - Capricorn2481 3y ago
      Why are you using md5 functions on the frontend? We're talking about using javascript for frontend
      - sebazzz 3y ago
        Read again, Webpack used that.
        Capricorn2481 3y ago

xnorswap 3y ago

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.

xupybd 3y ago
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.
jsiepkes 3y ago
> 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.
- 3y ago

havkom 3y ago

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).

Ciantic 3y ago
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.
- havkom 3y ago
  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.

jimsimmons 3y ago

I thought it was one of the fastest web frameworks but this article completely destroys that image. What gives

jcparkyn 3y ago
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.

webprofusion 3y ago

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.

Cthulhu_ 3y ago
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/ 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.
- BoorishBears 3y ago
  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
  - banashark 3y ago

deleted 3y ago

[deleted]

TrackerFF 3y ago

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

davidhyde 3y ago
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.
- moron4hire 3y ago
  > 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.

pelagicAustral 3y ago

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...

sebastianbk 3y ago

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.

xupybd 3y ago
As someone in New Zealand that's crazy. The ping to Europe is terrible. To the point that video calls to the UK are painful.
- chrisdbanks 3y ago
  I regularly have video calls from the UK to NZ with no issues at all. Might be your provider.
madeofpalk 3y ago
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.

_s_a_m_ 3y ago

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.

tcfhgj 3y ago
It's fast if you have fast internet and CPUs. 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.
deleted 3y ago
[deleted]

bragh 3y ago

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.

taspeotis 3y ago
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. If you really want you can cut Defender out of the picture too: https://learn.microsoft.com/en-us/windows/dev-drive/#understanding-security-risks-and-trust-in-relation-to-dev-drive https://learn.microsoft.com/en-us/windows/dev-drive/#underst...
- bragh 3y ago
  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.
  - taspeotis 3y ago
    I hassled my IT guys to get rid of Symantec Endpoint Protection on my PC and leave me with Defender. You can too.
    - moron4hire 3y ago
      Trust me, there are environments in which you can't. Keywords: "DoD" and "consulting".

ChicagoDave 3y ago

I honestly thought some version of WASM would be popular, performant, and easy to use by now, and not reliant on js/html/css. Like desktop app development in a browser or an actual good version of Silverlight.

pjmlp 3y ago
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.
mdhb 3y ago
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#.

ktsangop 3y ago

Nice article, very well researched. 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)..?

BitterAmethyst 3y ago

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.

mythz 3y ago

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]. [1] https://servicestack.net/posts/net8-best-blazor https://servicestack.net/posts/net8-best-blazor [2] https://blazordiffusion.com https://blazordiffusion.com [3] https://github.com/NetCoreApps/BlazorDiffusionVue https://github.com/NetCoreApps/BlazorDiffusionVue

jddj 3y ago
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.
- mythz 3y ago
  > 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 https://servicestack.net/auto-ui [2] https://docs.servicestack.net/releases/v6_07#new-locode-api-explorer-admin-uis-now-in-vue-3 https://docs.servicestack.net/releases/v6_07#new-locode-api-...

lostmsu 3y ago

I expected something to back the claims in the article, but found none. For instance, there are no performance numbers.

oaiey 3y ago
I think the mentioned performance aspects are quite believable and are well recognized without the need to show evidence. Even for mean as a fanboy.

singularity2001 3y ago

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.

jcparkyn 3y ago

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 https://github.com/jcparkyn/nodexr

banashark 3y ago
Very cool project!

FrustratedMonky 3y ago

===>>> 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."

mastry 3y ago
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... https://github.com/theolivenbaum/h5 https://github.com/theolivenbaum/h5 https://www.dice.com/career-advice/exploring-bridge-net-c-javascript https://www.dice.com/career-advice/exploring-bridge-net-c-ja... https://www.infoq.com/news/2015/02/duocode-csharp-javascript/ https://www.infoq.com/news/2015/02/duocode-csharp-javascript... http://jsil.org http://jsil.org I wonder if the community just isn't interested in this approach.
- FrustratedMonky 3y ago
  It is far beyond just using C# to javascript. That would just maintain the same way of thinking. The functional approach uses entire different structure. It isn't just a transpiler.
  - resoluteteeth 3y ago
    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).

brainwipe 3y ago

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.

rbanffy 3y ago

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.

zyl1n 3y ago

As a java backend dev, I am envious that Java doesn't have a modern equivalent of Blazor.

kmac_ 3y ago
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.

nu5500 3y ago

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.

Tao3300 3y ago

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?

peheje 3y ago
I smelled AI on the first Frankenstein image. I'm sure it's AI, look at how the needles (bottom 3/4' column) melt together with the vial holder.

eliasson 3y ago

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. [1] https://github.com/eliasson/quarter https://github.com/eliasson/quarter

jadbox 3y ago

Honestly I'm pretty happy with just the stack: server html jsx templates + htmx boost + css view transitions. It's simple, easy to troubleshoot, fast to build, and crucially provides most of the important benefits of a SPA (seamless updates) without hardly any frontend JS.

patates 3y ago
Wanted to give htmx a try. I have a form, in which multiple text editors can be added. Apparently here we need an endpoint to deliver the extra field and I can tell htmx where to append it, so some extra work but okay. Then the user should be able to click a button and the additional text editor should disappear. > Oh for that you need this custom language called hyperscript, it's so easy to get st... no.
- citizenkeen 3y ago
  You don't need hyperscript, you can just do it with Javascript.
  - patates 3y ago
    If I'm writing JS for something as simple as removing an element, then I can keep writing. Alpine.js would make more sense in that case.

kumarvvr 3y ago

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

louthy 3y ago
It's still relevant when MS decide to drop it and focus on yet another new shiny web-framework, like the 10 - or whatever number previous they've built - in the past 20 years. And, let's face it, they're not very good at it. If they were they wouldn't need to shelve so many previous attempts. Or, they decide to completely upend the entire ecosystem (Framework → Core) which then makes all previous web-frameworks (built by them) defunct. Enterprises with sense would either roll their own, that they can then have complete control of forever, or try and find a framework that has staying power (although I realise even that is difficult). I think running C# in the browser has benefits, for sure, but they should just stick to making that. And get out of the web-framework game for good to allow the community to create something exceptional - and, you know, play nice with others (other frameworks).
- kumarvvr 3y ago
  When it comes to web, MS has been focused on ASP.NET since forever. With evolution of the web, ASP.NET too has evolved quite a bit. Building a simple web app with Razor pages is incredibly easy and the output is fast and scalable. Their WebAPI in ASP.NET is very good. Blazor is an additional way to do web apps, but very much in line with the structure and core of ASP.NET. In the desktop world, MS has jumped a lot of hoops, mostly because there is no one to chide them on their own platform. But the web is different.

klysm 3y ago

I had a terrible time with blazor. It’s semantics are clunky

bsuvc 3y ago

Here is my personal experience. I've been working on a large-ish Blazor (Server) application for about a year. The choice to use Blazor was not mine, but I went into it with an open mind. For context, I have used React and Angular in the past. I will never used Blazor again. Performance is not good, with CPU always at some base level, even when idle. My machines fan is always cranking while developing it. Hot reload does not work consistently (on like 25% of the time), and when it does, it is slow, so it might as well not work at all. Everything in Blazor just feels half-baked. I'm old enough to remember things like "ActiveX Documents" and Silverlight, where were other attempts by Microsoft to provide a way for people not to have to learn and use a proper front end framework, and I think Blazor will end up on the scrap heap with them. Microsoft has a bad habit of touting the next big thing for developers to use and then abandoning it several years later. This feels like that to me.

andsoitis 3y ago
> a proper front end framework Do you think a WASM approach has merit or do you think it is doomed?
- bsuvc 3y ago
  Not sure. We haven't used the WASM version, but it is possible that it works better. I still think there is a rug-pull risk by Microsoft, so not sure I would choose it for that reason alone.
- kittoes 3y ago
  Am using Blazor WASM in our shop and absolutely loving it once deployed. The hot reload and other development headaches are -really- painful, but just being able to use our existing C# libraries everywhere has been a game-changer for us.
isbvhodnvemrwvn 3y ago
Sounds a bit like Adobe Flex.
avgDev 3y ago
I have a large blazor project and do not have fan cranking at all. Hot reload is VS issue. I have a completely difference experience but then again I'm creating business apps and do not anything 'new'.

TheRealDunkirk 3y ago

This feels like a move to be more like Rails, and I'm there for it. The problem with Microsoft is that, every time I think, hey, this new thing might be useful for such-and-such kind of app or problem, by the time I get around to trying to use it, they've moved on to something else.

azakai 3y ago

At the very end of the blogpost the author asks why not compile C# to JavaScript, like F# (Fable) does? The author thinks that would be the best solution overall, and is surprised it has not happened yet. In fact that has happened, see JSIL (http://jsil.org/ http://jsil.org/, which compiles .NET bytecode to JS) and also SharpKit (https://github.com/SharpKit/SharpKit https://github.com/SharpKit/SharpKit which is built on Roslyn). But this will not necessarily be any better than compiling to wasm. It avoids the .NET interpreter, which decreases the download, but it will still need to bundle a lot of library support code. And getting the language semantics exactly right - including features like C# finalizers which do not have direct support in JS - is tricky, unlike with wasm. And it won't benefit from the speed of the wasm implementation in AOT mode (which Blazor supports), which can be much faster than JS. Compiling to JS definitely still makes sense in some cases, but it isn't an idea that Microsoft or the .NET community has somehow overlooked. It has been done and it has its own tradeoffs.

girafffe_i 3y ago

I miss SSR JSPs. I worked on a b2b2c marketplace, the caching and performance of SSR for routine pages was a godsend. We also used a "widget" architecture pattern with reusable components. We then hired a front end architect who replaced all widgets with react components, changed our checkout to full CSR React, our latency raised for all users, we lost 5% conversion on checkouts that never recovered, then the next step was to build a React service to help render the React, and moved CSR React to SSR React service. We now have 2 teams to support this. I get there are a list of other tradeoffs but I really miss JSPs.

poszlem 3y ago

Tangentially to the topic of the blogpost, has anyone else noticed that many recent articles on Hacker News feature AI-generated illustrations? They seem to have a unique, AI-specific style and that weird "uncanny valley" like quality where you can easily tell it was, in fact, a machine generated thing?

dustedcodes 3y ago
I used DALL-E 3 to generate the images. I always wanted to include more images in my blog posts, because I personally (and I might be wrong) feel like it sometimes helps to better tell a story or explain a sentiment which you hold as the author. But as a hobby blogger you don't get to have nice illustrations or graphics without paying an arm and leg for something which is just a free blog post. So yeah, I used AI for it and I love it. Also I'm not a native English speaker and I'll admit that I use AI a lot in recent months where I type up my badly worded text ridden with a lot of grammar mistakes and then feed it into a prompt to help me smoothen things out. I actually think I'd be stupid not to do it and I don't see it much different to a book author writing a book and then sending the script to a team of editors who do exactly the same thing, just that now it's a computer doing it faster. I have no shame in admitting this :)

withinrafael 3y ago

I find it hard to justify/invest the time needed to really dig into Blazor. Everywhere I go/look, buisnesses are stuck on mature solutions utilizing ASP.NET MVC 4 or 5 + Entity Framework (non-core). Just upgrading beyond that requires a lot of migration work, let alone rearchitecting for the new and shiny Blazor.

johnfn 3y ago

This article is really odd. The long lists of disadvantages feel a lot like the lists of disadvantages that ChatGPT produce, where relevant disadvantages will be placed right next to things that are wildly inapplicable to whatever I'm doing. And the whole list is extremely impersonal - there isn't a single reference to the product(s) that the author worked on, so it's impossible to tell if the downsides are even real downsides or not.

JohannesH 3y ago

I'm still weary of using Blazor in anything serious/long term. I've been burnt before by MS, leaving me with a tech that's both hard to continue using and hard to get rid of if need be.

jmull 3y ago

Seems like an awful lot of complexity and significant compromises just to get to use C# instead of TS or JS. I wonder what the practical scalability difference there is between streaming updates over a web-socket connection and streaming updates over a long-lived HTTP connection. It sounds like the same exact thing. Hopefully it can keep the complexity of auto mode under the hood.. I don't think app devs want to deal with code that behaves differently depending on whether webassembly files are cached or not.

barryrandall 3y ago
People are willing to compromise and put up with a lot of complexity if it gets them out of having to engage with JavaScript and its supporting ecosystems.

wvenable 3y ago

I think that's missing from this discussion is why so much effort is being put into Blazor. Why would anyone use or even build a framework with 4 rendering modes? The answer is that the on the ground developer experience of writing interactive applications in Blazor is extremely nice. In an ideal world, Blazor feels like how web development should be. If you've never used it then you'll have no idea what I mean. I'm not using it in production yet for many of the reasons discussed in this article although I may revisit it again in .NET 8. The newest modes might actually push it over the top for applications that I develop. I wish there were no downsides because it just is so very nice to code in.

psadri 3y ago

Shameless plug: https://skymass.dev https://skymass.dev is a js/ts version of Blazor. It is a batteries-included, code-first solution for creating high quality business web apps by simply writing a single-dependency backend process. Please be gentle as it’s in beta.

grounder 3y ago

Trying to understand Blazor better. Is it a similar idea to what GWT tried to do with Java?

mattgreenrocks 3y ago

Curious to try SSR to see if it can dethrone SvelteKit for me. SK is pretty great, though the backend side feels under-baked a bit compared to FastAPI. Regardless, I’m pleased to see more contestants try to wrest mindshare away from JS culture. Cambrian explosion or something!

tankmohit11 3y ago

I develop company's internal tooling using Blazor Server, and have developed moderately complex and data intensive applications. As a former React Developer who has spent most of his time working with Node.js and JavaScript tooling, Using Blazor WA and Server felt like a breath of fresh air. C# is joy to write and everything fits very well with existing enterprisy Microsoft services. State management is pain in React, until you install 3rd party libraries (Jotai, Zustand etc.), each value needs to be bound individually. Dotnet command line felt very snappy compared to npm/pnpm.On my crappy company laptop, when a nextjs application dev server starts, my blazor server app has already opened a browser tab with website running locally. efcore is also good. Overall working with blazor felt like working with Vue/Svelte, but with faster performance on backend. Nowadays I only touch React if strictly necessary.

zawarq 3y ago

A couple of observations: Blazor plays well with any back-end technology, not just a .NET server-side. That should be a no-brainer for developers, but its an assurance that non-devs need. Secondly, performance issues apart, JS-interop is really easy to pull off. That is good news for the non-puritan, pragmatic programmer. We understand that it will take a while before Blazor libraries catch up to the large number of options available for Angular and React. Until then, Blazor + JS-interop is a great solution that covers all scenarios in the vast majority of cases. For the last year, amongst other things, we have been building a high-performance online trading platform using Blazor, Spring Boot and GCP. No insurmountable issues so far!