Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

.NET Blazor

dusted.codes

Post reply on HN
Print view View original

111–120 of 302 posts

Re: .NET Blazor

#111

Post by FrustratedMonky »

mastry wrote: post #92
FrustratedMonky wrote: post #79

===>>> 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…

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.

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.

Re: .NET Blazor

#112

Post by cxr »

jcmontx wrote: post #72
torginus wrote: post #55

Earlier quoted context omitted.

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.

> proprietary Microsoft weirdness .NET (and Blazor) has been open source for at least 7 years now

Something can be both open source and proprietary. Flex has been open source for even longer. Still proprietary. See also: XUL.

Re: .NET Blazor

#113

Post by kumarvvr »

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.

Re: .NET Blazor

#114

Post by spzb »

KronisLV wrote: post #75
sebastianbk wrote: post #27

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 dev…

> 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 th…

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

Re: .NET Blazor

#115

Post by louthy »

kumarvvr wrote: post #113

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…

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

Re: .NET Blazor

#116

Post by acdha »

throwaway_0235 wrote: post #109
sanitycheck wrote: post #77

Earlier quoted context omitted.

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 hav…

> Flash was always going to die someday though, as HTML/JS caught up with it. I'm not sure that would happen. I think Flash would evolve to just "compile" to HMTL/JS. IOS/Android could be other targets as well, once they found a way that would not upset the Eye of Apple.

Not if Adobe was developing it. Flash was terrible for performance and battery life, and it was wedded to the classic fixed-size window with a keyboard and mouse. Even Android users who had access hated it.

Now, it’s possible that some of that could’ve improved (battery life would’ve been hard due to the scene timing model) but Adobe just isn’t a platform company. They didn’t even want to fix the security problems, much less all of their half-assed APIs - they were even worse than Sun for announcing ambitious frameworks duplicating built-in OS features, shipping the easiest 40%, and then letting it stagnate because there was no way fixing the hard stuff would get them a second keynote.

Re: .NET Blazor

#117

Post by kumarvvr »

louthy wrote: post #115
kumarvvr wrote: post #113

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…

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 (buil…

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.

Re: .NET Blazor

#118

Post by LaGrange »

kumarvvr wrote: post #113

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…

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

Re: .NET Blazor

#119

Post by DonnyV »

useerup wrote: post #60
madeofpalk wrote: post #42

Earlier quoted context omitted.

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.

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 brows…

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

Re: .NET Blazor

#120

Post by louthy »

kumarvvr wrote: post #117
louthy wrote: post #115

Earlier quoted context omitted.

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 (buil…

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…

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

Post reply on HN