Live data from Hacker News

.NET Blazor

dusted.codes

1–10 of 302 posts

Re: .NET Blazor

#2
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?

Re: .NET Blazor

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

Re: .NET Blazor

#4
post #2

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…

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.

Re: .NET Blazor

#5
post #2

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…

Some people just don’t enjoy front end work, and vice versa

Re: .NET Blazor

#6
post #2

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…

Some people just don’t enjoy front end work, and vice versa

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.

Re: .NET Blazor

#7
post #4
post #2

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…

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.

There are many of us working at smaller companies who do all of the above.

Re: .NET Blazor

#8
post #4
post #2

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…

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.

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.

Re: .NET Blazor

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

Post reply on HN