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

My preferred .NET console stack

devlead.se

Post reply on HN
Print view View original

71–80 of 119 posts

Re: My preferred .NET console stack

#71

Post by bob1029 »

ripley12 wrote: post #41
nend wrote: post #30

Earlier quoted context omitted.

Blazor is still a bit rough around the edges but I find it so promising. I really hope Microsoft whole heartedly embraces it for front end development.

Have you seen the Blazor work planned for .NET 6? Hot reload and desktop apps with Blazor UI are both priority-0 (ultra-high priority) epics, I'm really looking forward to it. https://themesof.net/

Hot reload would probably cut my implementation time in half on this current project. Regardless, its still lightyears better than developing some javascript SPA and fighting all that extra boilerplate.

Re: My preferred .NET console stack

#73

Post by Sn0wCoder »

My colleague had a windows issue and I have been getting a box setup using scoop and winget. Going to play with this. Day job OS X, but my win10 box is getting some love and this is good motivation to experiment. Cheers!

Re: My preferred .NET console stack

#74

Post by mayli »

disgrunt wrote: post #42
pierrebai wrote: post #38

For Python, I've standardize on click. It provides simple decorator to turn functions into commands, sub-commands, etc, with easy options and built-in help.

Click is great and a feature-rich option. But recommend checking out Typer, which is even simpler if you're already using type annotations. [0] [0]: https://github.com/tiangolo/typer

That's why people use python, to avoid tons of .NET console boilerplate that does pretty much nothing.

Re: My preferred .NET console stack

#75

Post by ripley12 »

oblio wrote: post #62
ripley12 wrote: post #33

Earlier quoted context omitted.

> And you end up with a console app that is 20-100MB. FWIW, this is sort of a legacy of .NET's "enterprisey" history. Code size and trimming wasn't really a priority when most .NET code ran server-side or inside enterprises, now it is. There's been a lot of work happening recently to trim .NET executables and publish them as single files, and it looks like .NET binary sizes will eventually be in the same ballpark as…

Don't hold your breath. I've been keeping an eye on CoreRT and it actually slowed down and even regressed compared to Dotnet Core's rate of development while I was watching it. I think maybe in 2016? 2018? they were committing a lot to it, probably hoping to make it production ready. Then priorities shifted and they barely advanced and now they moved it into "runtimelab" which doesn't bode well to me.

My understanding is the opposite; now that they're planning to merge Mono and CoreCLR, there is significantly more pressure on the .NET team to have a proper AOT solution.

"Early adopters can experiment with native AOT form factor" is a priority-zero (highest priority) epic for .NET 6: https://github.com/dotnet/runtimelab/issues/248

Re: My preferred .NET console stack

#76

Post by Sn0wCoder »

nend wrote: post #30
bob1029 wrote: post #5

Spectre.Console looks like a really neat library. I am going to have to check this one out for some of my CLI utilities. With the advent of Blazor, you could also look at building rich UX on top of the very same business services used in the console variant. I have found that Blazor is productive enough to consider using universally for management/configuration/admin dashboards for whatever business process. You coul…

Blazor is still a bit rough around the edges but I find it so promising. I really hope Microsoft whole heartedly embraces it for front end development.

Second this. Want to use blazor but worried they are going to pull the rug out from under us, siverlight anyone (smile)

Re: My preferred .NET console stack

#77

Post by OniBait »

hacker_9 wrote: post #16

As a .Net developer I've.. never seen people write code at work like this. This looks like a hefty amount of boilerplate to achieve practically nothing. I'm guessing this guy learned Asp.Net first.

That is because he's giving a tiny example of a starter template for a console app.

If you were writing a "production-level" console app with multiple commands, logging, needed DI, input validation, nice looking progress bars, etc. Then this is pretty much what I'd want for a console template tbh.

Spectre.Console looks insanely nice.

Re: My preferred .NET console stack

#78

Post by mattferderer »

kertoip_1 wrote: post #67
nend wrote: post #30

Earlier quoted context omitted.

Blazor is still a bit rough around the edges but I find it so promising. I really hope Microsoft whole heartedly embraces it for front end development.

The biggest issue with it is a really large binaries that have to be downloaded on page start. So it isn't necessarily suitable for use cases where speed matters. But at the same time, it's perfect for dashboards, I really like to work with it.

Most large websites could do a little extra work on trimming their image size & be fine with the size of Blazor with WASM.

Re: My preferred .NET console stack

#79

Post by tester756 »

erikbye wrote: post #40
lol768 wrote: post #29

Earlier quoted context omitted.

> And you end up with a console app that is 20-100MB What are you talking about? It's 1.4MB. This is the easiest thing in the world to verify: $ dotnet publish -c Release Microsoft (R) Build Engine version 16.8.3+39993bd9d for .NET Copyright (C) Microsoft Corporation. All rights reserved. Determining projects to restore... All projects are up-to-date for restore. ConsoleApp -> /tmp/ConsoleApp/bin/Release/net5.0/Conso…

> And no, I don't want to hear about any figures for self-contained builds. Then what is your point? When talking about the size required for a program to run, you have to weigh all of its dependencies. For anyone interested, such a binary ends up at least 50MB, if we include the dependencies mentioned in the article in question.

in my opinion it is not the greatest argument

You write:

>And you end up with a console app that is 20-100MB.

Yea, but you can also say

>And you end up with a decent size app that is 20-100MB.

and also you can say

>And you end up with a decent size app that is 2MB

because you already have runtime, because you use .NET apps.

Re: My preferred .NET console stack

#80

Post by blargmaster42_8 »

bob1029 wrote: post #5

Spectre.Console looks like a really neat library. I am going to have to check this one out for some of my CLI utilities. With the advent of Blazor, you could also look at building rich UX on top of the very same business services used in the console variant. I have found that Blazor is productive enough to consider using universally for management/configuration/admin dashboards for whatever business process. You coul…

Uno seems like a better option.
Post reply on HN