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

171–180 of 302 posts

Re: .NET Blazor

#171

Post by gedy »

george_sp wrote: post #155
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…

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

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

Re: .NET Blazor

#172

Post by Capricorn2481 »

ninjis wrote: post #164
Capricorn2481 wrote: post #133

Earlier quoted context omitted.

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

.NET 8 is suppose to greatly improve AOT. Depending on your use case, you might be able to get around bundling the runtime entirely.

As far as I understand, .NET 8 AOT has nothing to do with the webassembly blob that gets served to the client.

Re: .NET Blazor

#173

Post by Capricorn2481 »

citizenkeen wrote: post #156
Capricorn2481 wrote: post #133

Earlier quoted context omitted.

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

Blazor Hybrid looks promising to completely negate the load time for Blazor WASM.

Yes that does look promising for load time, but once the Webassembly is downloaded and being used, Non high end computers can easily choke.

Re: .NET Blazor

#174

Post by _gabe_ »

Cthulhu_ wrote: post #19
jve wrote: post #6

Earlier quoted context omitted.

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.

That's my issue as well; over the years I've developed some insight in visual design and UX, but it's not my strong point and I don't want to be responsible for design. Luckily, I've always worked with designers and people who are better at CSS. My point is, I've done front-end for most of my career without having to do design work.

> over the years I've developed some insight in visual design and UX … Luckily, I've always worked with designers and people who are better at CSS

These two things are completely tangential. Translating a design into well structured HTML/CSS should not require any UX or design experience. In the same way, you don’t need to know HTML/CSS to create a good design and UX.

Re: .NET Blazor

#175

Post by seti0Cha »

osigurdson wrote: post #150
pier25 wrote: post #145

Earlier quoted context omitted.

React will die too, eventually. Or at least stop becoming the default.

Agree, but a dying star creates new life and pathways from old to new. A dying snowflake, just evaporates.

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.

Re: .NET Blazor

#176

Post by [deleted] »

louthy wrote: post #120
kumarvvr wrote: post #117

Earlier quoted context omitted.

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…

[deleted]

Re: .NET Blazor

#177

Post by azakai »

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.

Re: .NET Blazor

#178

Post by girafffe_i »

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.

Re: .NET Blazor

#179

Post by theolivenbaum »

kqr wrote: post #154
osigurdson wrote: post #140

Earlier quoted context omitted.

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?

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

Or similar for c# with https://h5.rocks (disclaimer: author here)

Re: .NET Blazor

#180

Post by poszlem »

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?
Post reply on HN