Hacker News new | past | comments | ask | show | jobs | submit login

I spent a decade with C# and .Net and even in its current form which is easily the best it’s ever been I vastly prefer to work with Typescript.

Yes, you do need to set up some rather strong governance around it for it to work for multiple teams, but you should really be doing that with any technology, and once you do, it’s just excellent. Part of the reason for this is that it’s basically designed from the ground up to require that you build and maintain “template” projects, have strong linting, testing and pipeline governance, so there is a lot of freedom to make it work easily for your organisation exactly the way you want it to. Typescript is obviously not alone in this, but it’s far less opinionated than something like .Net.

The main reason is that .Net always becomes burdensome once you start using it’s included batteries. This isn’t really an issue with C# as much at it is an issue with it’s libraries. Take OData and Entity Framework as an example, the .Net magic behind them sort of share the same model builder, but they do so differently. What this means is that a lot of the cool OData features like patch doesn’t actually work with EF, meaning you’ll either have to rewrite a lot of the model builder (don’t) or have to work around it. .Net has always sort of been like that. It variates between being 50-90% “done” but it never really gets there until it moves on. Like EF, much of the EF 7 road map isn’t implemented yet, but here we are, moving on to EF8.

I think for a lot of use cases it’s a wonderful technology, and Blazor will probably be awesome until Microsoft moves on, but at least around here, it’s also a technology that doesn’t really see adoption in anything but small-midsized companies, and in my opinion, .Net is part of what hinders growth. Obviously not a huge contributor, but once you step out of where it excels, you’re just going to have to fight .Net so much harder than you will with Typescript. Which is sort of interesting considering they are both Microsoft products which align more and more. That being said, it’s not like it’s bad either.




Batteries are included, but you aren't forced to use them.


Previously from this account: https://news.ycombinator.com/item?id=38228674

The tldr of both the previous and this posts is OData being bad yet the author extends his grievances regarding it to the entirety of ecosystem.


It seems a little disingenuous of you not to mention how I never hide the fact that it's an issue with the batteries. I'd also say that considering how great OData's patch is with the modelbuilder it's actually EF that's being bad in this case.

You could also point back to other posts like this one: https://news.ycombinator.com/item?id=37538333&p=3#37541652

Where I also point out other, similar issues with other parts of the .Net batteries.


If you are having issues with EF Core, maybe it's not the tool's fault?




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: