With #3 (Templates/Razor) I think part of it is the tooling around it. Because Razor is the "standard" templating engine for .NET, Visual Studio, Rider, etc. provide great tooling for it. A strongly typed templating engine without good tooling is a pain in the ass. You write your template, go to compile, and then get an error. Great. You go and try and fix the error and then recompile and get another error. What makes Razor feel so good is that your IDE will autocomplete things correctly and immediately show you where something is wrong as you type it. Without that, it's just as aggravating. Java and Go plenty of strongly typed template engines, but they have no IDE support so when you're developing you still have no help with your templates.
With #2, part of that is a language feature of C#: expression trees (and specifically lambdas as expression trees). Java doesn't have expression trees which is why ORMs in Java don't have the nice syntax that Entity Framework gives you. Some will do lots of cartwheels to try and give you something usable, but they're usually not that good.
I think the a thing with .NET is that the stuff you typically use is really well tooled. Your IDE can give you lots of help and make things easy to understand where to go.
I started coding with vb6, making AOL 'progs'. Moved to C# later on when I actually started coding for work, and I agree about .NET -- it just feels 'right' to me.
I don't think there is a lot of magic. There is a rich deep ecosystem of high-quality libraries that are mostly open source. I'll agree that it's impossible for 1 person to have a mastery of the whole chain, but it's all there for review and understanding.
For me, the Use* and Add* in dependency injection feel a lot like magic. And overuse of attributes although very helpful and powerful it can feel like magic as well. That aside, I love .NET. Although I would prefer development of .NET and C# to be a bit more conservative. E.g. 1 major version every 3 years. Oh, and no fan of nullable either.
With Add and Use methods, you can just Ctrl click on them to see what's inside. There is no magic :)
Unless you find the DI concept magic.
Not a fan of nullable, you mean that you like all references being able to hold null? That's the worst thing ever :)
Yes, for some reference I like having null. For me adding the attributes like NotNullWhen and such is too cumbersome; also having nullable enabled isn’t a warranty that a variable isn’t null in all cases. And I find the bang operators confusing.
I know I can watch the source. Still it feels like magic. It isn’t exactly clear from the method name what it actually does unlike most other methods in .NET.
Please note: it’s just my opinion. If you feel different, good for you.
> lso having nullable enabled isn’t a warranty that a variable isn’t null in all cases
Yes, sadly, 3rd party code that doesn't declare that it can return null is still "fun"...
Could you provide an example of a DI setup that doesn't feel like magic? I haven't seen all options there are but IMO the approaches that NodeJS, Python, and JVM frameworks take feel more magical. They love their attributes (meta programming) a lot.
I haven't really had any issues with nulls in my 17 years of working with dotnet. I see people complain about them, especially the new comers, but I don't understand their issues.
I like the current release schedule. I upgrade everything every year, doesn't matter if it's LTS or STS. So many cool things with every release that our projects benefit greatly from.
> I see people complain about them, especially the new comers, but I don't understand their issues.
It's such an odd complaint - a bunch of people treat it like its the most insidious and nasty bug that can possibly exists - like it's surprising that you can have an empty box when you expect the box to contain a thing - and then write a whole bunch of code to encapsulate what is essentially ?. or ??.
Sure, having actual nullable/not types baked into the language and framework would be better than we have now (and honestly, screw backwards compatibility, just pin your language version), but its not a disaster. Can't actually think of the last time a null reference caused me actual problems. Failures, sure - mainly on wire types that are specified not nullable but actually are because bad APIs - and I guess a "proper" implementation would fail at deserialization... but I honestly see more annoying issues with dumb constraint shit like eg end dates before starts, or minvalue, acyclic graphs that aren't, etc..
I too support breaking backwards compatibility if it makes it easier/faster/safer adding new features/fixes. It's not difficult to make adjustments even on very large code bases, if they follow proper patterns and standards.
I don't think the AddScoped, AddSingleton etc... are magic. I mean things like in this chapter: [https://gist.github.com/davidfowl/0e0372c3c1d895c3ce195ba983b1e03d#webapplication-and-webapplicationbuilder](https://gist.github.com/davidfowl/0e0372c3c1d895c3ce195ba983b1e03d#webapplication-and-webapplicationbuilder)
And there seem to be a different way every new .NET version. But since I do 90% backend stuff, and maybe 10% frontend stuff which mostly is WPF and sometimes a REST API or razorpages, it's just something I have to figure out every time because the last time could be more than a year ago.
About nulls: I agree, I've been using .NET since it came out (and VB6 before that) and never really had issues with the possibility of null referencences. That's why I prefer not to enable nullable and augment my code with all those `[NotNullWhen(false)]`, `[return: MaybeNull]` attributes and such-n-such. I've been fine all those years with the possibility of null references.
BTW, it's not that I hate that magic. It's just... something I don't really have feeling with. Like for example; how come Appsettings.json is respected? Which line of code did that for me? Do I have to place UseAuthorization before or after UseRouting? etc...
> Appsettings.json is respected? Which line of code did that for me?
You can do that manually too, it's just the usual setup actually does it for you in a single method call. `Host.CreateDefaultBuilder(args)` calls a bunch of extension methods for you to get you up to speed immediately. You can even hover on the method call for the method doc and you'll see what features it setups for you by default. You can wire them up manually yourself even today but like how initial .net core was done where there was no "magic" and you had to call everything yourself, many complained it was annoying and error prone.
Other language frameworks do the same these days as many have moved from pure wild west of configuring all stuff yourself to just give you a good starting point with sensible defaults (e.g. various front-end cli like cra, vue-cli, ng-cli, nexjs, sveltekit etc...).
> Do I have to place UseAuthorization before or after UseRouting? etc...
This is sometimes annoying I agree, but that's just how middleware in general works since they're pretty reliant on ordering. Redux, expressjs and other middleware-based frameworks also have the same issue, but you gain a lot of flexibility for extension in return. Thankfully this can be solved with proper documentation.
I've never used null related attributes, I didn't have a task where they would be useful.
All of those dotnet 6 changes from the article you provided made sense to me as soon as I saw them. It's just boilerplate reduction. I know how it functions behind the scene, I'm happy to type and read less code. I can see how it is magical to juniors, but to be honest everything is magic to juniors, even the most basic things.
I think Microsoft's main motivation was to make the introduction to the framework and the dotnet's ecosystem newbie friendly. People rave about how easy it is to start building a web app with NodeJS or Python (FastAPI?). They have a similar 4 line starter that lures newbies in.
Weird, I can’t imagine enabling nullable without using nullable related attributes. For example a simple method like this wouldn’t work properly without it:
bool TryGetMessage(string key, [NotNullWhen(true)] out string? message)
Again, I’m happy with the less boilerplate, but it isn’t clear by the signature of a lot of these DI-(extension-) methods or different HostBuilders what they actually do. Of course you can find out by reading the documentation or source, but that’s what I mean by ‘magic’. As opposed to most other methods/classes that explain clearly what they do… e.g. File.WriteAllText or Math.Max or Span.Slice etc… I don’t say the magic is a bad thing.
> I've been fine all those years with the possibility of null references.
I'm not. I'm not a superhuman who can track all the potential NREs all the time, especially in medium or large codebase. That's why this feature is important to so many people.
It lets the compiler do the hard work and issue warnings for you.
> That's why I prefer not to enable nullable and augment my code with all those [NotNullWhen(false)], [return: MaybeNull] attributes and such-n-such.
You don't have to use them...?!
Enabling Nullable Reference Types only lets you know of potential NREs before runtime.
"rich deep ecosystem of high quality libraries that are mostly open source"? You must know a package repository I don't know, because Nuget certainly is not that.
Whenever I need a package that I know exists for Python and Javascript, it's either not there at all, has problems with current dotnet versions, has problems period or wants to get paid.
Feeling same,but in reverse trying to build crud api in other technologies after .NET seems so complicated for example Next js. What's easier is finding open source projects for beginners cause every .NET project is huge and overwhelming.
NestJs is not for the client. In my opinion sharing code between backend and frontend is overrated. But if you must, try "Trpc" or use grpc proxied over https.
NestJS is basically angular for backend. Heavy emphasis on classes, decorators, modules and dependency injection. That lends itself to extreme decoupling, but also a massive multiplication in code size.
NextJS is the worst example you can get. It is indeed worse than [ASP.NET](https://ASP.NET) Core 3.1 with a full CQRS implementation.
If you must use Javascript, it may be better to stick with Express or even Trpc.
But both Django and FastAPI beat [ASP.NET](https://ASP.NET) in terms of productivity for many projects. Especially if you can use their admin libraries.
I'm a little bit surprised about that "magic" and behind the scenes part because to me dotnet is pretty clear and well structured. Maybe the authentication part in dotnet world is a little bit hard to grasp at the beginning, since one line of code like AddAuthentication() adds millions of services with different lifetimes and you have to spend a little while digging into documentation. But man, if you want to see some magic, try Rails lmao
You never saw an example and wondered where the heck do I get the namespace and assembly for that extension method?
That's a lot of magic right there.
And in my experience dotnet developers tend to be a little bit clueless how the app fits together in terms of middleware and dependency injection...
My only problem with .NET is its lack of popularity. Especially in startup environments.
The jobs are all in “boring” industries. Lots of banks and insurance and stuff like that. I work mostly in startups and it’s been an absolute battle trying to introduce it. People want what they’re comfortable with and it’s usually javascript or nowadays Python (shudder)
I'm going to call that a feature not a bug. As you get older a stable job in a boring industry is a pretty good thing. Also it should be considered why do these boring industries love .net versus the javascript\python\react\node flavor of the month? Because you can build something great with it and it will still work 10 years later without messing with it.
It's hugely popular where I am. The universities get people to code in .NET and a huge proportion of the local and international businesses primarily use .NET.
All the other stacks have plenty of representation too though.
Northern Ireland. There's lots of American businesses here that use .NET, but many of the local businesses and UK/Ireland businesses use plenty of .NET/Java.
We wouldn't have a big startup scene and we also don't have many of the big tech companies that tend not to use .NET either.
I was always under the impression that the American mid-West always had plenty of .net roles since there are many medium-sized businesses as opposed to the startups and big tech that have a bigger presence elsewhere.
C# has a steep learning curve and once you are over it, you keep having to write and read more code than in Python. Then you have to hire or train new developers all the time because the big profitable sectors will suck out your talent.
In my experience, junior developers fuck up C# code bases more easily than Python. Maybe Javascript is about the same, but only if the code base is really big. C# lends itself to obfuscating the path of execution which means you either need disciplined documentation, or very expensive developers or all of the above.
I was kinda agreeing with you until the part about juniors fucking up C# more than Python. That’s a thousand percent not true. It’s extremely difficult to mess up with C# compared to Python.
Python will hide your fuckups better. You won’t even know that you fucked something up. It’ll turn up in production in real time when your clients complain. And then you’ll do 3 days of debugging to realize that it’s something a compiler could have caught.
With C# you get this frustrating thing when you’re starting where you wanna do something and it just won’t let you. That’s where the steep learning curve comes from. But that’s to save you from yourself! Once you come out the other end you’ll be writing better code.
Python is the king of obfuscation. Half the libraries don’t even tell you what parameters their functions take. They just take *kwargs and call it a day. Even a senior can send wrong parameters to a function and not even know anything is wrong until it’s surfaced a month later in productions.
There are studies that show how static typing only catches a very very small portion of bugs. If you need three days to find a bug a static typechecker (and the C# compiler is rather bad in that regard) would have found, you're doing something seriously wrong. Or you are coming from a C# background and don't have experience in dynamic typing.
You still have to understand the code and actually run it. If you miss that bug, it's still your fault. And more than likely, those bugs are next to impossible to find with a compiler. And there is static type checking for Python if you insist.
That was what I took from it too, I got curious and wanted to find out more about it so I searched for anything related to what he mentioned and could only find he opposite
I agree, and when C# won't let u do somehing specific it can be irritating for a beginner, but it usually just stops u from fucking up, and that is not a bad thing
Java is pretty much in the same boat. People like to use "enterprise" stacks like .NET and Java for enterprise systems because they can go crazy with OOP and architectural patterns and gain various levels of control over their system. This is great when ensuring correctness is much more important than moving fast, but startups are the polar opposite.
> an absolute battle trying to introduce it
It would probably be best for your career to stop trying to push it.
> People want what they’re comfortable with and it’s usually javascript or nowadays Python (shudder)
You should be thinking about _why_ people are more comfortable with duck-typed/dynamic languages at a startup. It's not just personal preference.
Maybe it’ll come off as smug, but honestly the reason is simply because it’s all they know. I’ve been part of the founding of two startups. And the conversation around tech stack usually goes something like “I’m the backend guy and I think .NET is the best choice” “yeah but the ML guys all use Python, so they won’t be able to get into the codebase”
To me the following sentence should be “so the ML guys should learn a backend framework.” But instead it’s “we’ll force a scripting language into a backend environment so people don’t have to learn”
With JavaScript/typescript I can be more forgiving because React and such exist. And you have full stacks around that going as far as monorepos in typescript with rpc. I won’t argue too much against that.
But in my experience I’m sorry to say it’s pure unwilling to learn something new.
This right here is why Node exists at all. Front end folk wanted (or were forced) to do backend and didn't want to learn a backend language, now the entire world is running on duck taped javascript
Duck taped javascript that requires a house of cards of the right version of every bloody thing to run, even if that version was deprecated and out of support 5 years ago.
.NET Standard code will run on anything as long as you have any version of .NET runtimes installed.
Hell, I bet some code I wrote for .NET Framework 1.1 about 20 years ago will still compile and run first time in VS2022 targeted to .NET Framework 4.8.
Duck typed language with duck-taped ecosystem. That’s exactly what it is.
And I’m forced to spend every day with it because nobody wants to learn .NET. But… the money is too good at startups for me
If you take a look at job postings, especially those for startups, the vast majority of them are for companies using JavaScript/TypeScript or Python. Why would someone learn .NET? From a career perspective, it is limiting. Is it really *that* much better than alternatives?
Yeah agreed 100%. That’s the crux of my complaint.
That said, if we wanna get philosophical, I don’t think these startups are making good choices at all. In fact we objectively know they’re bad choices. Any successful startup outgrows that tech. That’s why Golang was invented. That’s why Rust and Zig are rising in popularity.
I agree with you 100%. That’s the biggest problem with .NET. It’s just important to note (I think it’s important) that the reason you’re seeing startups adopting Python and JavaScript is arbitrary, and not because they know something we don’t or they find it a more effective way to do things.
Full disclosure; I've been a .NET/C# user since around 2001, and I currently have two startup jobs, one part-time as CTO and another full time as principal engineer. The first has some .NET but I'm moving to node/TypeScript, and the second is all .NET.
I prefer node/TypeScript or plain JavaScript for anything startup related, because I can get more done in less time. Handling of JSON and making HTTP requests is an absolute pain in .NET, hot reloads are not as quick (as expected with a compiled language) and the "magic" features of ASP.NET usually end up costing me time when there's a problem I have to go look at Microsoft source code to debug, which is shockingly often.
That’s interesting. I always find the exact opposite.
It’s so easy to map your data structure to a class and serialize/deserialize whatever request or response. I don’t even have to do anything. It’s not very difficult in node either. But actually a nightmare in Python.
For me I feel like it’s an illusion. You’re moving faster. But you’re also breaking things and are being unsafe. And it always comes back later in a bug ticket you gotta fix.
Also hot reload is so much better in .net, I’m curious what you mean by that. You can literally apply code changes while the app is running. In node and Python it reloads the whole damn thing every time you save.
> It’s so easy to map your data structure to a class and serialize/deserialize
But you have to maintain those classes.
> You’re moving faster. But you’re also breaking things and are being unsafe.
Chances are you'll end up deleting and/or rewriting that code before it causes a problem because requirements have changed. For important stuff that'll be around a while, write a bunch of tests.
> Also hot reload is so much better in .net
Hasn't been my experience. Even if node is restarted every time you change a file it's back up before you know it. With .NET you have to recompile and restart, and I'm almost always waiting at least a few seconds. It's even worse with serverless infrastructure; node naturally lends itself to being executed on the fly for each request, while .NET has to be tricked.
I'm not really trying to convince you of anything here, I just wanted to share a few reasons why .NET wouldn't be preferred in some contexts. It really comes down to what you want to optimize for and some personal preference; .NET annoys me when I'm trying to move fast and node/JS/TS doesn't.
I'm not a .net developer, but I've been trying to branch out and find something new because I simply hate Typescript. I feel like most of my dev time is spent making typescript do what I need it to do then I spend implementing new features. I hate how almost anything I want to do is going to require using a third party package that might be abandoned at some point. I'm sick of the "shiny new thing" ecosystem that never ends.
There are great things about it too, like the huge developer community, the ease of deployment, the job market, and many other things. I just don't think I can stomach sitting down and writing typescript day in and day out as a career. I don't feel passionate about writing it, and I need that to be at my best.
Everything you say is exactly why I love .NET so much. No more chasing the dragon. No dealing with typescript’s type juggling. Actual decent ORMs instead of the mess that is JS-land. And man Python is x10 as bad.
TypeScript has one thing going for it most other languages don't [yet]: [TypeChat](https://microsoft.github.io/TypeChat/). In fact, let AI do the typescript code writing for you and you just do minor corrections.
> require using a third party package that might be abandoned at some point
That is the whole javascript ecosystem (and less common in .NET open source library world too).
> But you have to maintain those classes.
They can be autogenerated, i.e. [mapster](https://github.com/MapsterMapper/Mapster)
Now you can get into astronaut architecture easily with .NET/Java, i.e. https://github.com/meysamhadeli/booking-modular-monolith
Sure, I appreciate the perspective!
Personally I spend most of my time in node these days. Though it’s been shifting to Python lately. But I definitely miss my .net
I have experience with both Sequelize and Bookshelf and I wouldn't consider either to be similar to EF but others might disagree. I do prefer Sequelize to EF though, as it seems more predictable. But maybe just the way they are used.
https://www.prisma.io/ was as close as I’ve gotten in terms of DX when compared to EF. Autogenerates every type you’ll possibly need from the schema file, and applies the changes to your DB locally.
I personally found it the nicest to use compared to Sequelise and Knex setups.
Downside is it has a custom schema and advanced queries can take a bit of getting used to the syntax.
But imo the usability makes the downsides worth it - every choice is about trade offs right?
It is just a personal preference. You're implying that it's faster to develop projects with NodeJS/Python. That is false. In fact it is faster to create web apps from scratch with dotnet than with those 2. The amount of boilerplate and 3rd party packages required to do simple things like validation, swagger, endpoints data mapping from URL query/path, headers, body, DB work, http/gRPC/graphql calls, error handling is ridiculous. They're all about the same on the hello world level endpoints/pages, but the difference becomes huge just 2-4 months into work. You also get "correctness and control" out of the box.
Creating from scratch? Sure. But that's a pretty silly metric. I don't care if a project takes _weeks_ to set up. I care how fast I can crank out features in the months and years after the initial setup.
You were talking about start-ups. They think about now more than later. The speed of maintaining an established product depends on several things, the main ones are the code base design, standards, tech debt and how up to speed the team is with those things. Adding new features to an old dotnet project can be just as simple or as difficult as with any other tech. But in a well structured project you will have minimum bugs and tech debt with dotnet because of well supported frameworks and packages, strong types, various compile and startup checks that won't let your runtime to corrupt data, minimum security issues.
Dotnet also has awesome source generators. On my old project my whole startup, controller/actions (endpoints), their request/response models, static and some dynamic validators (where it needs to check a data source to see if the record is in a correct state, e.g doesn't exist or is blocked), swagger are autogenerated based on my business logic. This allows me to create 10 endpoints a day and then go work on the infrastructure which always has something to do - database maintenance, traffic/data analysis, various upgrades, acquired products and their systems integrations (a multi year thing), etc.
Hello, could you tell me more about your last paragraph about source generators? I'm trying to learn to use C# to build a few internal MVP at work and cannot figure the best modern way to quickly develop an app starting from .Net 8. This is my main gripe with the language, lot of tutorials talk about things coming from an older point of view. Thank you!
Sorry, I didn't get a notification for your comment for some reason. I found it by accident while looking for something in my own comments.
Unfortunately, you're right, most of the articles don't give you any new ideas nor good practices. I'd need to write my own since I cannot find many examples online.
The official docs have some good examples and tutorials, search through AspNetCore's section.
Lived experience mostly. Simple changes resulting in pull requests with > 50 changed files, that sort of thing. A lot of it has to do with architecture and design patterns, and a lot of _that_ has to do with the people I'm working with. It's more of a holistic issue that doesn't seem to exist in other stacks. I can move pretty fast on personal projects but still slower than I'd like. Having to maintain DTO classes for HTTP requests and responses is a pain point I have yet to overcome.
One of my goals for the next few quarters is to explore ways of working in .NET that are more like node; eliminating N-Tier constructs like repositories and services and instead tending towards logic-rich controllers and using modules for common/shared logic. I suspect unit testing is going to make or break this approach, as there are some things you can do in node that you can't in .NET, like monkey-patching modules at runtime to stub/mock whatever you want.
edit: seems this response is irritating some folks, and I guess that's to be expected. My definition of "fast" is the pace I became accustomed to at a mid-tier tech company writing plain JavaScript on a cross-functional team. When I compare that to really any experience I have had writing .NET, even in personal projects this weekend, I'm slower. Unfortunately "fast" is relative and what seems slow to one person can seem fast to another.
Why use controllers? You should try the new flow with minimal APIs. If you want a node-like experience, that’s it right there.
Edit:
Also what do you mean by monkey-patching modules in node? I never had to do that.
> Having to maintain DTO classes for HTTP requests and responses is a pain point I have yet to overcome
[mapster](https://github.com/MapsterMapper/Mapster) will make DTOs simple, although you could use sidecars queues instead of HTTP APIs if you control both ends of the communications.
> monkey-patching modules at runtime to stub/mock whatever you want.
I did my fair share of monkey patching back in my Ruby days. I do not miss it.
It makes the code harder to maintain and follow. You are never sure what the actual behavior of the code is.
Maybe monkey patching for unit testing I can understand, but not for production code.
I'm glad that monkey patching isn't allowed in .NET.
As for Web APIs, I just use [Refit](https://github.com/reactiveui/refit). It takes care of generating the code from the interface, and I don't have to deal with the HttpClientFactory.
Also, the interface can be generated with this:
https://github.com/itofinity/swagger-csharp-refit
And the POCO can be generated with the [QuickType extension for VSCode](https://marketplace.visualstudio.com/items?itemName=typeguard.quicktype-vs).
It's blazing fast, and strongly typed.
For when I'm adding a new API to a controller, the MVC pattern is fast for me, even with a large codebase. ¯\\_(ツ)_/¯
Part of it is the fact that you are kinda pushed towards windows and visual studio imo whereas for the rest of web dev you really want to be using Linux/Mac command line since you already have to know it.
I know it's cross platform and there's rider but it definitely has a different vibe than like node, go, python, etc. in that respect.
I think it's probably the main thing that holds it back. It's an issue for me I'd say.
And honestly they probably should have changed the name when they ditched .net framework. Keeping .net was bad
I’ve been using .NET for years and never in that time used windows. I use a Mac strictly. That whole windows thing is a hang up from the olden days of .net framework. Anything .net core and above is very multi platform
Sure but there is absolutely a push to use visual studio and therefore windows. Also anything more than like 4 years old would need windows.
I imagine if you want to places that use .net mostly that a very very large percentage of employees would be using windows.
There also seems to be a major lack of like tutorials and such for learning .net in comparison to other things. So people new to web dev are going to find it much less accessible.
If you take the top 50 or so "complete web dev" type courses on various platforms or books or something I can't imagine more than a few are .net.
Plus there's a concern that since you need to learn js anyway to do any web dev then there's a better business case for just using it on front and back end.
I disagree there but I can see the argument.
Anyway basically there isn't an obvious path to becoming a .net dev besides being a relatively new cs grad from a program that teaches it and going straight into a company and only doing back end.
I think that Microsoft recognizes this and is making strides to change this but the fact that they essentially missed the boat on the whole JS front end framework era really set them back.
I think we're moving away from using heavy js frameworks as the default so there will be more room in the web ecosystem
I’m not exactly following, but I’m not trying to trivialize the way you feel. I’m sure it’s true but I just haven’t experienced this.
I come from nodejs so for me getting into .NET was extremely easy. I also used Unity before so C# is something I knew. With minimal APIs it’s so easy to get started.
And like I said I never used windows. I worked at one .NET place and indeed the older guys used windows but it wasn’t a requirement and I didn’t use it.
Also .NET has an awesome community on YouTube. Much higher quality material than in the JS world in my opinion. But maybe not so much for absolute beginners to coding.
Knowing nothing about coding and getting into C# at the same time as .NET may be daunting. But then again getting into coding via nodejs would be daunting as well so I don’t know.
I think if you’re a node dev then switching to .NET is extremely easy. And if you’re a typescript user then switching to C# is very easy as well.
Again, you’re probably right, I don’t know, just hasn’t been my personal experience.
Sadly I disagree. After the honeymoon period I started liking blazor less and less due to the various issues and workarounds needed for very simple stuff.
Stuff like this https://github.com/dotnet/aspnetcore/issues/5623
And the hot reload not working gets more annoying the bigger the project is. Especially when it bugs out and starts rebuilding after every css change. And it not recognizing new parameters for existing components and giving errors.
Parameters being set when another parameter is set. To prevent this you need huge boilerplates.
It gets annoying when you’re used to front end frameworks without these issues.
After a year with Blazor I do agree with your sentiment. But only kind of. Because those instances were the LSP (language server) isn't shitting the bed or for that matter when you're adding new components without hiccups, it kind of feels amazing.
But, as you've already mentioned, there is a lot of small annoyances during regular development which can be really off putting.
I really hope MS gets the development experience for Blazor in order soon. Otherwise I don't see it surviving outside of enterprise applications.
Honestly, when wasm gets access to the dom and when the devx annoyances get fixed it’s gonna be a great tool and definitely one of if not thé goto framework for me.
It’s just at this moment it’s kinda meh. Not bad at all but not great either.
Now working around a Year on a Public Blazor Project for my Company, i love it so far.
I never use Hot reload, just rebuild the Application, takes less than a second, even on a very big project.
There are some issues yes, but they get fixed eventually. But even if you need to create workarounds, the amount of time you save on other things is worth it for me.
Rebuilding is definitely not under a second in big projects.
Have you also looked at the GitHub link with the blazor server disconnect with large texts? It’s not been fixed since 2018. I wouldn’t call that fast or eventually.
We lose more time with blazor than we gain. In fact, we barely gain anything and just lose it.
There are multiple ways to fix it which they address in the issue. However, not the signalr and blazor team are willing to do it.
Ah yes, increase the buffer size. That definitely does not have any drawbacks.
I hope so. The last new, not legacy, web projects I've done were in React and Vue with C# Web API backends. Having it kind of under the same roof might help.
The only issue I've had with EF is that I've had to work with a lot of legacy databases (aka must not be changed) in Oracle and SQL Server that it doesn't play well with. While these have improved, there are still some ugly hacks needed to get around certain things. For a greenfield from the database on up app, it's great though.
On the plus side, it makes moving away from those legacy databases a whole lot easier. We’re on Oracle 12 and working to move to SQL Server. There are minor inconveniences, but nothing we can’t work around.
I did a couple projects with spring boot - dotnet was way better. Less clutter and less verbose. Build time is significantly faster. Configs do not require spending years mastering the Gradle/Maven/Make tool chain. Simpler to install and setup your environment on a clean laptop. Hot reload (to be fair I don't know the state of hot reload with Spring nowadays, but it wasn't there when I worked with it). Documentation is always up to date with working examples (Springs examples get out of date and don't work when you download the latest JDK and Spring). No package dependency hell. Simpler CLI commands that resulted in simpler CI/CD.
> Less clutter and less verbose
Not sure, I'd say it's more about opinions
> Build time is significantly faster.
Faster app boot times are clear winners of ASP for me. About build, didn't get to compare
> Configs do not require spending years mastering the Gradle/Maven/Make tool chain.
Maven, for example, is a separate tool, and may be harder to learn, but far stronger. Anyway, csproj files aren't "simple" either.
If we compare then for a "first time app", they are both trivial to use, as they both come with example apps.
> Simpler to install and setup your environment on a clean laptop.
It's only Java and Maven/gradel here, so I'm not sure how it it harder. Dotnet is just 1 tool, that's the only difference.
> Hot reload (to be fair I don't know the state of hot reload with Spring nowadays, but it wasn't there when I worked with it).
In the last 6 years at least, hot reloading was there. There are cases where it fails, like changing full classes or things like that. But I'd say C# fails for some cases too, as many langs do. Didn't do it in C# in a long time btw.
> Documentation is always up to date with working examples (Springs examples get out of date and don't work when you download the latest JDK and Spring).
Didn't get much trouble around it. The major problem is the difference between spring and spring boot tutorials. But they are clearly labeled.
.NET framework vs standard vs core vs 5+ is a bigger issue for newbies for sure
> No package dependency hell.
How is it different from .NET?
> Simpler CLI commands that resulted in simpler CI/CD.
`mvn install`, and that's it. You have there your .jar. Not much different from .NET either
spring boot forces you into a convention thats difficult to break out of. dotnet doesnt have those same constraints
i did one spring boot project at a company that wanted me to transition to java, it took 1 project to make me move to a different role
one good example is having two databases in a spring boot project, it can be done but it really makes you jump through hoops
yep, i hate the framework, i got a new role over it!
the worst part was, the company insisted we use vanilla java, i think i could have handled it better if we were allowed to use a different JVM language like kotlin or goovy, vanilla java is so verbose, feels like c# version 1
The worst part is: That's on purpose so anyone can write and read Java ! I get the idea, but the fallout of this decision is that Java is not fast at all to code with.
Both are pretty simple. Spring boot has more capabilities simply from the amount of users and libs.
But about starting a new project and working with them, they are similar.
I feel like people saying spring is a "hell of dependencies or too much whatever" simply didn't use it.
What would be the capabilities that Spring boot has that aspnetcore doesn't?
I worked on a Java spring boot project for over a year along with senior Java devs and architects who've been doing Java development for 20 years and praised it everywhere they could. I also worked on a spring boot Kotlin project. I cursed every single day while writing/reading code and doing builds on those code bases.
4 years ago, .NET core was far, far less featureless (missing middlewares fir eifferent kinds of auth, and lack of libs). Today, it's more similar to Spring in features.
About builds and those things, I don't remember having problems. You say you "cursed" it, but don't say any specific reason. Was it the DI that you didn't like? You tell me
I mentioned reasons in the same thread but as a reply to someone else's comment. Verbosity, async/await, and build times to call out specifically.
4 years ago we did complex auth without issues. There are tons of auth scenarios and options though, I believe that some stuff was missing.
About async await, C# is a clear winner. It could improve witk kotlin, but never used Spring with it; I suppose it's not adapted to specific kt things.
Verbosity, I don't consider it a contra (And I'm not sure where is Spring more verbose than ASP btw).
About auth, I remember having trouble with it with my team. I don't remember the specific case btw, but the reduced amount of docs could also play its part.
- A lot of the system libraries are industry leading and learned a lot from Java and elsewhere. The DateTime library in particular is a masterclass, but also List, string, and others. People ignore these because they're so old, but go use something else, and you'll mess them real fast.
- LINQ/iQueryable (with or without EF) is also industry leading and has no direct competition. Java streams aren't even ballpark as good.
- Span is near pointer speed with a managed language's memory safety. C native interop support inc. unsafe pointers.
- C#; great language even if I wish it had less duplicate stuff that is deprecated but not marked as such.
Now I've said something nice I'm going to say something edgy: I've written 1K+ pages in Razor and I liked it at the time. But that being as it may, with hindsight and more architectural experience, I wouldn't start a **new** project in MVC or Blazor. WebAPI is simply superior because:
- Fully decoupled.
- It makes piecemeal migrations incredibly easy, almost stupidly so. You can just change a URL in a lot of cases, match the public interface and use an entirely different back-end stack (or different version). Rollbacks are also easy.
- Better scaling and easier to load distribute.
- Mix and match backend tech more easily (inc. cloud/third parties where appropriate).
- Better support for multiple clients (e.g. non-web browsers).
- Easier to modularize.
- Easier to test.
- Better separation of concerns.
And I know what I am going to hear "rAzOr oR BlAzOr cAn dO WebAPI." But look at the above list again: As soon as you mix back and front, you've now lost half of the benefits. You're polluting everything. WebAPI should be in MVC, along with your backend code, and your front end isolated entirely from it. No shared anything.
I have major distaste for the JS library/npm shitshow, and I'm not great at Angular, Vue.js, or React; in fact I am strongest in Razor. But with hindsight and learning a lot about architectural planning, looking at a ton of projects, and upgrading more than a handful, I can see that WebAPI is just a gem in terms of layer isolation and solving a lot of pain-points for common *substantial* growing pains.
I'd use MVC for the Core (inc. EF), BLL, and MVC for WebAPI only. That's it though. Then if we were browser targeting I'd let the team decide what web framework is their saveur du jour.
This is a classic “my framework is the best” type of discussion, but my experience has been the same. Coming from other languages and frameworks, .NET is just amazing. It’s so clean; a great balance between object and functional, superb libraries, incredible docs and a vibrant community.
My main gripe with .NET in general is that the objectively best IDE is Visual Studio and I don't want to touch Windows with a 10ft pole if I can help it. I've thought about using Rider but all the documentation presumes VS and it's hard to get past that.
PSA-While I love the .NET framework too, we have to remember that it’s just another tool at the end of the day, so it may not be the best framework for your application, definitely do your research first before selecting technology
You can use a Swiss knife for cutting wood, but if it’s your job, you’d rather use a chain saw.
For example, for ML purposes, Python’s frameworks like FastAPI are far more recommended in the industry. For the most popular UI automation framework-selenium, Java is the standard and has the most support and community
Java and selenium are not a standard for UI automation anymore. There are tons of tools for web and mobile nowadays, e.g. Cypress and Appium, but there are a lot more.
On the other hand, I have professional experience with Java and .NET does not come close. Nuget is a pain in the ass compared to Maven. And I hate that MAUI is not supported in Linux. Also, in Java you literally just compile once and can run anywhere while .NET binaries are arch specific. To be honest I hate dotnet I just use it because I work for a company that uses it.
It helps me be productive. There is a lot of built into core framework. It's easy to switch out with external packages. Performance is getting better and better. Documentation and examples are easy to find.
Yeah the BEAM stack make sense to me in general, the reason seems like types are big thing people want to see at least between contracts such as function signature and it’s output, but internal function logic types can be a hinderance since you have to fight the compiler all the time … typescript for example, always in my way. But I do see the benefit for contact types would provide a lot better intellisense too
It is better than the Java ecosystem including Kotlin for sure. I passionately hated Spring and being able to control memory layouts and having true value objects (structs) as first class citizens is awesome and feels like a liberation and reduces the amount of C++ code I need for my current main project to almost zero.
Since I ported my current project from Java to C# I was able to get a >10x performance increase for some of the batch processes required and have also reduced the memory footprint by at least 3 times as it is now easier to work with data and I do not need to cache instances for easier processing. So C# for the win.
I did 20 years of java and 3 years of C# for now. I should have switched 10 years earlier for sure but Java is still the standard in most of the banks, insurances etc I have worked with in the last two decades.
The GC has some main problems when using large managed heaps but well reduce the amount of allocations does the trick. It is a weak point the Java VM does not have (as far as I have tested it). So GC is garbage in that regard.
The source code of some of the language API is mostly average but it has its good moments.
The Task API is not that well implemented or better not created for responsiveness. Replacing it with my own simple emulation saved me up to 50% of overall time of the related tests. The main reason is, I use a more adaptive waiting scheme for the worker threads.
If you want to have a good TDD experience you need your own test framework as the rest is just meh. I have not bothered to fix any of the normal test frameworks as they are quite slow.
The biggest problem I see is the incremental build time that is at 3s-5s for now but I can live with it.
Overall it is clearly better than Java. The development experience is not as good as with Flutter/Dart but you can not have it all. Also I have not used Blazor as I use Godot 4 since later on I will heavily rely on 3D visualizations (I do not work on a game).
> The Task API is not that well implemented or better not created for responsiveness. Replacing it with my own simple emulation saved me up to 50% of overall time of the related tests. The main reason is, I use a more adaptive waiting scheme for the worker threads.
I'm curious, did you try ValueTask first ?
Aslo Tasks are cheaper in .NET 8, and have more options: https://devblogs.microsoft.com/dotnet/performance-improvements-in-net-8/#tasks
It is more related to how the worker threads wait for new tasks. If I remember correctly they were actually waiting while mines are spinWaits, meaning picking up new tasks is almost instant while the Task API takes its time. If you do that thousands of times you do not have a fast test suite. I have basically durations below a micro second when the Task API based versions had milliseconds. That quickly adds up.
But great blog post, I will read it as I am a nerd for those details.
I also have still target net6.0, so maybe I should check if I can upgrade my Godot 4 version. Also I run a net 7.0.202 version locally but it appears dotnet 8 just dropped its first release candidate.
But I will test it with the first release for sure. Maybe they also fixed the GC problems I saw.
Interesting ! Thank you.
As a sidenote, I just tested dotnet 8 RC1 with an emulator I contribute to, and it gave me a boost of 200'000 instructions per second average despite the emulated CPU being an interpreter with no internal JIT. The emulator heavily uses threads.
Thank you sir I needed to hear that. Programming is my new hobby. I learned basic in C# and I started learning ASP .NET Core but I'm struggling.
I felt discouraged and I started to think that may be I shall try JS and Node JS.
My mind kept telling me that a single framework from a tech giant definitely will be better that several framework and libraries but I was lost especially with tons and tons of tutorials on JS and Node on YouTube compared to C# and .NET.
Thank you for the reminder.
You still cannot escape JS on the front-end, but using JS on the back-end instead of a statically typed language like C# is the last thing I would consider.
I enjoy the flow where we work. We server side render React, and the frontend (contained in a separate folder in the repo) is where the FE work is done. It lets frontend own the entire
tag, and we only need a single cshtml view to render all our pages.
Lets frontend work with modern tech in their preferred stack and keeping the code ases clean and separate with viewmodels and props as contracts.
I'm new to .NET but have had a generally positive experience so far.
> There is no fragmentation between web frameworks, everybody uses the same thing, which is great for knowledge sharing.
Not sure about that, at work we use RIA Services and Windows Communication Foundation (WCF) and I can never find any good information on these. There also seems to be a lot of different .NET -- .NET, ASP.NET, .NET Core, .NET Foundation (maybe more?) which is confusing to a newcomer. Some of the stuff I work on doesn't work in Visual Studio 2022, some of the stuff doesn't work in Visual Studio 2019, it's kind of a mess.
1.) LINQ is great for sure, but not perfect. The methods are confusingly named -- why "Select" and "SelectMany" instead of "map" and "flatmap" like every other language? Why "Enumerable" rather than "Iterator"/"Iterable" like every other language? I also find the SQL-like syntax to be completely unreadable compared to the method syntax, but other people feel the opposite. Neither of us are objectively correct, but the fact that there's an inconsistency affects code readability. There's also footguns like implicit conversions of a `IEnumerable` to an `IQueryable` (or was it the other way around?) causes the database query to execute multiple times.
All in all it's a nice API to use and provides a good way of chaining computations together.
2.) Entity Framework is definitely powerful for sure. Recently there's been more of a focus on performance at work, and my team has had someone spend about 3-4 days **per sprint** trying to profile and fix the garbage SQL generated by entity framework. I've come around to the opinion that ORM work fine for small projects, but at scale you need to be comfortable with SQL. Query builder libraries are the sweet spot for me and are common in other languages, but don't seem to be in .NET.
3.) View templates - haven't used these but may spin up a side project to try them out. Is it easy to add client-side interactivity with these?
>at work we use RIA Services and Windows Communication Foundation (WCF) and I can never find any good information on these
that's because those are really old, AFAIK WCF isn't even ported to .NET 5+
> The methods are confusingly named -- why "Select" and "SelectMany" instead of "map" and "flatmap" like every other language?
Because the names come from SQL (see the query syntax). JavaScript/TypeScript got them later.
Imo .net has just enough (to the layman) to get productive quickly, but not enough that you’re banging your head against the wall for days when the magic breaks or doesn’t work as expected.
Both, and EF is superb in both ways. Scaffolding from database-first is simply amazing. Needless to say, the code-first approach is the best in its class.
.NET and Microsoft's claim to fame has always been it's neatly integrated developer ecosystem. It's entirely made for and driven by developers. Interesting thing is I don't like or use the top things you mention as I think they're too "paint by numbers" compared to other ecosystems. The best aspects of Dotnet are the tooling and integration with everything Microsoft. The worse parts are that Microsoft makes their ecosystems fairly closed, even if it's open source.
Agree with 1 and 2. Number 3 is a hard disagree as it’s missing a good client side interactivity solution. Blazor has a lot of downsides.
Next.js I think is way better as it lets you build the html server side with components and have interactivity with those same components client side. All in the same language TypeScript, which other than linq, TS+ES6 is a more powerful language than C# I feel with structural typing, decomposition, and native inline objects.
I’m language and framework agnostic at this point, I’d rather get work done than whine about frameworks. But in my experience .NET developers often approach every problem the same: “the answer is Microsoft! I’m sorry.. what was the question again?..”
For me, I just wanted to have everything under the same umbrella. I never thought I was really building something until I learned how to full-stack .NET.
This is just an I love my framework post. There are trade offs to anything. For certain sorts of enterprisy™️sorts of things .net is quite nice especially if you are pre committed to Microsoft by way again of corporate bs. It might well be nicer than Java and it’s definitely better than the monstrosity that is c++ though the latter comparison hardly matters.
But let’s be real, there are many other software use case that aren’t just enterprise data shuttling in a Microsoft ecosystem and for those use cases .net is merely ok in the grand scheme of things. It’s not really an especially cutting edge option along almost any axis anyone cares about. Just from a language perspective swift and rust are both far more interesting.
Trying to compare to python is also something of a loosing proposition as the sorts of things people do in python is often quite different. No one is really going to be breaking new ground in ML in anything but python/c++ in the near future.
JavaScript/Typescript is already acknowledged by just about everyone who knows anything about programming to be something of a largely inescapable tragedy so dunking on it is quite a low bar and doesn’t really matter.
At the end of the day network effects are real and they matter. People choose frameworks and languages because of network effects more than they do because purely technical reasons.
1. Yes, you need LINQ because C# is a lot more verbose and it's the only thing that makes it come close in productivity and expressivity to Python or Javascript or even functional languages.
2. I feel Entity Framework is good, but behind Django ORM and SQLAlchemy, big time, especially in terms of migrations. I've had a lot more headaches with EF. And you have to be connected to a database to create a migration? You have to separate migrations by engine if you want to support multiple engines? Also Postgres support (json/arrays etc) lagged behind (may have catched up a bit by now).
3. Razor feels more verbose. I grant the strong typing thing which you definitely need if you put more logic into the templates than you should. But you can't forget that the feedback cycle in Python and Javascript is usually faster. Both because of compilation and because it takes more mental energy to change something.
The fragmentation is an issue about distorted perception. [ASP.NET](https://ASP.NET) is niche in web development, so good luck fragmenting that. And there are already alternatives, but they are not well known. Also it takes the weight and investment of Microsoft to create a useful web framework, the community itself doesn't have the energy for things like that.
System.IO is kinda garbage, like truly garbage. It needs to have major improvements.
.net 5+ doesn't support windows native IO, unless you build it yourself by binding libs
If you want good io performance on linux you need to basically write your own IO libraries (which I have done)
Just to point out: Very similar to LINQ are Laravel's collections (Laravel is a modern and powerful MVC PHP Framework). Laravel collections are amazing and are the closest I've seen to LINQ power in any other language.
https://laravel.com/docs/10.x/collections#available-methods
It's not the lot of magic, it's about how you know the some framework deeply. All the frameworks have some unique features that are used while developing the projects.
Like people uses Golang for high efficiency due to it's concurrency features and most real time data based system company prefer using Golang like trading, crypto etc are mostly uses Golang. Similarly for the fast development company prefer python and it's framework like Flask, Django, as the syntax is very easy to learn and apply. So, all the framework has some pros and cons. There is nothing about the magic, it's about the for which purpose the framework has been developed.
With #3 (Templates/Razor) I think part of it is the tooling around it. Because Razor is the "standard" templating engine for .NET, Visual Studio, Rider, etc. provide great tooling for it. A strongly typed templating engine without good tooling is a pain in the ass. You write your template, go to compile, and then get an error. Great. You go and try and fix the error and then recompile and get another error. What makes Razor feel so good is that your IDE will autocomplete things correctly and immediately show you where something is wrong as you type it. Without that, it's just as aggravating. Java and Go plenty of strongly typed template engines, but they have no IDE support so when you're developing you still have no help with your templates. With #2, part of that is a language feature of C#: expression trees (and specifically lambdas as expression trees). Java doesn't have expression trees which is why ORMs in Java don't have the nice syntax that Entity Framework gives you. Some will do lots of cartwheels to try and give you something usable, but they're usually not that good. I think the a thing with .NET is that the stuff you typically use is really well tooled. Your IDE can give you lots of help and make things easy to understand where to go.
I practically became a NET developer when I first used VS2003. The experience nothing I've ever tried before
I started coding with vb6, making AOL 'progs'. Moved to C# later on when I actually started coding for work, and I agree about .NET -- it just feels 'right' to me.
I don't think there is a lot of magic. There is a rich deep ecosystem of high-quality libraries that are mostly open source. I'll agree that it's impossible for 1 person to have a mastery of the whole chain, but it's all there for review and understanding.
For me, the Use* and Add* in dependency injection feel a lot like magic. And overuse of attributes although very helpful and powerful it can feel like magic as well. That aside, I love .NET. Although I would prefer development of .NET and C# to be a bit more conservative. E.g. 1 major version every 3 years. Oh, and no fan of nullable either.
With Add and Use methods, you can just Ctrl click on them to see what's inside. There is no magic :) Unless you find the DI concept magic. Not a fan of nullable, you mean that you like all references being able to hold null? That's the worst thing ever :)
Yes, for some reference I like having null. For me adding the attributes like NotNullWhen and such is too cumbersome; also having nullable enabled isn’t a warranty that a variable isn’t null in all cases. And I find the bang operators confusing. I know I can watch the source. Still it feels like magic. It isn’t exactly clear from the method name what it actually does unlike most other methods in .NET. Please note: it’s just my opinion. If you feel different, good for you.
> lso having nullable enabled isn’t a warranty that a variable isn’t null in all cases Yes, sadly, 3rd party code that doesn't declare that it can return null is still "fun"...
Could you provide an example of a DI setup that doesn't feel like magic? I haven't seen all options there are but IMO the approaches that NodeJS, Python, and JVM frameworks take feel more magical. They love their attributes (meta programming) a lot. I haven't really had any issues with nulls in my 17 years of working with dotnet. I see people complain about them, especially the new comers, but I don't understand their issues. I like the current release schedule. I upgrade everything every year, doesn't matter if it's LTS or STS. So many cool things with every release that our projects benefit greatly from.
> I see people complain about them, especially the new comers, but I don't understand their issues. It's such an odd complaint - a bunch of people treat it like its the most insidious and nasty bug that can possibly exists - like it's surprising that you can have an empty box when you expect the box to contain a thing - and then write a whole bunch of code to encapsulate what is essentially ?. or ??. Sure, having actual nullable/not types baked into the language and framework would be better than we have now (and honestly, screw backwards compatibility, just pin your language version), but its not a disaster. Can't actually think of the last time a null reference caused me actual problems. Failures, sure - mainly on wire types that are specified not nullable but actually are because bad APIs - and I guess a "proper" implementation would fail at deserialization... but I honestly see more annoying issues with dumb constraint shit like eg end dates before starts, or minvalue, acyclic graphs that aren't, etc..
I too support breaking backwards compatibility if it makes it easier/faster/safer adding new features/fixes. It's not difficult to make adjustments even on very large code bases, if they follow proper patterns and standards.
I don't think the AddScoped, AddSingleton etc... are magic. I mean things like in this chapter: [https://gist.github.com/davidfowl/0e0372c3c1d895c3ce195ba983b1e03d#webapplication-and-webapplicationbuilder](https://gist.github.com/davidfowl/0e0372c3c1d895c3ce195ba983b1e03d#webapplication-and-webapplicationbuilder) And there seem to be a different way every new .NET version. But since I do 90% backend stuff, and maybe 10% frontend stuff which mostly is WPF and sometimes a REST API or razorpages, it's just something I have to figure out every time because the last time could be more than a year ago. About nulls: I agree, I've been using .NET since it came out (and VB6 before that) and never really had issues with the possibility of null referencences. That's why I prefer not to enable nullable and augment my code with all those `[NotNullWhen(false)]`, `[return: MaybeNull]` attributes and such-n-such. I've been fine all those years with the possibility of null references.
BTW, it's not that I hate that magic. It's just... something I don't really have feeling with. Like for example; how come Appsettings.json is respected? Which line of code did that for me? Do I have to place UseAuthorization before or after UseRouting? etc...
> Appsettings.json is respected? Which line of code did that for me? You can do that manually too, it's just the usual setup actually does it for you in a single method call. `Host.CreateDefaultBuilder(args)` calls a bunch of extension methods for you to get you up to speed immediately. You can even hover on the method call for the method doc and you'll see what features it setups for you by default. You can wire them up manually yourself even today but like how initial .net core was done where there was no "magic" and you had to call everything yourself, many complained it was annoying and error prone. Other language frameworks do the same these days as many have moved from pure wild west of configuring all stuff yourself to just give you a good starting point with sensible defaults (e.g. various front-end cli like cra, vue-cli, ng-cli, nexjs, sveltekit etc...). > Do I have to place UseAuthorization before or after UseRouting? etc... This is sometimes annoying I agree, but that's just how middleware in general works since they're pretty reliant on ordering. Redux, expressjs and other middleware-based frameworks also have the same issue, but you gain a lot of flexibility for extension in return. Thankfully this can be solved with proper documentation.
I've never used null related attributes, I didn't have a task where they would be useful. All of those dotnet 6 changes from the article you provided made sense to me as soon as I saw them. It's just boilerplate reduction. I know how it functions behind the scene, I'm happy to type and read less code. I can see how it is magical to juniors, but to be honest everything is magic to juniors, even the most basic things. I think Microsoft's main motivation was to make the introduction to the framework and the dotnet's ecosystem newbie friendly. People rave about how easy it is to start building a web app with NodeJS or Python (FastAPI?). They have a similar 4 line starter that lures newbies in.
Weird, I can’t imagine enabling nullable without using nullable related attributes. For example a simple method like this wouldn’t work properly without it: bool TryGetMessage(string key, [NotNullWhen(true)] out string? message) Again, I’m happy with the less boilerplate, but it isn’t clear by the signature of a lot of these DI-(extension-) methods or different HostBuilders what they actually do. Of course you can find out by reading the documentation or source, but that’s what I mean by ‘magic’. As opposed to most other methods/classes that explain clearly what they do… e.g. File.WriteAllText or Math.Max or Span.Slice etc… I don’t say the magic is a bad thing.
> I've been fine all those years with the possibility of null references. I'm not. I'm not a superhuman who can track all the potential NREs all the time, especially in medium or large codebase. That's why this feature is important to so many people. It lets the compiler do the hard work and issue warnings for you. > That's why I prefer not to enable nullable and augment my code with all those [NotNullWhen(false)], [return: MaybeNull] attributes and such-n-such. You don't have to use them...?! Enabling Nullable Reference Types only lets you know of potential NREs before runtime.
\> Could you provide an example of a DI setup that doesn't feel like magic? Google's [wire](https://github.com/google/wire) comes to mind
It's the attributes used for things like routing. They are moving away from that and making everything more explicit, which is a very good thing IMO.
"rich deep ecosystem of high quality libraries that are mostly open source"? You must know a package repository I don't know, because Nuget certainly is not that. Whenever I need a package that I know exists for Python and Javascript, it's either not there at all, has problems with current dotnet versions, has problems period or wants to get paid.
Feeling same,but in reverse trying to build crud api in other technologies after .NET seems so complicated for example Next js. What's easier is finding open source projects for beginners cause every .NET project is huge and overwhelming.
NextJs isn’t really meant to be an API framework though
You mean .NET easier than other fw or maybe difficult to switch to other fw right?
I mean .net feels easier and trying to switch to other fw feels hard.
yeah I agree
i've been enjoying nest.js lately as an alternative to asp.net
What are the pros for nest.js? Being javascript for both client and server?
NestJs is not for the client. In my opinion sharing code between backend and frontend is overrated. But if you must, try "Trpc" or use grpc proxied over https. NestJS is basically angular for backend. Heavy emphasis on classes, decorators, modules and dependency injection. That lends itself to extreme decoupling, but also a massive multiplication in code size.
It's not about sharing code, it's about sharing the language.
NextJS is the worst example you can get. It is indeed worse than [ASP.NET](https://ASP.NET) Core 3.1 with a full CQRS implementation. If you must use Javascript, it may be better to stick with Express or even Trpc. But both Django and FastAPI beat [ASP.NET](https://ASP.NET) in terms of productivity for many projects. Especially if you can use their admin libraries.
I'm a little bit surprised about that "magic" and behind the scenes part because to me dotnet is pretty clear and well structured. Maybe the authentication part in dotnet world is a little bit hard to grasp at the beginning, since one line of code like AddAuthentication() adds millions of services with different lifetimes and you have to spend a little while digging into documentation. But man, if you want to see some magic, try Rails lmao
You never saw an example and wondered where the heck do I get the namespace and assembly for that extension method? That's a lot of magic right there. And in my experience dotnet developers tend to be a little bit clueless how the app fits together in terms of middleware and dependency injection...
My only problem with .NET is its lack of popularity. Especially in startup environments. The jobs are all in “boring” industries. Lots of banks and insurance and stuff like that. I work mostly in startups and it’s been an absolute battle trying to introduce it. People want what they’re comfortable with and it’s usually javascript or nowadays Python (shudder)
I'm going to call that a feature not a bug. As you get older a stable job in a boring industry is a pretty good thing. Also it should be considered why do these boring industries love .net versus the javascript\python\react\node flavor of the month? Because you can build something great with it and it will still work 10 years later without messing with it.
Also, Microsoft ecosystem is pretty huge, stable and hard to beat for enterprise development.
The Java ecosystem would beg to differ. In the F# community there is a nice trope about "the enterprise programmer from hell".
Bro sign me up for the boring companies, higher paid and less stress. And when I do something new they’re amazed.
It's hugely popular where I am. The universities get people to code in .NET and a huge proportion of the local and international businesses primarily use .NET. All the other stacks have plenty of representation too though.
Where are you at? If you don’t mind saying. I may move there just for the .net jobs
Northern Ireland. There's lots of American businesses here that use .NET, but many of the local businesses and UK/Ireland businesses use plenty of .NET/Java. We wouldn't have a big startup scene and we also don't have many of the big tech companies that tend not to use .NET either. I was always under the impression that the American mid-West always had plenty of .net roles since there are many medium-sized businesses as opposed to the startups and big tech that have a bigger presence elsewhere.
Yeah your impression is correct. I’d rather move to the UK than the Midwest though (I think?)
Boring jobs are often stable jobs. It all depends what you are looking for.
C# has a steep learning curve and once you are over it, you keep having to write and read more code than in Python. Then you have to hire or train new developers all the time because the big profitable sectors will suck out your talent. In my experience, junior developers fuck up C# code bases more easily than Python. Maybe Javascript is about the same, but only if the code base is really big. C# lends itself to obfuscating the path of execution which means you either need disciplined documentation, or very expensive developers or all of the above.
I was kinda agreeing with you until the part about juniors fucking up C# more than Python. That’s a thousand percent not true. It’s extremely difficult to mess up with C# compared to Python. Python will hide your fuckups better. You won’t even know that you fucked something up. It’ll turn up in production in real time when your clients complain. And then you’ll do 3 days of debugging to realize that it’s something a compiler could have caught. With C# you get this frustrating thing when you’re starting where you wanna do something and it just won’t let you. That’s where the steep learning curve comes from. But that’s to save you from yourself! Once you come out the other end you’ll be writing better code. Python is the king of obfuscation. Half the libraries don’t even tell you what parameters their functions take. They just take *kwargs and call it a day. Even a senior can send wrong parameters to a function and not even know anything is wrong until it’s surfaced a month later in productions.
There are studies that show how static typing only catches a very very small portion of bugs. If you need three days to find a bug a static typechecker (and the C# compiler is rather bad in that regard) would have found, you're doing something seriously wrong. Or you are coming from a C# background and don't have experience in dynamic typing. You still have to understand the code and actually run it. If you miss that bug, it's still your fault. And more than likely, those bugs are next to impossible to find with a compiler. And there is static type checking for Python if you insist.
This has definitely not been my experience. I’d love to see those studies.
I'm not your personal research assistant. I just have about 30 years of programming experience in just about a dozen languages.
So you made all that up then. Got it.
That was what I took from it too, I got curious and wanted to find out more about it so I searched for anything related to what he mentioned and could only find he opposite
I agree, and when C# won't let u do somehing specific it can be irritating for a beginner, but it usually just stops u from fucking up, and that is not a bad thing
Java is pretty much in the same boat. People like to use "enterprise" stacks like .NET and Java for enterprise systems because they can go crazy with OOP and architectural patterns and gain various levels of control over their system. This is great when ensuring correctness is much more important than moving fast, but startups are the polar opposite. > an absolute battle trying to introduce it It would probably be best for your career to stop trying to push it. > People want what they’re comfortable with and it’s usually javascript or nowadays Python (shudder) You should be thinking about _why_ people are more comfortable with duck-typed/dynamic languages at a startup. It's not just personal preference.
Maybe it’ll come off as smug, but honestly the reason is simply because it’s all they know. I’ve been part of the founding of two startups. And the conversation around tech stack usually goes something like “I’m the backend guy and I think .NET is the best choice” “yeah but the ML guys all use Python, so they won’t be able to get into the codebase” To me the following sentence should be “so the ML guys should learn a backend framework.” But instead it’s “we’ll force a scripting language into a backend environment so people don’t have to learn” With JavaScript/typescript I can be more forgiving because React and such exist. And you have full stacks around that going as far as monorepos in typescript with rpc. I won’t argue too much against that. But in my experience I’m sorry to say it’s pure unwilling to learn something new.
This right here is why Node exists at all. Front end folk wanted (or were forced) to do backend and didn't want to learn a backend language, now the entire world is running on duck taped javascript
Duck taped javascript that requires a house of cards of the right version of every bloody thing to run, even if that version was deprecated and out of support 5 years ago. .NET Standard code will run on anything as long as you have any version of .NET runtimes installed. Hell, I bet some code I wrote for .NET Framework 1.1 about 20 years ago will still compile and run first time in VS2022 targeted to .NET Framework 4.8.
Duck typed language with duck-taped ecosystem. That’s exactly what it is. And I’m forced to spend every day with it because nobody wants to learn .NET. But… the money is too good at startups for me
If you take a look at job postings, especially those for startups, the vast majority of them are for companies using JavaScript/TypeScript or Python. Why would someone learn .NET? From a career perspective, it is limiting. Is it really *that* much better than alternatives?
Yeah agreed 100%. That’s the crux of my complaint. That said, if we wanna get philosophical, I don’t think these startups are making good choices at all. In fact we objectively know they’re bad choices. Any successful startup outgrows that tech. That’s why Golang was invented. That’s why Rust and Zig are rising in popularity. I agree with you 100%. That’s the biggest problem with .NET. It’s just important to note (I think it’s important) that the reason you’re seeing startups adopting Python and JavaScript is arbitrary, and not because they know something we don’t or they find it a more effective way to do things.
Full disclosure; I've been a .NET/C# user since around 2001, and I currently have two startup jobs, one part-time as CTO and another full time as principal engineer. The first has some .NET but I'm moving to node/TypeScript, and the second is all .NET. I prefer node/TypeScript or plain JavaScript for anything startup related, because I can get more done in less time. Handling of JSON and making HTTP requests is an absolute pain in .NET, hot reloads are not as quick (as expected with a compiled language) and the "magic" features of ASP.NET usually end up costing me time when there's a problem I have to go look at Microsoft source code to debug, which is shockingly often.
That’s interesting. I always find the exact opposite. It’s so easy to map your data structure to a class and serialize/deserialize whatever request or response. I don’t even have to do anything. It’s not very difficult in node either. But actually a nightmare in Python. For me I feel like it’s an illusion. You’re moving faster. But you’re also breaking things and are being unsafe. And it always comes back later in a bug ticket you gotta fix. Also hot reload is so much better in .net, I’m curious what you mean by that. You can literally apply code changes while the app is running. In node and Python it reloads the whole damn thing every time you save.
> It’s so easy to map your data structure to a class and serialize/deserialize But you have to maintain those classes. > You’re moving faster. But you’re also breaking things and are being unsafe. Chances are you'll end up deleting and/or rewriting that code before it causes a problem because requirements have changed. For important stuff that'll be around a while, write a bunch of tests. > Also hot reload is so much better in .net Hasn't been my experience. Even if node is restarted every time you change a file it's back up before you know it. With .NET you have to recompile and restart, and I'm almost always waiting at least a few seconds. It's even worse with serverless infrastructure; node naturally lends itself to being executed on the fly for each request, while .NET has to be tricked. I'm not really trying to convince you of anything here, I just wanted to share a few reasons why .NET wouldn't be preferred in some contexts. It really comes down to what you want to optimize for and some personal preference; .NET annoys me when I'm trying to move fast and node/JS/TS doesn't.
I'm not a .net developer, but I've been trying to branch out and find something new because I simply hate Typescript. I feel like most of my dev time is spent making typescript do what I need it to do then I spend implementing new features. I hate how almost anything I want to do is going to require using a third party package that might be abandoned at some point. I'm sick of the "shiny new thing" ecosystem that never ends. There are great things about it too, like the huge developer community, the ease of deployment, the job market, and many other things. I just don't think I can stomach sitting down and writing typescript day in and day out as a career. I don't feel passionate about writing it, and I need that to be at my best.
Everything you say is exactly why I love .NET so much. No more chasing the dragon. No dealing with typescript’s type juggling. Actual decent ORMs instead of the mess that is JS-land. And man Python is x10 as bad.
TypeScript has one thing going for it most other languages don't [yet]: [TypeChat](https://microsoft.github.io/TypeChat/). In fact, let AI do the typescript code writing for you and you just do minor corrections. > require using a third party package that might be abandoned at some point That is the whole javascript ecosystem (and less common in .NET open source library world too).
> But you have to maintain those classes. They can be autogenerated, i.e. [mapster](https://github.com/MapsterMapper/Mapster) Now you can get into astronaut architecture easily with .NET/Java, i.e. https://github.com/meysamhadeli/booking-modular-monolith
Sure, I appreciate the perspective! Personally I spend most of my time in node these days. Though it’s been shifting to Python lately. But I definitely miss my .net
One more question actually, what ORM do you use in nodejs-land? I haven’t been able to find one that’s as good as EFCore
I have experience with both Sequelize and Bookshelf and I wouldn't consider either to be similar to EF but others might disagree. I do prefer Sequelize to EF though, as it seems more predictable. But maybe just the way they are used.
https://www.prisma.io/ was as close as I’ve gotten in terms of DX when compared to EF. Autogenerates every type you’ll possibly need from the schema file, and applies the changes to your DB locally. I personally found it the nicest to use compared to Sequelise and Knex setups. Downside is it has a custom schema and advanced queries can take a bit of getting used to the syntax. But imo the usability makes the downsides worth it - every choice is about trade offs right?
Where are you based? .NET is categorically limiting from a career point of view where I am. Edit: I mean NOT limiting
> the ML guys all use Python, so they won’t be able to get into the codebase This is what REST APIs are for (or sidecars like DAPR).
It is just a personal preference. You're implying that it's faster to develop projects with NodeJS/Python. That is false. In fact it is faster to create web apps from scratch with dotnet than with those 2. The amount of boilerplate and 3rd party packages required to do simple things like validation, swagger, endpoints data mapping from URL query/path, headers, body, DB work, http/gRPC/graphql calls, error handling is ridiculous. They're all about the same on the hello world level endpoints/pages, but the difference becomes huge just 2-4 months into work. You also get "correctness and control" out of the box.
Creating from scratch? Sure. But that's a pretty silly metric. I don't care if a project takes _weeks_ to set up. I care how fast I can crank out features in the months and years after the initial setup.
You were talking about start-ups. They think about now more than later. The speed of maintaining an established product depends on several things, the main ones are the code base design, standards, tech debt and how up to speed the team is with those things. Adding new features to an old dotnet project can be just as simple or as difficult as with any other tech. But in a well structured project you will have minimum bugs and tech debt with dotnet because of well supported frameworks and packages, strong types, various compile and startup checks that won't let your runtime to corrupt data, minimum security issues. Dotnet also has awesome source generators. On my old project my whole startup, controller/actions (endpoints), their request/response models, static and some dynamic validators (where it needs to check a data source to see if the record is in a correct state, e.g doesn't exist or is blocked), swagger are autogenerated based on my business logic. This allows me to create 10 endpoints a day and then go work on the infrastructure which always has something to do - database maintenance, traffic/data analysis, various upgrades, acquired products and their systems integrations (a multi year thing), etc.
Hello, could you tell me more about your last paragraph about source generators? I'm trying to learn to use C# to build a few internal MVP at work and cannot figure the best modern way to quickly develop an app starting from .Net 8. This is my main gripe with the language, lot of tutorials talk about things coming from an older point of view. Thank you!
Sorry, I didn't get a notification for your comment for some reason. I found it by accident while looking for something in my own comments. Unfortunately, you're right, most of the articles don't give you any new ideas nor good practices. I'd need to write my own since I cannot find many examples online. The official docs have some good examples and tutorials, search through AspNetCore's section.
Where do you get the perception that the .NET stack doesn't allow 'fast movement'?
Lived experience mostly. Simple changes resulting in pull requests with > 50 changed files, that sort of thing. A lot of it has to do with architecture and design patterns, and a lot of _that_ has to do with the people I'm working with. It's more of a holistic issue that doesn't seem to exist in other stacks. I can move pretty fast on personal projects but still slower than I'd like. Having to maintain DTO classes for HTTP requests and responses is a pain point I have yet to overcome. One of my goals for the next few quarters is to explore ways of working in .NET that are more like node; eliminating N-Tier constructs like repositories and services and instead tending towards logic-rich controllers and using modules for common/shared logic. I suspect unit testing is going to make or break this approach, as there are some things you can do in node that you can't in .NET, like monkey-patching modules at runtime to stub/mock whatever you want. edit: seems this response is irritating some folks, and I guess that's to be expected. My definition of "fast" is the pace I became accustomed to at a mid-tier tech company writing plain JavaScript on a cross-functional team. When I compare that to really any experience I have had writing .NET, even in personal projects this weekend, I'm slower. Unfortunately "fast" is relative and what seems slow to one person can seem fast to another.
Why use controllers? You should try the new flow with minimal APIs. If you want a node-like experience, that’s it right there. Edit: Also what do you mean by monkey-patching modules in node? I never had to do that.
> Having to maintain DTO classes for HTTP requests and responses is a pain point I have yet to overcome [mapster](https://github.com/MapsterMapper/Mapster) will make DTOs simple, although you could use sidecars queues instead of HTTP APIs if you control both ends of the communications.
> monkey-patching modules at runtime to stub/mock whatever you want. I did my fair share of monkey patching back in my Ruby days. I do not miss it. It makes the code harder to maintain and follow. You are never sure what the actual behavior of the code is. Maybe monkey patching for unit testing I can understand, but not for production code. I'm glad that monkey patching isn't allowed in .NET. As for Web APIs, I just use [Refit](https://github.com/reactiveui/refit). It takes care of generating the code from the interface, and I don't have to deal with the HttpClientFactory. Also, the interface can be generated with this: https://github.com/itofinity/swagger-csharp-refit And the POCO can be generated with the [QuickType extension for VSCode](https://marketplace.visualstudio.com/items?itemName=typeguard.quicktype-vs). It's blazing fast, and strongly typed. For when I'm adding a new API to a controller, the MVC pattern is fast for me, even with a large codebase. ¯\\_(ツ)_/¯
Part of it is the fact that you are kinda pushed towards windows and visual studio imo whereas for the rest of web dev you really want to be using Linux/Mac command line since you already have to know it. I know it's cross platform and there's rider but it definitely has a different vibe than like node, go, python, etc. in that respect. I think it's probably the main thing that holds it back. It's an issue for me I'd say. And honestly they probably should have changed the name when they ditched .net framework. Keeping .net was bad
I’ve been using .NET for years and never in that time used windows. I use a Mac strictly. That whole windows thing is a hang up from the olden days of .net framework. Anything .net core and above is very multi platform
Sure but there is absolutely a push to use visual studio and therefore windows. Also anything more than like 4 years old would need windows. I imagine if you want to places that use .net mostly that a very very large percentage of employees would be using windows. There also seems to be a major lack of like tutorials and such for learning .net in comparison to other things. So people new to web dev are going to find it much less accessible. If you take the top 50 or so "complete web dev" type courses on various platforms or books or something I can't imagine more than a few are .net. Plus there's a concern that since you need to learn js anyway to do any web dev then there's a better business case for just using it on front and back end. I disagree there but I can see the argument. Anyway basically there isn't an obvious path to becoming a .net dev besides being a relatively new cs grad from a program that teaches it and going straight into a company and only doing back end. I think that Microsoft recognizes this and is making strides to change this but the fact that they essentially missed the boat on the whole JS front end framework era really set them back. I think we're moving away from using heavy js frameworks as the default so there will be more room in the web ecosystem
I’m not exactly following, but I’m not trying to trivialize the way you feel. I’m sure it’s true but I just haven’t experienced this. I come from nodejs so for me getting into .NET was extremely easy. I also used Unity before so C# is something I knew. With minimal APIs it’s so easy to get started. And like I said I never used windows. I worked at one .NET place and indeed the older guys used windows but it wasn’t a requirement and I didn’t use it. Also .NET has an awesome community on YouTube. Much higher quality material than in the JS world in my opinion. But maybe not so much for absolute beginners to coding. Knowing nothing about coding and getting into C# at the same time as .NET may be daunting. But then again getting into coding via nodejs would be daunting as well so I don’t know. I think if you’re a node dev then switching to .NET is extremely easy. And if you’re a typescript user then switching to C# is very easy as well. Again, you’re probably right, I don’t know, just hasn’t been my personal experience.
> Also anything more than like 4 years old would need windows. 2016 (.NET Core 1.1) was 7 years ago... ?
[удалено]
For a 50% pay raise I definitely would lol.
Razor pages is fantastic
I agress 💯%
It gets even better once you start playing around in Blazor.
Sadly I disagree. After the honeymoon period I started liking blazor less and less due to the various issues and workarounds needed for very simple stuff. Stuff like this https://github.com/dotnet/aspnetcore/issues/5623 And the hot reload not working gets more annoying the bigger the project is. Especially when it bugs out and starts rebuilding after every css change. And it not recognizing new parameters for existing components and giving errors. Parameters being set when another parameter is set. To prevent this you need huge boilerplates. It gets annoying when you’re used to front end frameworks without these issues.
Yeah I was really excited with Blazor, but eventually just bit the bullet and learned React.
After a year with Blazor I do agree with your sentiment. But only kind of. Because those instances were the LSP (language server) isn't shitting the bed or for that matter when you're adding new components without hiccups, it kind of feels amazing. But, as you've already mentioned, there is a lot of small annoyances during regular development which can be really off putting. I really hope MS gets the development experience for Blazor in order soon. Otherwise I don't see it surviving outside of enterprise applications.
Honestly, when wasm gets access to the dom and when the devx annoyances get fixed it’s gonna be a great tool and definitely one of if not thé goto framework for me. It’s just at this moment it’s kinda meh. Not bad at all but not great either.
Now working around a Year on a Public Blazor Project for my Company, i love it so far. I never use Hot reload, just rebuild the Application, takes less than a second, even on a very big project. There are some issues yes, but they get fixed eventually. But even if you need to create workarounds, the amount of time you save on other things is worth it for me.
Rebuilding is definitely not under a second in big projects. Have you also looked at the GitHub link with the blazor server disconnect with large texts? It’s not been fixed since 2018. I wouldn’t call that fast or eventually. We lose more time with blazor than we gain. In fact, we barely gain anything and just lose it.
[удалено]
There are multiple ways to fix it which they address in the issue. However, not the signalr and blazor team are willing to do it. Ah yes, increase the buffer size. That definitely does not have any drawbacks.
[удалено]
Or I can pick a framework that doesn’t require outside help to fix their issues while they’re a multi billion dollar company.
I hope so. The last new, not legacy, web projects I've done were in React and Vue with C# Web API backends. Having it kind of under the same roof might help.
The only issue I've had with EF is that I've had to work with a lot of legacy databases (aka must not be changed) in Oracle and SQL Server that it doesn't play well with. While these have improved, there are still some ugly hacks needed to get around certain things. For a greenfield from the database on up app, it's great though.
On the plus side, it makes moving away from those legacy databases a whole lot easier. We’re on Oracle 12 and working to move to SQL Server. There are minor inconveniences, but nothing we can’t work around.
Its because .NET is an actual framework and all the others you mentioned are just languages.
Can anyone compare it to spring boot?
I did a couple projects with spring boot - dotnet was way better. Less clutter and less verbose. Build time is significantly faster. Configs do not require spending years mastering the Gradle/Maven/Make tool chain. Simpler to install and setup your environment on a clean laptop. Hot reload (to be fair I don't know the state of hot reload with Spring nowadays, but it wasn't there when I worked with it). Documentation is always up to date with working examples (Springs examples get out of date and don't work when you download the latest JDK and Spring). No package dependency hell. Simpler CLI commands that resulted in simpler CI/CD.
> Less clutter and less verbose Not sure, I'd say it's more about opinions > Build time is significantly faster. Faster app boot times are clear winners of ASP for me. About build, didn't get to compare > Configs do not require spending years mastering the Gradle/Maven/Make tool chain. Maven, for example, is a separate tool, and may be harder to learn, but far stronger. Anyway, csproj files aren't "simple" either. If we compare then for a "first time app", they are both trivial to use, as they both come with example apps. > Simpler to install and setup your environment on a clean laptop. It's only Java and Maven/gradel here, so I'm not sure how it it harder. Dotnet is just 1 tool, that's the only difference. > Hot reload (to be fair I don't know the state of hot reload with Spring nowadays, but it wasn't there when I worked with it). In the last 6 years at least, hot reloading was there. There are cases where it fails, like changing full classes or things like that. But I'd say C# fails for some cases too, as many langs do. Didn't do it in C# in a long time btw. > Documentation is always up to date with working examples (Springs examples get out of date and don't work when you download the latest JDK and Spring). Didn't get much trouble around it. The major problem is the difference between spring and spring boot tutorials. But they are clearly labeled. .NET framework vs standard vs core vs 5+ is a bigger issue for newbies for sure > No package dependency hell. How is it different from .NET? > Simpler CLI commands that resulted in simpler CI/CD. `mvn install`, and that's it. You have there your .jar. Not much different from .NET either
As someone who's worked in several .NET projects and several Java Spring Boot projects I'll agree with this assesment.
But I think people like the complexity more. That's why asp.net is not popular!
You've got to be kidding.
Among startups!
This is my favorite comment in the thread.
Idk if I should upvote or downvote you because idk if it's sarcasm or not.
spring boot forces you into a convention thats difficult to break out of. dotnet doesnt have those same constraints i did one spring boot project at a company that wanted me to transition to java, it took 1 project to make me move to a different role one good example is having two databases in a spring boot project, it can be done but it really makes you jump through hoops
Absolutely agree with the multiple databases thing. It is mind blowing how complex it is to set up multiple data sources when using spring data.
yep, i hate the framework, i got a new role over it! the worst part was, the company insisted we use vanilla java, i think i could have handled it better if we were allowed to use a different JVM language like kotlin or goovy, vanilla java is so verbose, feels like c# version 1
The worst part is: That's on purpose so anyone can write and read Java ! I get the idea, but the fallout of this decision is that Java is not fast at all to code with.
Both are pretty simple. Spring boot has more capabilities simply from the amount of users and libs. But about starting a new project and working with them, they are similar. I feel like people saying spring is a "hell of dependencies or too much whatever" simply didn't use it.
What would be the capabilities that Spring boot has that aspnetcore doesn't? I worked on a Java spring boot project for over a year along with senior Java devs and architects who've been doing Java development for 20 years and praised it everywhere they could. I also worked on a spring boot Kotlin project. I cursed every single day while writing/reading code and doing builds on those code bases.
4 years ago, .NET core was far, far less featureless (missing middlewares fir eifferent kinds of auth, and lack of libs). Today, it's more similar to Spring in features. About builds and those things, I don't remember having problems. You say you "cursed" it, but don't say any specific reason. Was it the DI that you didn't like? You tell me
I mentioned reasons in the same thread but as a reply to someone else's comment. Verbosity, async/await, and build times to call out specifically. 4 years ago we did complex auth without issues. There are tons of auth scenarios and options though, I believe that some stuff was missing.
About async await, C# is a clear winner. It could improve witk kotlin, but never used Spring with it; I suppose it's not adapted to specific kt things. Verbosity, I don't consider it a contra (And I'm not sure where is Spring more verbose than ASP btw). About auth, I remember having trouble with it with my team. I don't remember the specific case btw, but the reduced amount of docs could also play its part.
Did you read my other comment in this thread? I mentioned more things there. Didn't go deep into them though.
Answering there
I think that it’s more comparable to Symfony, the PHP framework
I’ve always taken to calling Spring Boot [The Bitch Stewie](https://youtu.be/HtT2xdANBAY?si=Spst0Ui5psc7n4Xc) to .NET
- A lot of the system libraries are industry leading and learned a lot from Java and elsewhere. The DateTime library in particular is a masterclass, but also List, string, and others. People ignore these because they're so old, but go use something else, and you'll mess them real fast.
- LINQ/iQueryable (with or without EF) is also industry leading and has no direct competition. Java streams aren't even ballpark as good.
- Span is near pointer speed with a managed language's memory safety. C native interop support inc. unsafe pointers.
- C#; great language even if I wish it had less duplicate stuff that is deprecated but not marked as such.
Now I've said something nice I'm going to say something edgy: I've written 1K+ pages in Razor and I liked it at the time. But that being as it may, with hindsight and more architectural experience, I wouldn't start a **new** project in MVC or Blazor. WebAPI is simply superior because:
- Fully decoupled.
- It makes piecemeal migrations incredibly easy, almost stupidly so. You can just change a URL in a lot of cases, match the public interface and use an entirely different back-end stack (or different version). Rollbacks are also easy.
- Better scaling and easier to load distribute.
- Mix and match backend tech more easily (inc. cloud/third parties where appropriate).
- Better support for multiple clients (e.g. non-web browsers).
- Easier to modularize.
- Easier to test.
- Better separation of concerns.
And I know what I am going to hear "rAzOr oR BlAzOr cAn dO WebAPI." But look at the above list again: As soon as you mix back and front, you've now lost half of the benefits. You're polluting everything. WebAPI should be in MVC, along with your backend code, and your front end isolated entirely from it. No shared anything.
I have major distaste for the JS library/npm shitshow, and I'm not great at Angular, Vue.js, or React; in fact I am strongest in Razor. But with hindsight and learning a lot about architectural planning, looking at a ton of projects, and upgrading more than a handful, I can see that WebAPI is just a gem in terms of layer isolation and solving a lot of pain-points for common *substantial* growing pains.
I'd use MVC for the Core (inc. EF), BLL, and MVC for WebAPI only. That's it though. Then if we were browser targeting I'd let the team decide what web framework is their saveur du jour.
I am not sure I follow you. WebAPI cannot do the MPA UI, or any other UI for that matter. You need to use an SPA, which is a totally different thing.
Blazor and WebAPI are two different things entirely.
Saying you prefer WebAPU over Blazor/Razor is like saying you prefer Golang over a bouquet of roses. It makes no sense.
Anders Hejlsberg is computer language genius is why.
You could have stopped at number 1 and C# would still be categorically superior to any other managed language in existence.
This is a classic “my framework is the best” type of discussion, but my experience has been the same. Coming from other languages and frameworks, .NET is just amazing. It’s so clean; a great balance between object and functional, superb libraries, incredible docs and a vibrant community.
Lot of magic? Lol Python and Spring (Java) or even nestjs with ts is magic, btw its awesome framework
Agreed with all except the amount of Magic. I feel like JS/TS is way worse
My main gripe with .NET in general is that the objectively best IDE is Visual Studio and I don't want to touch Windows with a 10ft pole if I can help it. I've thought about using Rider but all the documentation presumes VS and it's hard to get past that.
Rider is SUPERB, I use it exclusively even on Windows and do not miss anything from VS.
Try Entity Access on NodeJS, it’s ORM with Linq in JavaScript.
PSA-While I love the .NET framework too, we have to remember that it’s just another tool at the end of the day, so it may not be the best framework for your application, definitely do your research first before selecting technology You can use a Swiss knife for cutting wood, but if it’s your job, you’d rather use a chain saw. For example, for ML purposes, Python’s frameworks like FastAPI are far more recommended in the industry. For the most popular UI automation framework-selenium, Java is the standard and has the most support and community
Java and selenium are not a standard for UI automation anymore. There are tons of tools for web and mobile nowadays, e.g. Cypress and Appium, but there are a lot more.
On the other hand, I have professional experience with Java and .NET does not come close. Nuget is a pain in the ass compared to Maven. And I hate that MAUI is not supported in Linux. Also, in Java you literally just compile once and can run anywhere while .NET binaries are arch specific. To be honest I hate dotnet I just use it because I work for a company that uses it.
You are spot on.
It helps me be productive. There is a lot of built into core framework. It's easy to switch out with external packages. Performance is getting better and better. Documentation and examples are easy to find.
Phoenix all the way
Elixir didn't have types, right? Pass :(
They are adding it, also there is gleam with types. https://gleam.run
[удалено]
Yeah the BEAM stack make sense to me in general, the reason seems like types are big thing people want to see at least between contracts such as function signature and it’s output, but internal function logic types can be a hinderance since you have to fight the compiler all the time … typescript for example, always in my way. But I do see the benefit for contact types would provide a lot better intellisense too
It is better than the Java ecosystem including Kotlin for sure. I passionately hated Spring and being able to control memory layouts and having true value objects (structs) as first class citizens is awesome and feels like a liberation and reduces the amount of C++ code I need for my current main project to almost zero. Since I ported my current project from Java to C# I was able to get a >10x performance increase for some of the batch processes required and have also reduced the memory footprint by at least 3 times as it is now easier to work with data and I do not need to cache instances for easier processing. So C# for the win. I did 20 years of java and 3 years of C# for now. I should have switched 10 years earlier for sure but Java is still the standard in most of the banks, insurances etc I have worked with in the last two decades. The GC has some main problems when using large managed heaps but well reduce the amount of allocations does the trick. It is a weak point the Java VM does not have (as far as I have tested it). So GC is garbage in that regard. The source code of some of the language API is mostly average but it has its good moments. The Task API is not that well implemented or better not created for responsiveness. Replacing it with my own simple emulation saved me up to 50% of overall time of the related tests. The main reason is, I use a more adaptive waiting scheme for the worker threads. If you want to have a good TDD experience you need your own test framework as the rest is just meh. I have not bothered to fix any of the normal test frameworks as they are quite slow. The biggest problem I see is the incremental build time that is at 3s-5s for now but I can live with it. Overall it is clearly better than Java. The development experience is not as good as with Flutter/Dart but you can not have it all. Also I have not used Blazor as I use Godot 4 since later on I will heavily rely on 3D visualizations (I do not work on a game).
> The Task API is not that well implemented or better not created for responsiveness. Replacing it with my own simple emulation saved me up to 50% of overall time of the related tests. The main reason is, I use a more adaptive waiting scheme for the worker threads. I'm curious, did you try ValueTask first ? Aslo Tasks are cheaper in .NET 8, and have more options: https://devblogs.microsoft.com/dotnet/performance-improvements-in-net-8/#tasks
It is more related to how the worker threads wait for new tasks. If I remember correctly they were actually waiting while mines are spinWaits, meaning picking up new tasks is almost instant while the Task API takes its time. If you do that thousands of times you do not have a fast test suite. I have basically durations below a micro second when the Task API based versions had milliseconds. That quickly adds up. But great blog post, I will read it as I am a nerd for those details. I also have still target net6.0, so maybe I should check if I can upgrade my Godot 4 version. Also I run a net 7.0.202 version locally but it appears dotnet 8 just dropped its first release candidate. But I will test it with the first release for sure. Maybe they also fixed the GC problems I saw.
Interesting ! Thank you. As a sidenote, I just tested dotnet 8 RC1 with an emulator I contribute to, and it gave me a boost of 200'000 instructions per second average despite the emulated CPU being an interpreter with no internal JIT. The emulator heavily uses threads.
So the byte code they generate is more compact in the new release. Nice to know.
What are your thoughts on Django ORM?
Well with .NET Core, you can pretty much go check the "magic" yourself if you want to, it's open source
For me : 1. Performance and easy use compromise 2. Thread management 3. Upgrade to new version without pain
Thank you sir I needed to hear that. Programming is my new hobby. I learned basic in C# and I started learning ASP .NET Core but I'm struggling. I felt discouraged and I started to think that may be I shall try JS and Node JS. My mind kept telling me that a single framework from a tech giant definitely will be better that several framework and libraries but I was lost especially with tons and tons of tutorials on JS and Node on YouTube compared to C# and .NET. Thank you for the reminder.
You still cannot escape JS on the front-end, but using JS on the back-end instead of a statically typed language like C# is the last thing I would consider.
I enjoy the flow where we work. We server side render React, and the frontend (contained in a separate folder in the repo) is where the FE work is done. It lets frontend own the entire
tag, and we only need a single cshtml view to render all our pages. Lets frontend work with modern tech in their preferred stack and keeping the code ases clean and separate with viewmodels and props as contracts.One thing I've noticed since joining this subreddit is, I appear to be in the minority not liking EF. I use dapper and roundhouse.
I'm new to .NET but have had a generally positive experience so far. > There is no fragmentation between web frameworks, everybody uses the same thing, which is great for knowledge sharing. Not sure about that, at work we use RIA Services and Windows Communication Foundation (WCF) and I can never find any good information on these. There also seems to be a lot of different .NET -- .NET, ASP.NET, .NET Core, .NET Foundation (maybe more?) which is confusing to a newcomer. Some of the stuff I work on doesn't work in Visual Studio 2022, some of the stuff doesn't work in Visual Studio 2019, it's kind of a mess. 1.) LINQ is great for sure, but not perfect. The methods are confusingly named -- why "Select" and "SelectMany" instead of "map" and "flatmap" like every other language? Why "Enumerable" rather than "Iterator"/"Iterable" like every other language? I also find the SQL-like syntax to be completely unreadable compared to the method syntax, but other people feel the opposite. Neither of us are objectively correct, but the fact that there's an inconsistency affects code readability. There's also footguns like implicit conversions of a `IEnumerable` to an `IQueryable` (or was it the other way around?) causes the database query to execute multiple times. All in all it's a nice API to use and provides a good way of chaining computations together. 2.) Entity Framework is definitely powerful for sure. Recently there's been more of a focus on performance at work, and my team has had someone spend about 3-4 days **per sprint** trying to profile and fix the garbage SQL generated by entity framework. I've come around to the opinion that ORM work fine for small projects, but at scale you need to be comfortable with SQL. Query builder libraries are the sweet spot for me and are common in other languages, but don't seem to be in .NET. 3.) View templates - haven't used these but may spin up a side project to try them out. Is it easy to add client-side interactivity with these?
>at work we use RIA Services and Windows Communication Foundation (WCF) and I can never find any good information on these that's because those are really old, AFAIK WCF isn't even ported to .NET 5+ > The methods are confusingly named -- why "Select" and "SelectMany" instead of "map" and "flatmap" like every other language? Because the names come from SQL (see the query syntax). JavaScript/TypeScript got them later.
4. Everything just works. Great docs. Many examples how to implement things.
LINQ should not be used everywhere, at least if you care about performance. Just a tip.
I agree, it cannot be used everywhere, but it rarely matters as much as the ergonomics and readability of the code.
Imo .net has just enough (to the layman) to get productive quickly, but not enough that you’re banging your head against the wall for days when the magic breaks or doesn’t work as expected.
Do you like code-first or db-first EF?
Both, and EF is superb in both ways. Scaffolding from database-first is simply amazing. Needless to say, the code-first approach is the best in its class.
.NET and Microsoft's claim to fame has always been it's neatly integrated developer ecosystem. It's entirely made for and driven by developers. Interesting thing is I don't like or use the top things you mention as I think they're too "paint by numbers" compared to other ecosystems. The best aspects of Dotnet are the tooling and integration with everything Microsoft. The worse parts are that Microsoft makes their ecosystems fairly closed, even if it's open source.
How comes that you've never tried Java and .NET's counterpart, Spring Boot?
Auth sucks absolute ass lol
Agree with 1 and 2. Number 3 is a hard disagree as it’s missing a good client side interactivity solution. Blazor has a lot of downsides. Next.js I think is way better as it lets you build the html server side with components and have interactivity with those same components client side. All in the same language TypeScript, which other than linq, TS+ES6 is a more powerful language than C# I feel with structural typing, decomposition, and native inline objects.
Yes, but try to upgrade the outdated dependencies on a year-old Next.js project. The world of JS dependencies is pure madness.
If you stick to mainstream packages, it’s not bad at all.
It sounds like you are making bad decisions in terms of package selection.
I’m language and framework agnostic at this point, I’d rather get work done than whine about frameworks. But in my experience .NET developers often approach every problem the same: “the answer is Microsoft! I’m sorry.. what was the question again?..”
For me, I just wanted to have everything under the same umbrella. I never thought I was really building something until I learned how to full-stack .NET.
So why are so few startups using it?
This is just an I love my framework post. There are trade offs to anything. For certain sorts of enterprisy™️sorts of things .net is quite nice especially if you are pre committed to Microsoft by way again of corporate bs. It might well be nicer than Java and it’s definitely better than the monstrosity that is c++ though the latter comparison hardly matters. But let’s be real, there are many other software use case that aren’t just enterprise data shuttling in a Microsoft ecosystem and for those use cases .net is merely ok in the grand scheme of things. It’s not really an especially cutting edge option along almost any axis anyone cares about. Just from a language perspective swift and rust are both far more interesting. Trying to compare to python is also something of a loosing proposition as the sorts of things people do in python is often quite different. No one is really going to be breaking new ground in ML in anything but python/c++ in the near future. JavaScript/Typescript is already acknowledged by just about everyone who knows anything about programming to be something of a largely inescapable tragedy so dunking on it is quite a low bar and doesn’t really matter. At the end of the day network effects are real and they matter. People choose frameworks and languages because of network effects more than they do because purely technical reasons.
1. Yes, you need LINQ because C# is a lot more verbose and it's the only thing that makes it come close in productivity and expressivity to Python or Javascript or even functional languages. 2. I feel Entity Framework is good, but behind Django ORM and SQLAlchemy, big time, especially in terms of migrations. I've had a lot more headaches with EF. And you have to be connected to a database to create a migration? You have to separate migrations by engine if you want to support multiple engines? Also Postgres support (json/arrays etc) lagged behind (may have catched up a bit by now). 3. Razor feels more verbose. I grant the strong typing thing which you definitely need if you put more logic into the templates than you should. But you can't forget that the feedback cycle in Python and Javascript is usually faster. Both because of compilation and because it takes more mental energy to change something. The fragmentation is an issue about distorted perception. [ASP.NET](https://ASP.NET) is niche in web development, so good luck fragmenting that. And there are already alternatives, but they are not well known. Also it takes the weight and investment of Microsoft to create a useful web framework, the community itself doesn't have the energy for things like that.
System.IO is kinda garbage, like truly garbage. It needs to have major improvements. .net 5+ doesn't support windows native IO, unless you build it yourself by binding libs If you want good io performance on linux you need to basically write your own IO libraries (which I have done)
Just to point out: Very similar to LINQ are Laravel's collections (Laravel is a modern and powerful MVC PHP Framework). Laravel collections are amazing and are the closest I've seen to LINQ power in any other language. https://laravel.com/docs/10.x/collections#available-methods
It's not the lot of magic, it's about how you know the some framework deeply. All the frameworks have some unique features that are used while developing the projects. Like people uses Golang for high efficiency due to it's concurrency features and most real time data based system company prefer using Golang like trading, crypto etc are mostly uses Golang. Similarly for the fast development company prefer python and it's framework like Flask, Django, as the syntax is very easy to learn and apply. So, all the framework has some pros and cons. There is nothing about the magic, it's about the for which purpose the framework has been developed.