Hacker News Reader

Comment by brushfoot | Hacker News Reader

.NET has been doing a lot of things right. My startup's codebase is nearly all .NET 7: landing page, web app, Windows service, API. The main non-.NET code is vanilla JS in the web app.

I've been keeping a close eye on Next.js, which is very well done, but I love how versatile .NET is. With one language, I can write all of the above, and my dependencies are minimal thanks to .NET's rich standard library - a refreshing change from the NodeJS apps I've written and maintained.

With native AOT, .NET can even be compiled to native binaries. Recently, I wrote a Windows password filter DLL in C#, which would have been unthinkable some years ago.

It's a really enjoyable stack to work with. Kudos to Microsoft for what they've been doing with it.

View on HN

Nextjs (and its contemporaries) work really well with .NET. Toss in your API calls into Next, write a beautiful front end, and now you've got separate front end and back end that works phenomenally together and can be tested separately using their strengths.

I'm more shocked by you sticking with Javascript. Surely with your adoration of C# you would have moved to its closely related sibling Typescript. Although I guess there is that slight initial hump to move to TS from a purely vanilla project.

> Nextjs (and its contemporaries) work really well with .NET. Toss in your API calls into Next, write a beautiful front end, and now you've got separate front end and back end that works phenomenally together and can be tested separately using their strengths.

Is it somehow different than using any other language for your backend? Seems to me you're describing any frontend/backend split, nothing specific to either Nextjs or .NET here.

> I'm more shocked by you sticking with Javascript. Surely with your adoration of C# you would have moved to its closely related sibling Typescript. Although I guess there is that slight initial hump to move to TS from a purely vanilla project.

Some people prefer to stick with vanilla JS because that's what the browser ends up running anyways. Personally, TypeScript tends to get more in the way than be helpful for certain type of projects, while for others, TypeScript helps a lot but tends to be when the codebase involves a lot of contributors of varying skill-levels rather than a small circle of contributors with relatively high knowledge of programming and JavaScript in particular.

Feel free to replace Next with another framework if that's more you're liking. Same benefits apply.

I'm not so sure experts of JS would avoid TS just because they're experts in JS. The opposite even, being experts they know how many footguns JS has, and TS just comes with far too many benefits for any project that is to be maintained for longer than a week.

Frontends often have a much shorter lifetime than backends. A good example are banks, they change the online banking frontend approximately every 10 years, but a lot of backend systems are running since the 80s/90s without complete rewrites.

It makes a lot of sense to decouple them, and just re-write the frontend to whatever technology is the best for its time. It’s also not uncommon to have multiple frontends, for example a web application and also a native android/iOS app.

How do the costs of running the .NET 7 codebase compare with running something open? I like .NET a lot, have worked with it a lot in the past. But when I tried my own startup, I picked node instead and don't really regret it. I'm getting back into .NET these days though at a new job again, and .NET 7 will be interesting to dive into. Still not sure I'd want to be that tightly-coupled to Microsoft subscriptions though. I'd tried getting a couple .NET projects off the ground back in the .NET 5 days or whenever .NET Core first became a thing. It was surprisingly expensive to run things in Azure, and to use tools too. So that played a role in me just picking node for my startup even though I'd have preferred to stick with C# and .NET if I could, so I could become an expert in those tools.

But yeah, it's definitely a huge plus to have access to .NET's massive standard library. The documentation is amazing, too. If the costs to run in Azure and to be tightly-coupled with Microsoft rthat way are reasonable for a lean/small startup or self-funded startup, then I may give it a shot again.

.NET IS open and not really tied to any Microsoft Subscription. I really hate when people keep parroting that without understanding. Rider is nowadays a better IDE for C# and it's not owned by Microsoft. You can host it wherever because it runs wherever.

Nah, Rider only better on cross platform Web development, and even then it fails short for Blazor.

In my experience, Rider is much a better IDE for development, especially on large codebases. In our few million LOC codebase, VS lags/hangs a lot, navigation is slow, search (like searching for a log string in a codebase) is awfully slow. Refactorings are not useful w/out Resharper etc.

VS has a lot of useful stuff around profiling, performance analysis etc, but as a code editor it's pretty bad.

VS lags/hangs a lot with Resharper installed. As someone who doesn't like/trust Resharper, I have a very different experience of VS performance.

(Also, Roslyn built-in refactorings have gotten so good, I increasingly feel like I should just develop more in VS Code because the language server is the same.)

It's just like any other containerized Linux app. The only thing worth noting, that base asp net core api will idle like 200mb memory.

> Still not sure I'd want to be that tightly-coupled to Microsoft subscriptions though.

No need for MSDN subscriptions these days, although they do come with some perks.

> How do the costs of running the .NET 7 codebase compare with running something open?

.NET has been open source since .NET Core 1 in 2017. The source code is on GitHub: https://github.com/dotnet/

What do you mean open? It is open

Building my startup on .Net as well. Been a huge fan for over a decade but haven't written professional C# in over 8 years. It's been a dream to write OSS b2b .Net based IT tooling for years now(C# or my language crush F#); and here I am :)

Using Asp.Net 7 for the server component with React and Vite as the FE tooling. Been a HUGE learning curve the first couple months particularly around the DI, options pattern, Asp.Net auth and Identity and etc but everything is falling into place now. Also SignalR is much more low-level than it pretends to be lol.

It would have been easier to go straight NodeJS as I'm quite proficient in writing even framework level code in it(down to the sockets), but I believe .Net is the better option for this long term.

Fortunately NextJS and .Net isn’t strictly an either/or proposition. I’ve moved most of my new front-end development to NextJS at this point and use C# for most everything behind it.

A few years ago, the authentication/authorization story was quite tough to configure in this setup. Did things change recently?

It really just depends on what you're trying to do I guess. The main auth boundary for my projects is typically the server gateway/api, and that's very straightforward to set up, whether you want simple auth or role-based or to inspect JWT claims or whatever.

Reply on news.ycombinator.com