[HN Gopher] .NET Blazor
___________________________________________________________________
.NET Blazor
Author : dustedcodes
Score : 287 points
Date : 2023-11-21 07:41 UTC (15 hours ago)
(HTM) web link (dusted.codes)
(TXT) w3m dump (dusted.codes)
| smokel wrote:
| 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 wrote:
| 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 wrote:
| There are many of us working at smaller companies who do all
| of the above.
| ttymck wrote:
| 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 wrote:
| That was not the context the OP was addressing.
| catmanjan wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| Some people just don't enjoy front end work, and vice versa
| jve wrote:
| 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 wrote:
| Front is also very tedious. Lots of reinventing the wheel
| every time, obscure css bugs, etc.
| Cthulhu_ wrote:
| 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_ wrote:
| > 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 wrote:
| I think sometimes there's often gaps where you have to
| fill in for the designer.
| lf-non wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| pacifika wrote:
| Picking up full stack is a long way from innovating in it.
| sebazzz wrote:
| Innovation in the technology is not something every company
| has to do.
| sebazzz wrote:
| 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 wrote:
| 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 wrote:
| 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.
| xnorswap wrote:
| 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 wrote:
| 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 wrote:
| > 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.
| pjmlp wrote:
| JavaFX never really became a thing, because even at Sun it
| had a bumpy start with the scripting based language before it
| got rebooted into Java, just before Sun went down.
|
| Oracle isn't a GUI company, beyond the stuff needed for their
| database products and IDEs, so they also didn't invest that
| much into it.
|
| Thus most of the Java ecosystem, kept targeting Swing, and
| for the extent native desktop applications are still around,
| Swing is good enough.
|
| Android is its own thing, so even one less reason to care
| about JavaFX.
| HeckFeck wrote:
| javax.window.JOptionPane.showMessageDialog("Hello!");
|
| Forever burnt into my mind from Programming 1008. And in
| fairness, much easier to get off the ground than the
| legions of XML required for JavaFX.
| BurnGpuBurn wrote:
| Don't forget all the other products Microsoft managed to
| screw over developers with. Like discontinuing Xamarin.
| jve wrote:
| Sorry for not being up-to-date. I can't read anything about
| discontinuing Xamarin on wiki:
| https://en.wikipedia.org/wiki/Xamarin
|
| Ok, MS says this: https://dotnet.microsoft.com/en-
| us/platform/support/policy/x...
|
| > Xamarin.Android, Xamarin.iOS, Xamarin.Mac are now
| integrated directly into .NET (starting with .NET 6) as
| Android, iOS, and Mac for .NET. If you're building with
| these project types today, they should be upgraded to .NET
| SDK-style projects for continued support.
|
| > Xamarin.Forms has evolved into .NET Multi-platform App UI
| (MAUI) and existing Xamarin.Forms projects should be
| migrated to .NET MAUI.
|
| So to those of you using Xamarin: how painful it is? How
| compatible Xamarin.Forms or not is with .NET MAUI? Are they
| totally different tech?
|
| How easy/hard it is to go from Xamarin.{Android,iOS,Mac} to
| .NET6+ ?
| throwaway2990 wrote:
| Xamarin for iOS and Android just works...
|
| Maui on the other hand is a turd. It's such a pain to
| work with, workloads just plain suck. And if you install
| . Net 7 and your project targets 6, It will download .net
| 7 workloads and fail to build. Then 8 comes out and same
| problem. Have to pin the SDK.
| rqtwteye wrote:
| And by the time Maui starts to mature and work, they will
| announce a new framework and the cycle starts again. I
| still don't understand why they couldn't keep working on
| WPF instead of cranking out a new framework every three
| years.
| bad_user wrote:
| You can say that, but at the same time, whenever people
| complain about technology changing, leaving them behind, they
| usually mean tech by Microsoft.
|
| The reason Java and JavaFX survived is that they went Open
| Source, with a large FOSS ecosystem, targetting FOSS
| operating systems as well, all while there still was
| interest. And their maintenance and evolution continued.
| Adobe RIA and Flash were proprietary platforms, just like
| Silverlight.
|
| In fairness, projects that survive tend to be FOSS, and
| AFAIK, .NET Blazor is open source. OTOH, the .NET ecosystem
| tends to prefer Microsoft's solutions, with alternatives
| languishing, they basically killed Xamarin's projects, and
| they have had several noteworthy conflicts with the FOSS
| community. So the jury is still out on whether Microsoft's
| projects can escape the deprecation curse.
|
| ---
|
| The lesson here, for all, if you want for your knowledge and
| work to stay relevant, look towards Open-Source platforms and
| open standards. If seeking stability, the older, the better,
| actually. FOSS platforms age like fine wine.
| cxr wrote:
| > That's not really fair to MS since all the web frameworks
| which were born in that era (Adobe's AIR, JavaFX as a web
| tech, etc.) died because IE died. And also because Apple
| killed off browser plugins since they didn't work on the
| iPhone.
|
| Who could have foreseen that hitching your horse to derpy,
| single-vendor RIA frameworks that were closed source
| proprietary and worked on the basis of shoving foreign
| content into the browser to get it to do non-Web things was a
| bad idea? Oh wait, anyone.
|
| In that vein, in response to the earlier remarks by the
| original commenter:
|
| > Silverlight burned a lot of small businesses hard, almost
| everywhere I've worked has had a silverlight horror story of
| a project they experimented in it with only for it to
| languish. So now they either have some outdated dependencies
| they'll never update or had to re-write it back into
| something else.
|
| Yeah, good. That pain is well-deserved. Almost self-
| inflicted, even.
| torginus wrote:
| I like .NET, and I believe Blazor represents an unique
| capability for that tech stack, but using Blazor essentially
| means eschewing all the traditional web stack tooling that was
| built up around TS/JS during the past decade for proprietary
| Microsoft weirdness.
| jcmontx wrote:
| > proprietary Microsoft weirdness
|
| .NET (and Blazor) has been open source for at least 7 years
| now
| ajryan wrote:
| Call it Blazor weirdness then. This obviously wasn't a
| swipe at Microsoft being closed, just a point that Blazor
| stuff is not general standard web stuff.
| cxr wrote:
| Something can be both open source and proprietary. Flex has
| been open source for even longer. Still proprietary. See
| also: XUL.
| keyle wrote:
| I professionally saw the rise, the peak and the burn of
| Director (Shockwave), Flash and Silverlight...
|
| By far, the most devastating one, was Flash.
|
| One good thing came out of Silverlight, and it's not really
| getting the credit it deserves: MVVM.
|
| As far as I know, Silverlight brought that pattern to light,
| before that, it was MVC and OO hell. And MVVM paved the way to
| modern paradigms, imho.
| sanitycheck wrote:
| Oh, me too. So much now-obsolete knowledge accumulated!
|
| Flash was always going to die someday though, as HTML/JS
| caught up with it. In the end it was killed (arguably)
| prematurely, but it probably wouldn't have lasted more than
| another 5-6 years anyway.
|
| Silverlight, I think, was worse - only a few years between
| initial launch and discontinuation. Pretty much every client
| app based on Silverlight would have had to have been
| rewritten from the ground up within a couple of years of
| completion.
|
| I try to learn lessons, in life. One of them is to not rely
| much on any Microsoft technology that's less than 10 years
| old.
| keyle wrote:
| I remember the transition to WPF apps was awfully painful.
| throwaway_0235 wrote:
| > Flash was always going to die someday though, as HTML/JS
| caught up with it.
|
| I'm not sure that would happen. I think Flash would evolve
| to just "compile" to HMTL/JS. IOS/Android could be other
| targets as well, once they found a way that would not upset
| the Eye of Apple.
| acdha wrote:
| Not if Adobe was developing it. Flash was terrible for
| performance and battery life, and it was wedded to the
| classic fixed-size window with a keyboard and mouse. Even
| Android users who had access hated it.
|
| Now, it's possible that some of that could've improved
| (battery life would've been hard due to the scene timing
| model) but Adobe just isn't a platform company. They
| didn't even want to fix the security problems, much less
| all of their half-assed APIs - they were even worse than
| Sun for announcing ambitious frameworks duplicating
| built-in OS features, shipping the easiest 40%, and then
| letting it stagnate because there was no way fixing the
| hard stuff would get them a second keynote.
| jen20 wrote:
| MVVM was also the prescribed pattern for WPF (which shares
| some other things like XAML with Silverlight). WPF debuted a
| year earlier though!
| oaiey wrote:
| I have to disagree. What you describe is every legacy stack and
| 20 years evolvement. Java with how many EE systems. JS with how
| many SPA frameworks. Python I know too little. Go/Rust are too
| young to have history.
| kgwxd wrote:
| Silverlight was an obvious bust from the beginning, no one with
| longevity in mind jumped on that ship and fought against anyone
| pitching it at the time (mostly inexperienced devs, sales
| people, and tech companies looking to make a quick buck).
| Anything plug-in based was already on the chopping block by the
| time it came out. Blazor WASM is, at least, as safe a bet as
| any popular JS framework. If .NET was still a Windows only
| thing, I'd stick with the JS frameworks, but now that it's
| cross platform, I've got no problem choosing Blazor over any
| other UI framework that just as easily might need a full
| rewrite in a few years.
| havkom wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| I thought it was one of the fastest web frameworks but this
| article completely destroys that image. What gives
| jcparkyn wrote:
| 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 wrote:
| 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_ wrote:
| Coming from the other side, this compatibility is why NodeJS is
| still very popular on the back-end. It makes sense for
| companies to try and stick to one programming language and / or
| ecosystem, else you end up with two disciplines within your
| company.
|
| http://boringtechnology.club/ 's slides show the problem pretty
| well. I'm not saying companies _should_ stick to one
| technology, since the "golden hammer" is also not a good idea,
| but that the technology choices should be taken with care and
| consideration of things like hiring.
| BoorishBears wrote:
| 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 wrote:
| Referencing the site, I would categorize Blazor under both:
|
| - Unknown unknowns (since it hasn't been out for as long
| and battle-tested by as many people)
|
| - Shiny new tech (one could argue that C# is old, but
| that's a small part of the experience of a new and shiny
| API)
| dustedcodes wrote:
| Thanks for your feedback. It sounds like you are saying that
| Blazor was created mainly for internal corporate apps on their
| intranet, but I don't think that is quite what Microsoft
| envisions when they market Blazor. Perhaps that is where you
| concluded that Blazor has its only real place, possibly for the
| exact reasons which I've listed in the article?
| > If you're replacing a shared spreadsheet cooked up by Tim on
| the data analytics team, how much does JS really matter.
|
| I take your point, but from my experience replacing an internal
| spreadsheet which most non engineers know exactly how it works
| and does mostly everything they need/want with a custom SPA so
| 5 people in an organisation can do a task differently has never
| been a good use of developer resources or improved
| productivity.
| merinofg wrote:
| People don't realize this. Blazor is about the developer. I am
| a `DevOps/Backend` guy and in my previous job some internal
| tools were made with Blazor.
|
| It was such a joy to work with. Productivity was so high. You
| add Blazor Radzen components[1] or Syncfusion[2] and suddenly
| feels like magic. Super complex grid tables can filter, re-
| order columns, aggregate them and much more functionality for
| free in 10 lines or fewer.
|
| I cannot recommend enough to people to give it a try. This
| technology enabled me to do a repair shop software in 1-2 month
| on my spare time. From customers to emitting bills in PDF. Zero
| JS and just using the basics grids from bootstrap CSS to make
| it responsive. As a non frontend developer, this was heaven.
|
| [1] https://blazor.radzen.com/ [2]
| https://www.syncfusion.com/blazor-components
| BoorishBears wrote:
| It's funny you're being downvoted, I've used Blazor on less
| important side projects and I love it for the same reasons,
| but a subset of HN hates it because their uBlock Origin no-Js
| anti-tracker cookieless oddball browsers choke on it.
|
| Interestingly enough Google's crawlers don't even choke on
| it: my fully SignalR based site was indexed soon after
| getting a spike in traffic without an issue.
|
| Does it annoy me that leaving the tab and coming back can
| kill the app? Sure. But often times I reach for it when I
| otherwise wouldn't have built a thing at all.
|
| Most normal people will take an app with hair edges they can
| use over nothing so I'm going to keep reaching for it from
| time to time
| mardifoufs wrote:
| No, people hate it because it's a massive downgrade in UX,
| especially the wasm variant, just because backend devs
| don't want to use the right tools for the job. I'm fine
| with it in internal apps, but public facing apps using
| blazor would be horrible for the users, which is why it is
| thankfully very rare to see.
|
| Javascript seems downright lightweight and unbloated
| compared to shipping an entire dot net runtime for a crud
| form app. For what it's worth, I don't care about turning
| off javaScript or even bloat in general, but this is
| extreme.
| BoorishBears wrote:
| That's not how the right tool for the job works: the tool
| that results in the smallest bundle size and the most
| impressive web metrics is absolutely worthless if 99% of
| the value in what you're making is it existing and the
| creator of said tool doesn't feel like building out a
| SPA.
|
| Of the tens of thousands of people who found my tool
| useful, the only people who ever complained where Hacker
| News users, and the tool simply would not exist if I had
| gone and wasted my time spinning up Next, realizing the
| app router is garbage, RSC has no place in most React
| apps, then going back to pages router, then rediscovering
| how awful NextAuth is, then...
|
| Which is exactly how some of my otherwise interesting
| side projects die too.
| pjmlp wrote:
| Same role, this is exactly why have I kept myself focused on
| .NET and Java frameworks for Web development, or CMS in those
| platforms, and mostly leave SPA stuff for the FE team.
|
| Native desktop development is another matter, though.
| cxr wrote:
| > Blazor is about the developer
|
| Clearly. And that's exactly where the most salient criticism
| of it comes from: prioritizing the pleasure of the programmer
| during the development process over everything else,
| including the experience of the person who actually has to
| put up with using the thing--all while providing cover for
| the vendor who bid on the job to argue that they've fulfilled
| all the requirements so what are you upset about if it's a
| little janky? Classic enterprise crapware mindset.
| wwilim wrote:
| Blazor Server is even better for corporate intranet
| applications. Building monitoring/operations apps is insanely
| easy when you can just connect your UI components directly to a
| singleton state on the backend. I wouldn't even consider
| anything else if my job was to make an app for a group of users
| who all sit in the same room.
| hliyan wrote:
| can we not say the same thing about PHP applications?
| TrackerFF wrote:
| 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 wrote:
| 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 wrote:
| > 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.
| unsignedint wrote:
| Downloading older builds remains an option, and scaffolding
| the environment for your chosen version is simplified by
| their scripts. I've successfully installed six versions,
| ranging from 2 to 8, side by side using this method.
|
| https://dotnet.microsoft.com/en-us/download/dotnet
| pelagicAustral wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| I regularly have video calls from the UK to NZ with no issues
| at all. Might be your provider.
| madeofpalk wrote:
| 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.
| sebastianbk wrote:
| It can be hosted by either WebAssembly or by the server (in
| which case the server will render the DOM and send diffs to
| the client over a WebSocket connection). Blazor Server
| probably isn't the best choice for a popular SaaS app, mainly
| because of its dependency on WebSocket connections and less-
| than-perfect reconnection logic.
|
| I'm optimistic about the auto-rendering mode, which will
| serve the app via Blazor Server (using a WebSocket
| connection) the first time the user hits the app. It will
| download the WebAssembly DLLs in the background so that the
| next time the user comes by, they will get the WebAssembly-
| hosted version. It's an interesting mix combining the best of
| both worlds (hopefully).
| useerup wrote:
| Blazor - until .NET 8 - came in Blazor Server and Blazoe
| Webassembly variants.
|
| Blazor Server renders the DOM at the server and sends it to
| the browser. The server also holds on to some state for each
| client - notably the "current DOM" - so that it can calculate
| diffs on changes and only send the diffs to the browser.
|
| Blazor Webassembly does the rendering in Webassembly in the
| browser. The .NET stack runs in the browser. Here, the code
| renders and diffs in the browser and the the diffs are
| applied to the DOM as well.
|
| This also means that _the same components_ can run either
| server-side or client-side. They basically all end up
| computing DOM diffs and applying those diffs to the actual
| DOM. Pretty neat, actually.
|
| Each model has it's pro and cons. Blazor Server initialized
| really quickly and relies on minimal Javascript in the
| browser. But it creates load and server affinity on the
| server. Blazor Webassembly offloads all rendering to the
| browser, but at the cost of an initial load of the code.
|
| In .NET 8 these can now be blended, and a new "auto" mode
| allows a component to be initially server-side and then
| client-side when the webassembly code has downloaded.
|
| In addition to that is now (.NET 8) also the static server
| side rendering (and "enhanced navigation") which you could
| say is server side components without the "circuit" server
| affinity and server state of each client. Static server side
| rendering has some limitations on how interactive they can be
| - i.e. changing the DOM.
| Mountain_Skies wrote:
| Seems like server vs client would also come with a set of
| security tradeoffs.
| andrewxdiamond wrote:
| It's just moving the work that would be happening in the
| browser to the server. There is no reduction in security
| with either of these styles
| DonnyV wrote:
| "The server also holds on to some state for each client"
|
| If this is how Blazor is architected. Then I have no
| interests in using this and really anyone doing any type of
| web development shouldn't bother with this. Internal apps
| eventually need to be used externally. This is a time bomb
| waiting to explode on the users and the developers.
|
| I use VueJS with Asp.net Core with multi-page single load
| architecture. Meaning once a page is loaded all other data
| is loaded through ajax. But the app is made of multiple
| pages. Over 10 years of being a web developer has brought
| me to this setup. Client UI state should stay on the
| client. All other state should be saved to the server. All
| communication should be stateless.
| failbuffer wrote:
| It's how Blazor Server apps are architected. Blazor
| WebAssembly apps don't maintain client state in the
| server and can be load-balanced like normal.
| gustavus wrote:
| > This is a time bomb waiting to explode on the users and
| the developers.
|
| I'm just saying a lot of the target they are aiming to
| replace is VBA applications slapped on top of Access DBs,
| and Lovecraftian nightmares born out unholy fornication
| of Batch scripts and unintelligible spreadsheet formula.
|
| I'm not saying your wrong, just pointing out that even if
| this is a ticking time bomb it's a ticking time bomb that
| is using conventional explosives replacing a cesium based
| nuclear time bomb that is already counting down the
| seconds.
| jdthedisciple wrote:
| Man, well done- how do you just start a company and instantly
| the biggest issue becomes having _too_ many customers?
| throwaway2990 wrote:
| > I quickly got tired of the internal plumbing, package
| management, build configuration, and all the other things not
| related to the actual functionality of the app that Vue (v2)
| required at the time.
|
| I don't understand this. I've used v2 since before release and
| it's never been anything more than an initial setup of 5m and
| then build your app?
| marcos100 wrote:
| As a backend dev, I love the technology. The problem is that
| you have to choose between a not-so-scalable solution (Server,
| signalR) or a minimum 2mb initial payload (WASM) that can
| easily go to 5mb.
|
| Interested on how many concurrent users you have for Server to
| be a problem. Can you elaborate more on your performance
| issues?
| blackoil wrote:
| Is 5MB a real problems? Theoretically it may look big, but I
| have seen many websites much bigger, not to mention all
| video/image we download are already skewing download by a
| lot. Considering runtime is cached for long time, I don't see
| a real blocker. First page render would be an issue but SSR
| solves that.
| sebastianz wrote:
| > Is 5MB a real problems?
|
| Well if you want to make small fast loading html pages with
| a minimal js library, and end up at a few hundred KB that
| you can understand, profile and optimize, then that is
| impossible with blazor. So it's a very real problem.
|
| If you want 5mb blobs and do not care about what is going
| on inside, how to optimize or reduce the memory and
| bandwidth usage, then it's not a problem, works just as
| well as the websites you have seen, with 200 node
| dependencies.
| francisofascii wrote:
| On a phone, 5MB it not ideal. On a corporate desktop, not
| an issue.
| sebastianbk wrote:
| I may have made a mistake in designing the architecture of
| our app. Since we're a small team, I opted for a big ol'
| monolith, hosting our APIs on the same server as our Blazor
| Server app. We normally serve a few hundreds requests per
| second on our APIs, which is totally fine. However, sometimes
| we got some spikes up to thousands of requests per second,
| which has the unfortunate consequence that our Blazor Server
| app becomes laggy and starts to drop WebSocket connections
| frequently. So, now, we are in the process of moving our API
| controllers to another project, which will be hosted on a
| separate server.
| diarrhea wrote:
| Sounds like you did everything right then. Started off
| simple, now your business is taking off, failures aren't
| catastrophic (they're grey, not black, from what it sounds
| like) and splitting out a component shouldn't be too hard,
| so you'll be ready for more scale soon. All while
| maintaining the business!
| eknkc wrote:
| .NET 8 solves that exact problem as far as I can see. You can
| opt into auto mode and it uses server side Blazor until the
| client downloads all assets, then in subsequent visits it
| uses the WASM runtime. Seems to be a good compromise.
| KronisLV wrote:
| > In my previous job, I was on a team using Vue.js for the
| frontend and ASP.NET Core for the backend. I quickly got tired
| of the internal plumbing, package management, build
| configuration, and all the other things not related to the
| actual functionality of the app that Vue (v2) required at the
| time.
|
| Oh, hey, I have something relevant to say about this setup.
| Currently I'm bootstrapping a platform with .NET Core on the
| back end and Vue 3 on the front end.
|
| In short: - .NET is one of those boring
| workhorse choices, like Java - it's pretty stable, the
| performance is good, the type system is decent, IDEs are as
| good as it gets (Rider, VS), can run on Windows or Linux with
| no issues, there is an ecosystem that feels very coherent (more
| focus on ASP.NET than something like Spring in Java, because
| there's fragmentation around that, Dropwizard, Quarkus, VertX
| and so on) - Vue feels really nice to work with, the
| Composition API feels simpler than React, the developer
| ergonomics are fine, the documentation is nice, packages like
| Pinia, VueUse and VueRequest keep things simple, in addition to
| something like PrimeVue giving lots of UI components that you
| can use to iterate out of the box - however, while I
| think that the SPA approach can be nice to keep the front end
| separate from whatever technology you use on the back end, it
| comes at a cost of duplicating your data model and the
| interfaces between them (REST endpoint and client, for
| example), in addition to needing to think about how to deploy
| it all (separate domains vs context paths on the same domain,
| CSP, CORS etc.), though it's mostly doable - I did
| definitely run into problems with Vue not being the single most
| popular choice out there, for example I wanted to integrate
| Mapbox maps and the VueMapbox package is for Vue 2 only,
| whereas Vue 3 Mapbox GL breaks when you try to integrate it
| with mapbox-gl-directions. Eventually I switched over to Vue
| Map (Leaflet based) with leaflet-control-geocoder and leaflet-
| routing-machine but even those tended to break, because adding
| markers for a calculated route makes the map break when you
| zoom in/out, due to it losing a reference to the map JS object;
| in the end I just used patch-package to fix a few lines of code
| that didn't work in the offending packages instead of
| forking/building them myself, but that's a bit of a dirty hack
|
| In short, I think that .NET is pretty good, Vue is pretty good,
| but the JS ecosystem feels like it works well only _sometimes_
| , even for reasonably popular solutions. On that note, I'm all
| for trying out things like Blazor, but then again my past
| experiences with Java and something like
| JSP/JSF/PrimeFaces/Vaadin have soured my perspective a bit
| (which is also why I prefer to keep the front end decoupled
| from the back end as much as possible, sometimes to my own
| dismay).
|
| Honestly, it sometimes feels like picking anything that's not
| React is shooting yourself in the foot because everyone's
| building their libraries/packages/integrations for React. At
| the same time, I don't really enjoy React much at all.
| naasking wrote:
| > however, while I think that the SPA approach can be nice to
| keep the front end separate from whatever technology you use
| on the back end, it comes at a cost of duplicating your data
| model and the interfaces between them
|
| Can you elaborate on this? I'm not sure I get it, because
| once you have your view model in asp.net, it seems like it
| should be easy to derive a JS/TS model from it using various
| techniques (reflection, source generators, etc.).
| devjab wrote:
| I spent a decade with C# and .Net and even in its current
| form which is easily the best it's ever been I vastly prefer
| to work with Typescript.
|
| Yes, you do need to set up some rather strong governance
| around it for it to work for multiple teams, but you should
| really be doing that with any technology, and once you do,
| it's just excellent. Part of the reason for this is that it's
| basically designed from the ground up to require that you
| build and maintain "template" projects, have strong linting,
| testing and pipeline governance, so there is a lot of freedom
| to make it work easily for your organisation exactly the way
| you want it to. Typescript is obviously not alone in this,
| but it's far less opinionated than something like .Net.
|
| The main reason is that .Net always becomes burdensome once
| you start using it's included batteries. This isn't really an
| issue with C# as much at it is an issue with it's libraries.
| Take OData and Entity Framework as an example, the .Net magic
| behind them sort of share the same model builder, but they do
| so differently. What this means is that a lot of the cool
| OData features like patch doesn't actually work with EF,
| meaning you'll either have to rewrite a lot of the model
| builder (don't) or have to work around it. .Net has always
| sort of been like that. It variates between being 50-90%
| "done" but it never really gets there until it moves on. Like
| EF, much of the EF 7 road map isn't implemented yet, but here
| we are, moving on to EF8.
|
| I think for a lot of use cases it's a wonderful technology,
| and Blazor will probably be awesome until Microsoft moves on,
| but at least around here, it's also a technology that doesn't
| really see adoption in anything but small-midsized companies,
| and in my opinion, .Net is part of what hinders growth.
| Obviously not a huge contributor, but once you step out of
| where it excels, you're just going to have to fight .Net so
| much harder than you will with Typescript. Which is sort of
| interesting considering they are both Microsoft products
| which align more and more. That being said, it's not like
| it's bad either.
| GiorgioG wrote:
| Batteries are included, but you aren't forced to use them.
| neonsunset wrote:
| Previously from this account:
| https://news.ycombinator.com/item?id=38228674
|
| The tldr of both the previous and this posts is OData being
| bad yet the author extends his grievances regarding it to
| the entirety of ecosystem.
| devjab wrote:
| It seems a little disingenuous of you not to mention how
| I never hide the fact that it's an issue with the
| batteries. I'd also say that considering how great
| OData's patch is with the modelbuilder it's actually EF
| that's being bad in this case.
|
| You could also point back to other posts like this one: h
| ttps://news.ycombinator.com/item?id=37538333&p=3#37541652
|
| Where I also point out other, similar issues with other
| parts of the .Net batteries.
| spzb wrote:
| I enjoyed using ServiceStack. Write your data model in the C#
| API, run a tiny CLI command and it spits out Typescript
| definitions to match your data model.
|
| https://docs.servicestack.net/typescript-add-servicestack-
| re...
| fuzzy2 wrote:
| TypeLite used to offer something similar, but it's somewhat
| dead nowadays.
|
| OpenAPI client generators are probably what's popular
| today.
| rattray wrote:
| Yep. For frontend use, I think
| https://www.npmjs.com/package/openapi-typescript is the
| most widely-used/well-regarded, though
| https://www.npmjs.com/package/orval seems to me to have
| some nicer features like react-query support.
|
| There are other options too, I'd just stay away from
| "_the_ openapi generator" (https://openapi-
| generator.tech/) which does a pretty poor job IMO.
|
| Disclaimer: I'm the founder of a company doing SDKs
| commercially, but we don't focus on the frontend right
| now, and our free plan is still in beta.
| squidsoup wrote:
| > it comes at a cost of duplicating your data model and the
| interfaces between them
|
| Not the case if you use graphql.
| oaiey wrote:
| I share your perspective. It is the most productive environment
| I have seen in many years. Blazor WASM for internal company
| applications, PWA or Blazor Hybrid (basically Cordova/Electron
| Shell just with C#) is just awesome.
|
| I share the article's fear of overloading the technology, but
| do not see it overall that negative.
| bob1029 wrote:
| > However, now that we have many customers using the
| application in production, we're starting to see some of the
| not-so-pleasant side of Blazor Server. When experiencing a lot
| of requests, the experience is degraded for all users of the
| app. In addition, it's not very good at re-establishing the
| WebSocket connection if it fails, giving a poor impression to
| the user.
|
| We've been using Blazor server for ~3 years now and have had
| similar experience. We _only_ use it for internally-facing
| administration sites, and even then it 's still quite annoying
| to hear team members complain about the inevitable reconnecting
| to website warning, even when everyone knows exactly why its
| happening.
|
| This experience with using websockets to move state between
| client and server has pushed us away from the idea that the
| client could ever be made responsible for any meaningful amount
| of state. In our current stack, we return final server-side
| rendered HTML and handle multipart form posts. There are no
| more websockets in our stack. Everything is stateless HTTP
| interactions - the client only manages a session token.
|
| SPA was a fun experiment, but I am completely over it. If you
| are trying to fix some weird UX quirk, reach for a little bit
| of javascript. Don't throw away everything else that works over
| something small. There was a time when I would have agreed that
| you _need_ frameworks, but that time has long since passed.
|
| In 2023, approaches like PHP feel more valid than ever. I know
| way more about what _doesn 't_ work than what does these days.
| If you want something like PHP but you don't know where to
| start, you should think really deeply about what PHP is
| actually doing and if your preferred programming language does
| not also have a similar string interpolation concept.
| ptrwis wrote:
| In my experience, long polling is more stable and you can
| enable transfer compression. Maybe it would be good in Blazor
| to disable the persistent connection completely, having only
| requests and responses. Often we just want to call a backend
| method and update the view in response.
| _s_a_m_ wrote:
| 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 wrote:
| 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.
| bragh wrote:
| 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 wrote:
| 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/#underst...
| bragh wrote:
| 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 wrote:
| I hassled my IT guys to get rid of Symantec Endpoint
| Protection on my PC and leave me with Defender. You can
| too.
| moron4hire wrote:
| Trust me, there are environments in which you can't.
| Keywords: "DoD" and "consulting".
| moron4hire wrote:
| Yes, how dumb of me to not make a completely weird request to
| interview the corporate IT department of my job after I had
| been laid off for two months and was struggling to find
| anything in my area.
| cxr wrote:
| If _antivirus scanners_ come up at any point when the topic is
| things that are "critical" to the developer experience (let
| alone as the very first thing), that's a really telling
| baseline--the tip of the iceberg as far as indicators of
| organizational dysfunction go. You might as well be speaking
| from a place where every employee starts the day with a nailgun
| fired through the palm of their hand and then they spend their
| time gushing over lunch about how Acme Co. has the best
| woodsaws out of all the woodsaws because theirs are the ones
| that let you really get in there and cut away most of the plank
| --so you're just walking around with a medium chunk of wood
| fixed to the back of your hand, of course, instead of the whole
| board. Nuts.
| ChicagoDave wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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
|
| [2] https://blazordiffusion.com
|
| [3] https://github.com/NetCoreApps/BlazorDiffusionVue
| jddj wrote:
| 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 wrote:
| > By the way, I think if you used a light-dom framework like
| alpine or petite-vue you would avoid most of the issues with
| the page not recalculating the front-end state on navigation.
|
| Unfortunately it's how Blazor Enhanced Navigation works where
| it compares the rendered content of the new page and diffs in
| the changes so I'm not expecting it to work by default (i.e.
| without adopting a workaround) with any JS FX that
| dynamically generates the UI as it'll get replaced back into
| an empty div when Blazor patches in the new page elements.
|
| Also I wouldn't recommend "lite-dom" FX's like PetiteVue
| which has basically been unmaintained since 2021, has poor
| composition/component model and pretty glaring
| bugs/limitations you're likely to hit very quickly for any
| complex UI. We ended up having to rewrite all our Built-in
| UIs [1] with Vue 3 [2] to overcome its limitations. The 40kb
| increase in minified/compressed .js size vs vue.min.js is not
| worth the pain of working within its limitations.
|
| [1] https://servicestack.net/auto-ui
|
| [2] https://docs.servicestack.net/releases/v6_07#new-locode-
| api-...
| jddj wrote:
| Ah, ok.
|
| I did that same rewrite (alpinejs to vue3) in a project of
| mine. I did it for CSP reasons rather than
| performance/behaviour limitations despite spending quite a
| while getting recursive generation to work.
|
| The next project has less untrusted input and a simpler
| datamodel so I went with alpine again and I've not had any
| issues whatsoever.
|
| Good to know about the bugs/abandonment of petit-vue.
| Admittedly, I probably shouldn't have recommended it above
| without having used it.
| feoren wrote:
| > Blazor SSR + Vue
|
| I'm sorry, but WTF? You spend 5 paragraphs talking about how
| great Blazor _Server-Side Rendering_ is and then throw a "+
| Vue" right at the end? WTF? So it's not SSR _at all_!? How are
| you avoiding npm and JavaScript builds when you 're literally
| using Vue? That little example app you showed has ~3500 lines
| of JavaScript in it ...
| lostmsu wrote:
| I expected something to back the claims in the article, but found
| none. For instance, there are no performance numbers.
| oaiey wrote:
| 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 wrote:
| 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 wrote:
| 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
| banashark wrote:
| Very cool project!
| FrustratedMonky wrote:
| ===>>> 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 wrote:
| 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://www.dice.com/career-advice/exploring-bridge-net-c-ja...
|
| https://www.infoq.com/news/2015/02/duocode-csharp-javascript...
|
| http://jsil.org
|
| I wonder if the community just isn't interested in this
| approach.
| FrustratedMonky wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| As a java backend dev, I am envious that Java doesn't have a
| modern equivalent of Blazor.
| nu5500 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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
| jadbox wrote:
| 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 wrote:
| 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 wrote:
| You don't need hyperscript, you can just do it with
| Javascript.
| kumarvvr wrote:
| 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 wrote:
| 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 wrote:
| 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.
| louthy wrote:
| > When it comes to web, MS has been focused on ASP.NET
| since forever.
|
| What's your definition of 'forever'? Are you talking about
| ASP, or ASP.NET, or ASP.NET Core? Or, Web Forms, MVC1,
| MVC2, MVC3, Silverlight, 'minimal APIs'? ...
|
| Honestly, it's just one clusterfuck after another.
|
| ---
|
| EDIT: There's a number of sub-comments here that seem to be
| missing the point. So, I'll expand here:
|
| * For those who are questioning my right to have an opinion
| on this and doubting my expertise: I have used .NET since
| version 1. I founded a company in 2004 and have been
| responsible for building an enormous web-app product in the
| .NET world (since before jquery era, basically). I've seen
| all these frameworks come and go.
|
| * For those who are saying "whatabout JS". Am I not allowed
| to have an opinion on the ever changing landscape of .NET
| web-app development without first criticising the 1000s of
| open-source developments?
|
| * For those saying they've done migrations in the past. I'm
| pleased for you. Now try it with an application of over 500
| pages when you have other things to be getting on with.
| Especially if you're not eager to jump to the latest and
| greatest every time a new one comes out, then you have a
| big problem of jumping multiple steps. Or, especially when
| they rip the entire ecosystem away (.NET Framework - .NET
| Core) meaning a big fix-up job for those migrating. I'd
| love to know what the collective economic impact of MS
| changing their minds every few years is.
|
| But, finally, this is not about migration per se. This is
| about the poor quality of the frameworks themselves.
| Microsoft just follow the latest trends once they get going
| and then build half-assed versions that try to completely
| lock you into their world. They try to destroy everything
| that is the web so they can stop you leaving their
| ecosystem. This has profound problems for the consumer of
| these frameworks when MS drop it and go after something
| else. The Minimal APIs is a good example of bandwagon
| jumping, they've seen the trends to more functional-style
| APIs, and then they go and implement it in a horrible half-
| functional/half-OO ugly way. There are so many gaps in it
| due to its design that it's already obvious that it won't
| last (in its current form at least).
|
| In 'JS land' it may not be the prettiest of ecosystems to
| work with, but JS written 20 years ago will probably still
| run today. Frameworks written 20 years ago can still be
| used. Support may go away, but that doesn't precipitate a
| rewriting of your UI layer. Anyone developing software for
| the long-term, which is professional software houses,
| should be wary of relying on anything MS build (outside of
| the language itself and its tooling, which is excellent).
|
| Personally, I'd never bet the house on a MS web framework
| again. We ended up rolling our own, which was much more
| advanced than most web-frameworks (at the time) and stayed
| written (well, until .NET Core came along!).
| michaelteter wrote:
| Have you been to JavaScript land in a while?
| louthy wrote:
| Sure, do you have a point you'd like to make?
| codegeek wrote:
| The tooling ecosystem around JS is nuts. Packages (npm
| etc) hardly have any backward compatibility. You install
| a package today. In 3 months, that code won't build. The
| errors want you to go take a cryptography course to
| understand WTF is happening.
|
| And I am not even talking about the language itself YET.
| ANd no, why should I be forced to use Typescript ? Yet
| another layer.
|
| And I did I get to the 100s of config files that need to
| be set just so I can run "npm build" ? Webpack, Vite,
| blah blah.
| realusername wrote:
| > You install a package today. In 3 months, that code
| won't build.
|
| And you are even generous, if you force upgrade every
| package you have in a month, I'm pretty sure you will
| have broken stuff.
| eddythompson80 wrote:
| A lot of these frameworks either composed together or had
| an upgrade path where it made sense. Plus if you're
| structuring your application right in .net, that web
| layer becomes another interface. I have taken an
| application across a few of those with some fuss, but
| you're covering 20+ years of development there.
| unusualmonkey wrote:
| Have you used those technologies?
|
| Asp.netbwas great, asp.net cire was a good upgrade, and
| minimal apis are an optional way to get an asp project up
| and running with less boilerplate.
|
| Not sure how that constitutes a cluster.
| no_wizard wrote:
| Don't forget Web API 2! And their other API
| recommendations (OData anyone?)
| codegeek wrote:
| " yet another new shiny web-framework"
|
| Funny you say that. JS..cough..JS.
| LaGrange wrote:
| > All the dis-advantages are not relevant for enterprise LOB
| apps, which Blazor is best suited for.
|
| The disadvantages: the _actual user_ is going to have a
| horrible time with the application. It will load slowly, work
| slowly, probably break the moment you inevitably _will_ have to
| touch JS, and if the browser the user hates anyway is out of
| sync with the forced updates, the entire thing will blow up.
|
| But enterprise LOB don't care.
|
| > I don't have to maintain the cognitive overhead of
| translating domain models into JSON models and vice versa.
|
| Every single time I've seen this attitude, it turned out that
| actually it just meant you're going to have a worse time when
| you inevitably had to do that translating.
|
| Java web applets aren't new. "Using models directly from the
| domain" is not new. Even when the runtime is friendly, the
| latter is a bad idea.
| brtkdotse wrote:
| > It will load slowly, work slowly
|
| Why do you think this will be the case?
| Capricorn2481 wrote:
| Well for Blazor Webassembly at least, you need to download
| the entire .NET runtime and WebAssembly isn't quite as fast
| as JS in browsers yet.
|
| Couple that with the fact that interoping with JS can be a
| lot more annoying than just using JS
| brtkdotse wrote:
| > Well for Blazor Webassembly at least, you need to
| download the entire .NET runtime
|
| It's a one-time download that's smaller than the initial
| load of the Facebook feed
| Capricorn2481 wrote:
| What about the CPU usage?
|
| Facebook loads a lot of information. I don't think we
| should be comparing the download size of a hello world
| app with loading dozens of images on a facebook feed.
| strich wrote:
| Honestly I'm afraid you don't know what you're talking
| about. Blazor just isn't that experience and hasn't been
| for awhile.
| Capricorn2481 wrote:
| Well color me convinced!
| littlecranky67 wrote:
| plus in LOB apps very likely to be in the browsers cache
| already. And dont forget buisness workstations are
| usually connected via at least 1GBit Ethernet.
| guhidalg wrote:
| I'm not who you're replying to but designing for excess
| resources is the kind of thinking that leads to slow
| software.
|
| > And dont forget business workstations are usually
| connected via at least 1GBit Ethernet.
|
| NOPE! More likely they are WiFi connected Dell shitboxes
| running Windows 11 with 8GB of memory, half of which is
| taken up by all the browser tabs, Teams, Office, and the
| 30 horrible little programs that IT deploys via group
| policy.
|
| Speed matters. The user is probably running your code +
| 30 other things. Don't assume your page is the only thing
| they care about.
| littlecranky67 wrote:
| Any data to back this up?
| citizenkeen wrote:
| Blazor Hybrid looks promising to completely negate the
| load time for Blazor WASM.
| Capricorn2481 wrote:
| Yes that does look promising for load time, but once the
| Webassembly is downloaded and being used, Non high end
| computers can easily choke.
| ninjis wrote:
| .NET 8 is suppose to greatly improve AOT. Depending on
| your use case, you might be able to get around bundling
| the runtime entirely.
| Capricorn2481 wrote:
| As far as I understand, .NET 8 AOT has nothing to do with
| the webassembly blob that gets served to the client.
| ninjis wrote:
| They're working on it. .NET 8 introduces the option to
| perform a degree of trimming on the AOT output.
| https://learn.microsoft.com/en-
| us/aspnet/core/blazor/host-an...
| merb wrote:
| Actually dotnet wasm can be further trimmed in .net 8.
| but for most non rtl people the biggest improvement will
| be to reduce the locale bundle. Sadly it's not possible
| to specify which ones you want. Also it's not possible to
| bundle DLLs/webcil. I.e the dotnet compiler will be
| shipped to the client thus you will also get shipped lots
| of dlls
| mbesto wrote:
| Serious question - do you know this to be in fact true of
| Blazor specifically, with real life comparisons, or is this
| just conjecture based on analogous frameworks?
| brtkdotse wrote:
| > I don't have to maintain the cognitive overhead of
| translating domain models into JSON models and vice versa.
|
| I'm more happy about not having to maintain working knowledge
| of two sets of IDEs, build tools, CI/CD pipelines, hosting
| models and testing framework and conventions.
| codegeek wrote:
| For me, just the fact that I don't have to deal with JS
| bullshit and ecosystem including node/npm hellhole is a win for
| me. Before these shiny JS frameworks came along, .NET already
| had great UI component libraries as well including syncfusion
| (my favorite) and many others.
|
| I only do VueJS when I do use JS but man I can't wait to not
| write any code in JS.
| mdasen wrote:
| Yea, I've been using Blazor in .NET 8 through the previews
| and it's really nice.
|
| The Server Side Rendering is fast like any server-rendered
| stuff. Enhanced Navigation means that pages load even faster
| since they're just using `fetch` to get the next page and
| swapping the content (like Turbo in Rails). When I need some
| interactivity, the page still renders from the server and
| then the browser downloads the WASM in the background.
|
| With .NET 8, Blazor is really ready. It isn't perfect, but
| it's so productive for me and the downsides are really
| minimal. Plus, it'll likely get a lot better with .NET 9 in a
| year because of WASM-GC (and post-MVP improvements to WASM-
| GC). With WASM-GC, .NET won't need to ship a garbage
| collector and WASM-based stuff won't need to copy between
| WASM and JS for DOM manipulations.
|
| Since people might want the "minimal" downsides, I'll put
| them here. If you're using Blazor SSR with WASM, after the
| first interactive page renders for the first time, there's a
| second or two before the interactivity is actually available
| while it downloads the WASM (on interactive components, not
| links or anything). If you were making a Facebook clone, it'd
| mean that the "like" button on posts wouldn't work for a
| second or two. This is pretty minimal for two reasons. First,
| it's just the first page load of the first interactive page.
| After that, the WASM is cached in the browser. Second, most
| of the time people need a few seconds to read the content
| before using an interactive bit. All of the navigation and
| such works instantly, but an interactive bit like a "like"
| button takes a second or two.
|
| If you want to get rid of that, you can use interactive-auto.
| This means that the first interactive page load will use a
| web socket and the interactive bits will be done with Blazor
| Server. It'll download the WASM in the background and switch
| to WASM for future page loads so you don't need the web
| socket for the vast majority of your stuff. However, web
| sockets do create a certain amount of hassle since you need
| to make sure that any proxies in-between handle web sockets
| and that you consistently route the user to the correct
| backend if you're load balancing.
|
| To me, those downsides are minimal and don't have a lot of
| user impact for me. This is in contrast with Blazor in .NET 7
| where I'd have to choose using a web socket all the time or
| having a big WASM payload that meant the page didn't render
| for a few seconds and gave users a crappy experience.
|
| If you're primarily creating something that would be server-
| rendered (like Rails or Django), Blazor offers that with the
| additional nicety that you can add interactive elements
| without needing to deal with JS. That isn't meant as a "JS is
| crappy" comment, but to note that having to deal with another
| ecosystem where you need to duplicate your models and keep
| them in sync, having to deal with another build system or
| glue things together yourself, etc. is a pain when it isn't
| your main focus. So many sites end up with a full front-end
| stack and all the hassle involved because they need a couple
| pages or want to keep a consistent component system. Blazor
| means that you don't have to go that route.
| halfcat wrote:
| > With WASM-GC, .NET won't need to ship a garbage collector
| and WASM-based stuff won't need to copy between WASM and JS
| for DOM manipulations.
|
| Does this mean the JS-interop performance penalty goes
| away?
| legulere wrote:
| Wasm-GC isn't compatible with .NET allowing references to
| fields among other issues. So I doubt that we will see
| integration soon
|
| https://github.com/WebAssembly/gc/issues/77
| evntdrvn wrote:
| I have faith that it'll happen eventually, in some form
| osigurdson wrote:
| The problem is, all of this stuff will probably be dead in a
| few years. I think they would be better off working within
| established paradigms rather than trying to do something
| completely new. How about, for example, making it as easy as
| possible to use React with a C# backend?
| pier25 wrote:
| React will die too, eventually. Or at least stop becoming the
| default.
| osigurdson wrote:
| Agree, but a dying star creates new life and pathways from
| old to new. A dying snowflake, just evaporates.
| seti0Cha wrote:
| I used to be a frontend coder, but am no longer. In part
| this is because I couldn't bring myself to keep up with
| the constant ecosystem churn of the JS world. I recently
| worked at a company that was trying to migrate from Vue 2
| to Vue 3. It was not going quickly. Is Vue going to even
| be around in a few years, or will React eat it entirely?
| Or will react itself be eaten by Svelte? I have no idea,
| I'm not involved in these things. But after watching how
| such things play out for a couple of decades, my
| conclusion is that if you are building for the web, you
| should use whatever you are comfortable with and what
| provides the features you want now, because there's no
| way to know what things will look like a few years down
| the road. Even if the framework you chose sticks around,
| you may end up doing a rewrite because of other concerns
| or throw the whole thing away altogether.
| Someone1234 wrote:
| Let's say it does: It leaves behind a WebAPI backend that
| [new hotness] can utilize. WebAPI is an agnostic protocol.
|
| What does Blazor leave behind? Nothing reusable at all. It
| is a proprietary server hosting proprietary connections via
| proprietary pipeline. Plus sometimes inscrutable
| WebAssembly. Just go ask all the companies STILL stuck on
| Web Forms or Silverlight how that worked out for them the
| last times? Exactly.
|
| Friends don't let friends buy into proprietary backends
| that muddy the water between UI/API layers. Stick to WebAPI
| and put whatever you want in front. That way you can
| migrate either front OR back independently of one another
| (and or do piecemeal migrations).
|
| PS - This has nothing to do with "Microsoft bad." This has
| to do with standard protocols between front/back Vs bespoke
| stuff. I'd also criticize the short-sightedness if another
| company offered the same thing.
| progmetaldev wrote:
| Best practices would dictate that you still build WebAPIs
| for your Blazor apps, to avoid that potentially
| happening. It will also give you a clean separation of
| concerns in your application. Even when I build a
| traditional MVC application, I still built out my API as
| a separate layer so I can change out the front-end in the
| future.
| Someone1234 wrote:
| So, in order to use Blazor safely, I need to develop and
| test everything twice. That's a death knell within
| itself. You just made my argument for me.
| progmetaldev wrote:
| Do you not bother testing your JavaScript?
| Someone1234 wrote:
| We're discussing which abstraction is between the
| backend/front end. You said, to use Blazor safely, I also
| need to deploy WebAPI. I said you therefore need to test
| and develop it all twice: Blazor and WebAPI.
|
| Your "question" is non-sequitur.
| halfcat wrote:
| > I need to develop and test everything twice.
|
| That's...literally the downside of frontend/backend
| separation of concerns...
| kqr wrote:
| You get a little closer with Fable to compile F# to
| JavaScript. It lets you model your domain using F# types
| (which are just as good as - if not better than - C# types)
| and then you can use them both from your C# backend and F# or
| JavaScript frontend (whichever you prefer.)
|
| It does require you to faff about with toolchains for
| building frontend code though (WebPack and the like), and
| it's not always completely seamless, but if you want to
| invest in a shared domain model it's the most compatible I've
| been able to go at least.
| theolivenbaum wrote:
| Or similar for c# with https://h5.rocks (disclaimer: author
| here)
| jmnicolas wrote:
| Contrary to Google, MS never kills any tech. You can still
| develop Winforms apps today.
| twisteriffic wrote:
| They don't kill it, they just tie it up in the basement and
| pretend it never existed.
| glonq wrote:
| RIP Silverlight
| unsignedint wrote:
| Silverlight's phase-out primarily stemmed from the
| browser ecosystem's shift away from plugins. It's worth
| noting that Silverlight 5 was supported until October
| 2021, a decade after its release, indicating substantial
| longevity despite the changing landscape.
| v-erne wrote:
| Ok first thing first - allow me to vent my existential
| frustration with few off the cuff (mostly rhetorical)
| questions ...
|
| You call decade a substantial longevity?
|
| Is this some kind of a joke?
|
| Is your ability to assess being held hostage by js
| ecosystem expererience?
|
| But seriously - I expect a bit more from platform that
| could potentially waste my life and my venture. I am
| still happily supporting some Java (and JSF) code that I
| have written for clients 15 years ago (don't you just
| love that sweet support fees that you get mostly for
| being alive and breathing ?). Meanwhile my friend that
| build whole company around product written in silverlight
| almost went bankrupt. Now after few years working in AI
| (going into it a bit too soon) he is trying to create
| same product in ... yes you guessed it, Blazor.
|
| Maybe some people do not learn from their mistakes :)?
| jodrellblank wrote:
| https://www.theregister.com/2023/10/10/microsoft_says_vbscr
| i...
| gwervc wrote:
| Blazor is just a new iteration on Volta (2007)
| https://en.m.wikipedia.org/wiki/Microsoft_Live_Labs_Volta
| starik36 wrote:
| That's because WinForms are in active development. But yes,
| for a while, it was baked.
| DylanSp wrote:
| Oh, that's handy, I thought MS had stopped supporting it.
| Good to know that it's still going. I thought they had
| dropped support in one of the .NET Core versions, before
| .NET 5+.
| jongalloway2 wrote:
| Presentation from .NET Conf 2023 last week with some of
| the new stuff:
| https://www.youtube.com/watch?v=N1weyWS_pL0
| DylanSp wrote:
| Thanks for linking that. The video description mentions
| they added WinForms to .NET Core in 3.0; maybe I was
| remembering the .NET Core 2.1/2.2 timeframe, when it
| wasn't supported in Core?
| steve1977 wrote:
| You can still develop Win32 and MFC apps today - those are
| more then 30 years old.
| jeroen79 wrote:
| Thats not always true, they keep some stuff that is a
| success for a long time, but they are also not afraid to
| drop there failures like ActiveX, SilverLight, VBScript,
| ...
|
| And i am afraid blazer may be next.
| johnnyballgame wrote:
| RIP FoxPro.
| mattmanser wrote:
| Silverlight, WPF, OData (was amazing for hooking your
| backend up to client-side tables, rubbish at everything
| else), WWF (Windows Workflow Foundation), WCF (thank god).
|
| All dead.
|
| And those are just the ones I can think of from the top of
| my head.
|
| Plus the terrible excel VBA replacement they made, then
| abandoned, and now it's some fiddly javascript mess.
|
| I'm sure there's a ton more people can add. Those are just
| the ones I personally wasted time on.
|
| And let's not forget Window Mobile!
|
| Edit: They've also gone through a stupid amount of changes
| in the asp.net MVC model in quite a short time. Plus
| constantly seem to overhaul their consistently
| overcomplicated authentication/authorization system. The
| state it's in at the moment is shockingly bad.
| strich wrote:
| You can't be blamed for having that opinion given history.
| But Blazor is I think standing on the graves of those
| previous attempts and is looking extremely strong - it is as
| of even a year ago mature, well supported, and a deep
| ecosystem.
|
| I think it's pretty safe to be optimistic at this point.
| password4321 wrote:
| Web Forms ("I'm not dead"), Silverlight, etc.
| george_sp wrote:
| I feel like your comment touched a million different places so
| I'll try to compose my arguments in a compact manner, hopefully
| to make some sense.
|
| > All the dis-advantages are not relevant for enterprise LOB
| apps, which Blazor is best suited for.
|
| Where does this conclusion come from? At least from my humble
| experience,I've been doing them for ~10 years with various
| tools, both JS and Blazor/Razor Pages and the fact that they
| "work" does not mean they stand on solid ground.
|
| I've written apps in Blazor, yet I don't understand its
| existence. Most apps, even LOB as you said, Razor Pages are
| more than enough. Razor Pages are amazing. What seems to me to
| be the source of the problem is the whole mentality: > But, as
| a developer who has done exactly one complex web app for a
| client, let me tell you, the ability to use C# models, directly
| from your domain, in web app markup code, using Razor
| components is a god send... You can ship server side generated
| HTML with Razor and just LEARN a bit of JS. I don't understand
| the allergy of the so called "back end" developers with JS. Yes
| it's shitty. Yes it feels better writing C#. I also like my
| bike more than my car. Will I take my bike to drive 500km? No.
| There's a time and place for everything. I feel efforts like
| Blazor just fight against the (unfortunate yet inevitable)
| current that JS is the only language that can manipulate DOM. I
| really think all of us should be open to use whatever makes
| sense for the job, even if it occasionally makes us feel
| uncomfortable. This is the dev community I want to be a part
| of.
| gedy wrote:
| > I don't understand the allergy of the so called "back end"
| developers with JS
|
| I think what many people are complaining about is that they
| actually dislike UI development and all the ambiguity and
| complexity. "JS" just catches blame for this. Modern JS and
| esp. TypeScript are pretty good languages, or at least
| comparable.
|
| A lot of these server side UI toolkits avoid some of the
| complexity by supporting basic UIs and flows, e.g.
| List/Show/Edit (which is fine in many cases), but to do
| complex UIs that many modern apps need, it's a huge pain.
| Worse situation to dev is forcing 80% of the functionality
| via server side, then the last 20% you ask "front end" to
| wedge in with jQuery style development.
| uticus wrote:
| As someone who suffers from this allergy, I'll chime in
| with 2 additional thoughts:
|
| It's not just that UI development is more ambiguous, it is
| the fact that it is difficult to make text-based code fit
| it. This is doubly (or maybe logarithmicaly) so when
| responsive (same code fit different screens). HTML, XAML,
| HAML, etc all require a _lot_ of code. Reusability
| mechanisms (like components, etc) help this but it is a
| world of difference from what BE devs are comfortable with.
|
| Thought #2: I'd guess BE devs like to just code, and the FE
| frameworks have a reputation of getting in the way of that.
| This is a less certain thought, so welcome opposition, but
| seems at least like part of the emotional reaction a BE dev
| would have to FE work.
| cl0ckt0wer wrote:
| I spend most of my dev time in typed languages. Going to
| untyped languages feels like going from K'nex to clay.
| Hunkler wrote:
| .NET 8 comes with Blazor United (renamed to simply Blazor)
| that combines the Blazor Server and Blazor WebAssembly
| frameworks.
|
| For client side components C# code is compiled into
| WebAssembly that manipulates the DOM just like JS.
|
| Today with Blazor Server, the main drawback is the slight
| delay you can get when you click something. .NET8 essentially
| blends Server and WebAssembly and solves the problem, even
| giving you the best of both worlds since WebAssembly has high
| first load times, .NET8 Blazor loads initially with Server
| side and provides client side after it loads all resources.
| JackMorgan wrote:
| I use swashbuckle and swagger-typescript-api to automatically
| scrape my controllers and generate API calls and TS types every
| time I rebuild. No hassle or overhead at all. No need for
| converters or anything.
|
| I've been using this now for several projects, it's a great way
| to have all the power of TS for client side and C# for server
| side.
|
| https://www.npmjs.com/package/swagger-typescript-api
|
| https://www.nuget.org/packages/Swashbuckle
| CharlieDigital wrote:
| I do the same.
|
| I have a small write-up here:
| https://chrlschn.dev/blog/2023/10/end-to-end-type-safety-
| wit...
|
| You get end-to-end type safety (even better once you connect
| it to EF Core since you get it all ways to your DB).
|
| With this setup with hot-reload (currently broken in .NET 8
| [0]), productivity is really, really good. Like tRPC but with
| one of the most powerful ORMs out there right now.
|
| [0] https://github.com/dotnet/sdk/issues/36918
| aerhardt wrote:
| I do the same in Django with drf-spectacular. I have a
| precommit hook that autogenerates (fairly thin) TypeScript
| schemas and routes on commit. This is not take merit from LOB
| devs who want to use C# back-to-front. I _will_ use it as an
| argument to those who say that this is why you _should_ go
| full TypeScript on any new web project though.
| switch007 wrote:
| N.B. the last commit/release for Swashbuckle was Jan this
| year.
|
| https://github.com/RicoSuter/NSwag might be a better choice
| for a new project. It look much more maintained and active
| than Swashbuckle
| dustymcp wrote:
| yeah nswag has been pretty consistent i can recommend
| aswell.
| SantiagoElf wrote:
| BBBBBBBBBBBBBBINGOOOOOOOOOOOOOOOOOO!
|
| Yes, at the end of the day, businesses use software in LOB
| apps.
|
| Period.
|
| Get shit done.
|
| WebForms/ASP.NET MVC/.NET Core MVC/Blazor will outlive ANY js
| framework.
| uticus wrote:
| Agreed. I mean really in the spirit of get er done the AS400
| is the pinnacle of UI for these sorts of things. I've worked
| with other things, even WinForm apps, Access things, Excel
| sheets that were turned into portable apps, and of course web
| pages. Green screen allowed 99% of things to get done faster
| with 1000% less fuss.
|
| https://en.wikipedia.org/wiki/Computer_terminal
| construct0 wrote:
| This may help if you'd like to keep front and backend(s)
| separated: https://quicktype.io/
| yread wrote:
| I consider myself more of a backend person but I feel I can
| deal with JS much easier than CSS. I learnt both in 15 yrs ago
| so compatibility with IE was crucial. Slap jquery on, stick to
| style guidelines so that variables are named consistently,
| avoid dependencies and it feels okish. There isn't anything
| like that to help with CSS though.
| renegade-otter wrote:
| As a backend dev primarily, learning CSS Grid really helped
| me filter out a lot of the BS.
|
| It's a UI framework that is 20 years too late, and with
| "lean" JS frameworks that are emerging, a lot of this UI
| development legacy can die a horrible death as far as I am
| concerned.
| zerr wrote:
| So is it like ASP.NET WebForms?
| klysm wrote:
| I had a terrible time with blazor. It's semantics are clunky
| bsuvc wrote:
| 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 wrote:
| > a proper front end framework
|
| Do you think a WASM approach has merit or do you think it is
| doomed?
| bsuvc wrote:
| 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 wrote:
| 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 wrote:
| Sounds a bit like Adobe Flex.
| avgDev wrote:
| 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 wrote:
| 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 wrote:
| 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/, which
| compiles .NET bytecode to JS) and also SharpKit
| (https://github.com/SharpKit/SharpKit which is built on Roslyn).
|
| But this will not necessarily be any better than compiling to
| wasm. It avoids the .NET interpreter, which decreases the
| download, but it will still need to bundle a lot of library
| support code. And getting the language semantics exactly right -
| including features like C# finalizers which do not have direct
| support in JS - is tricky, unlike with wasm. And it won't benefit
| from the speed of the wasm implementation in AOT mode (which
| Blazor supports), which can be much faster than JS.
|
| Compiling to JS definitely still makes sense in some cases, but
| it isn't an idea that Microsoft or the .NET community has somehow
| overlooked. It has been done and it has its own tradeoffs.
| girafffe_i wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| Shameless plug: 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.
| mattgreenrocks wrote:
| 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!
| grounder wrote:
| Trying to understand Blazor better. Is it a similar idea to what
| GWT tried to do with Java?
___________________________________________________________________
(page generated 2023-11-21 23:03 UTC)