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

291–300 of 302 posts

Re: .NET Blazor

#291

Post by sebazzz »

Capricorn2481 wrote: post #280
sebazzz wrote: post #251

Earlier quoted context omitted.

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…

Why are you using md5 functions on the frontend? We're talking about using javascript for frontend

Read again, Webpack used that.

Re: .NET Blazor

#292

Post by tester756 »

osigurdson wrote: post #140
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…

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?

>How about, for example, making it as easy as possible to use React with a C# backend?

Aint is easy already?

Re: .NET Blazor

#293

Post by uticus »

yCombLinks wrote: post #272
uticus wrote: post #206

Earlier quoted context omitted.

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

My first job required maintaining a very old informix 4gl app. The trained users could fly in that thing! Seeing clunky webapps with a bunch of clunky laggy UI components doesn't seem worth it for trained internal users

At my old job non-technical people would navigate about as well as they would with a mouse and a graphical-based interface, because the graphical interface didn't provide any additional value. For those people it took the same time whether read instructions and press key or read instructions and click button. Trained people were definitely faster, and often the user would type ahead of the terminal (with no ill effects) because they were inputting data close to their speed of thought about the process [0].

The point is, for this situation a text-based terminal offered no downsides and many benefits compared to a graphical UI. I suspect the same is true for a lot of other business solutions.

I've heard it argued before that graphical systems are easier to use, but in my day-to-day experience in the trenches with others who actually used the systems this argument was simply not true. I've also seen it hinted that graphical systems seemed more modern, so they got less emotional disdain. That rings more true to me. And really if I were in charge of such things I would acknowledge emotional disdain - even misplaced - may well count for something in the overall business picture.

Also, and maybe most importantly, if the green screen needed a new feature or bugfix, there was one person at corporate that would do that. They had about a half dozen devs working on other things but she was the go-to for the green screen features. So I imagine it's harder to hire people for those sorts of systems nowadays. However it was also interesting for me to note that one person didn't seem stressed out or overly busy and the system never had a major crash or bugfix. So, tradeoffs.

[0] The terminal was actually hosted inside a wrapper app inside Windows 7. So I ended up using AutoHotKey to great effect to get even more efficiency gains.

* edit: added footnote explaining how AutoHotKey could be talked about in same breath as green-screen dumb terminals.

Re: .NET Blazor

#294

Post by yndoendo »

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.

WinForms can still be used with all of the stagnant issues. Had a faulty touchscreen driver on Windows 10 that only affected the touchscreen event messaging in a WinForms application. Had to wire directly into the messaging pump, construct a custom event system, and override the WinForms event system for everything to work properly.

Also had to wire a custom touchscreen event system for WPF because the Microsoft method would latch on to UI components with quick taps and press with sliding. This caused buttons to stay pressed while no fingers where on the screen.

I cannot recommend WinForms or WPF or UWP. Microsoft is bad at GUI application frameworks. It was recently that they finally shipped VS2022 with proper WinForms designer support and the ability to move away from VS2019. I still need to close and reopen VS2022 daily for WinForms and WPF development.

QT, GTK or some other framework gives the ability for cross platform solutions without being anchored to Window OS. Non Microsoft GUI frameworks are also faster and better when deterministic response time is needed and ability to run on low powered computers.

Re: .NET Blazor

#295

Post by no_wizard »

v-erne wrote: post #256
unsignedint wrote: post #232

Earlier quoted context omitted.

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.

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

No knock on C# or Java developers meant here, however I find that C# and Java Developers find 10 years of support not long enough, nearly every other ecosystem you're lucky if you get 3 year time horizons of backward compatibility and/or support.

10 years is pretty amazing, all told, IMO.

Re: .NET Blazor

#296

Post by steego »

LaGrange wrote: post #267
cl0ckt0wer wrote: post #192

Earlier quoted context omitted.

I spend most of my dev time in typed languages. Going to untyped languages feels like going from K'nex to clay.

This is hilarious, because clay is just such an amazing material.

Clay is very malleable and has all sorts of wonderful properties. As a building material it has fundamental limitations as it’s less suited for tensile loads.

It’s funny, because you can continue the analogy and compare optionally typed languages (like TypeScript) to adding wood/rebar to a brick building, allowing it to go vertical.

A good example: the Chrysler building sports 3 million specially made bricks for its facade. By blending both materials, you receive the thermal and maintenance benefits of brick with structural integrity of steel.

Re: .NET Blazor

#297

Post by cxr »

bragh wrote: post #258
cxr wrote: post #216

Earlier quoted context omitted.

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…

Not sure that I follow... From what I have understood, a lot of corporations have these kind of set ups in place to avoid downloading malicious software, limit the possible impact of malware, monitor employees and so on. And it is clear that no development team can change policy for whole organization — so why shouldn't developers choose the kind of tooling which allows them to deliver within the constraints of the o…

You are taking it as a given that developers are making these choices at organizations where it is normal for them to have to fire a nailgun through the palms of their hands at the beginning of the day. I'm saying that when developers are making these choices they should be doing so at organizations where it is a given that they don't have to do that.

Re: .NET Blazor

#298

Post by Capricorn2481 »

sebazzz wrote: post #291
Capricorn2481 wrote: post #280

Earlier quoted context omitted.

Why are you using md5 functions on the frontend? We're talking about using javascript for frontend

Read again, Webpack used that.

Is gulp really better than webpack in this case? I have a few gulp projects and they're not exactly standing up to the test of time.

Re: .NET Blazor

#299

Post by tankmohit11 »

I develop company's internal tooling using Blazor Server, and have developed moderately complex and data intensive applications. As a former React Developer who has spent most of his time working with Node.js and JavaScript tooling, Using Blazor WA and Server felt like a breath of fresh air. C# is joy to write and everything fits very well with existing enterprisy Microsoft services.

State management is pain in React, until you install 3rd party libraries (Jotai, Zustand etc.), each value needs to be bound individually.

Dotnet command line felt very snappy compared to npm/pnpm.On my crappy company laptop, when a nextjs application dev server starts, my blazor server app has already opened a browser tab with website running locally. efcore is also good.

Overall working with blazor felt like working with Vue/Svelte, but with faster performance on backend. Nowadays I only touch React if strictly necessary.

Re: .NET Blazor

#300

Post by LaGrange »

progmetaldev wrote: post #278
LaGrange wrote: post #270

Earlier quoted context omitted.

> You install a package today. In 3 months, that code won't build. Skill issue. Like I do that regularly. And I'm not even particularly great at frontend tech, so after 3 months I need to hit the docs to actually change anything. But the build pipeline works just fine. > And I did I get to the 100s of config files that need to be set just so I can run "npm build" ? ..."webpack.config.ts", "package.json" and "package-…

Your way of upgrading front-end tech, where you need to hit the docs, sounds exactly like moving from the different .NET technologies to the latest version. I still tend to build out classic MVC applications, and use JavaScript only for progressive enhancement. I've been able to move from .NET Framework to the different versions of .NET Core, and now just .NET. I just follow the documentation, Microsoft has great doc…

> Your way of upgrading front-end tech, where you need to hit the docs, sounds exactly like moving from the different .NET technologies to the latest version.

What front-end tech, everything is typescript.

Also not upgrading. I need to read the readme file because I didn't run the software in 3 months. Point is, it will _still run_. It might need a few updates for security reason, but it will _not_ magically stop working.

> It just sounds like you are more familiar with working with front-end tech,

No. I'm a full-stacker, but very much focused on backend, and actually mostly in Python. But nodejs + typescript actually works well enough that, even with _decades_ of Python experience, I now need a proper reason to pick it over typescript for a new thing.

> I'm not trying to convince you to change technologies, but if you're familiar with a specific process, it's always going to be easier to follow that process than something you're not familiar with.

Yep. Maybe the reason why some folks struggle so hard with running their old JS stacks, rather than some .net superiority?

Post reply on HN