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

241–250 of 302 posts

Re: .NET Blazor

#241

Post by realusername »

codegeek wrote: post #142
louthy wrote: post #124

Earlier quoted context omitted.

Sure, do you have a point you'd like to make?

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…

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

Re: .NET Blazor

#242

Post by johnnyballgame »

jmnicolas wrote: post #157
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?

Contrary to Google, MS never kills any tech. You can still develop Winforms apps today.

RIP FoxPro.

Re: .NET Blazor

#243

Post by siquick »

ttymck wrote: post #39
siquick wrote: post #7

Earlier quoted context omitted.

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

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.

That was not the context the OP was addressing.

Re: .NET Blazor

#244

Post by unsignedint »

davidhyde wrote: post #43
TrackerFF wrote: post #23

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

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

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

Re: .NET Blazor

#245

Post by legulere »

mdasen wrote: post #195
codegeek wrote: post #134

Earlier quoted context omitted.

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.

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…

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

Re: .NET Blazor

#246

Post by dustymcp »

switch007 wrote: post #222
JackMorgan wrote: post #170

Earlier quoted context omitted.

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/packa…

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

yeah nswag has been pretty consistent i can recommend aswell.

Re: .NET Blazor

#247

Post by evntdrvn »

legulere wrote: post #245
mdasen wrote: post #195

Earlier quoted context omitted.

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…

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

I have faith that it'll happen eventually, in some form

Re: .NET Blazor

#248

Post by gustavus »

DonnyV wrote: post #119
useerup wrote: post #60

Earlier quoted context omitted.

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

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

Re: .NET Blazor

#249

Post by peheje »

Tao3300 wrote: post #104

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?

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.

Re: .NET Blazor

#250

Post by devjab »

neonsunset wrote: post #141
devjab wrote: post #99

Earlier quoted context omitted.

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…

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.

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: https://news.ycombinator.com/item?id=37538333&p=3#37541652

Where I also point out other, similar issues with other parts of the .Net batteries.

Post reply on HN