Not using React anymore, but it's generally not an easy decision whether to use a framework for a SPA or not. Currently I'm torn between Nuxt and Vue with Vue Router. Nuxt has many fun QoL features, but adds a significant layer of potential issues (bugs, maintainability, leaky abstractions over the core library).
My tendency is to have an easier life in the future. So I'd probably prefer not using an universal rendering framework like Next, Nuxt, SvelteKit or SolidStart in client side mode and just use the core SPA framework. In case of Vue, it's even easier (but without those QoL features Nuxt provides).
I used C# on .NET framework (the old .NET running only on Windows) 10 years ago at work. Then I had to use it 2 years ago again, and man, did it change! ASP.NET Minimal API is absolutely awesome, as the Generic Host integrating config, logging and DI is a great too. A very mature and complete framework.
It brings everything to the table a great modern language and ecosystem needs. Even null safety.
Regarding error handling, I don't have a strong opinion yet. I think Rust has nailed it, but C# (with unchecked exceptions) didn't create any issues in the projects I worked on.
> This feels similar to C# and Microsoft's other CLR/.NET languages. Sure, they've broken away a bit and aren't exclusively used to run things on MS platforms, but still.
A wrong and quite outdated statement. You can develop and run C# on Linux only using open source tooling perfectly fine. I'm using Ubuntu, LazyVim with Omnisharp, dotnet CLI for scaffolding and package management. It's in the same ballpark as Go and Rust in terms of dev experience. I don't have numbers, but I guess a large fraction of new deployments is on Linux.
I don't understand why it's a good idea to couple tooling or configuration or infrastructure (e.g. Aspire.NET, which I'm also not convinced of being a good idea) so tightly with the application. An application should not need to be aware of how whatever tools are implemented or how configuration or infrastructure is managed. The tooling should point to the application as dependency. The application should not have any dependency on tooling.
Extremely interesting topic, unfortunately shallow article. Still I'm happy for the input.
I'd like to learn more about how abundance of food, lack of threats and other comforts of civilization distort the formerly vital instincts into all kind of dysfunctional and harming behavior. And more importantly, how to manage those.
Damn, thanks for your insights. I recently discovered how much better I sleep when fasting. During my fasts I'm taking precise amounts of electrolytes (sodium, magnesium, potassium: https://en.wikipedia.org/wiki/Oral_rehydration_therapy). Being off my fasts I'm getting sloppy with my electrolytes intake and here we are: I'm getting the same symptoms you describe. Not severely, but noticeably.
Now I need to find a proper supplement in Germany. Most electrolytes that also have the recommended amounts of glucose contain artificial sweetener which is a big no-go for daily usage for me.
I'm not convinced by .NET Aspire. It solves a small problem (service discovery and orchestration for local development of multi service projects). But it solves this by making service discovery and orchestration an application level concern. With Aspire you needlessly add complexity at the app level and get locked into a narrow ecosystem. There are many proven alternatives like docker compose for local development. Aspire is not even that much if at all easier than using docker compose and env vars.
I was looking for a mature, complete and powerful statically typed stack as well. ASP.NET was my clear answer (not Go or Rust).
There's a lot of noise coming from Microsoft to sell their new products (this year: Aspire.NET). But don't be mislead by this noise: .NET Core (C#, ASP.NET Minimal API or MVC, EF Core) is more batteries included and reliable than most other options. The only gripe I have is the need to get into the OOP and DI mindset ("create custom implementations of some abstract classes and put them into DI and the framework calls your implemented methods magically" kind of stuff). Takes some time, but not a big deal for experienced devs (and younger ones can learn faster anyway :-)).
The problem is finding fresh blood who want to write C#. RoR or Django is a much safer choice in that regard. This OO/DI stuff has fallen out of fashion (whether that’s good or bad, I don’t know) and very few enjoy working with these constructs anymore.
That's true. Once upon a time when I was intern I was charmed with ASP .NET.
Couple of years later I had opportunity to work with Django. Everything looked so batteries included, felt hackable and syntax was friendlier to me (Only exception ORM).
Unfortunately project got on hold and I was moved to write new service in ASP .NET.
Holding mental model of Dependency Injections, everything OOP, boilerplate produced is cumbersome, CamelCase...
It's a top-heavy market because the industry-wide growth and momentum was 2001-2008. Since that period, the available alternatives for entry into a dev career have increased. Python/Ruby/JavaScript tend to be what most juniors are encouraged to focus on. There are new waves of C# enthusiasts, but the growth in dev overall has drowned it out.
Could be, but the wave is against OO languages, and unfortunately, juniors often show unwarranted disregard for the paradigm. We’ve had good interviewees who flat-out told us they weren’t interested in working with any Microsoft stack—including C#, .NET, and Azure—and they definitely weren’t the only ones. Betting on Python, JS, and Go is way safer, and many new startups reflect that.
I'm surprised you've had trouble finding juniors in this market. What sources were used to build the candidate pool? I'm even more surprised to hear that finding Ruby juniors was easier.
My tendency is to have an easier life in the future. So I'd probably prefer not using an universal rendering framework like Next, Nuxt, SvelteKit or SolidStart in client side mode and just use the core SPA framework. In case of Vue, it's even easier (but without those QoL features Nuxt provides).
reply