Threading and tasks add unnecessary complexity.
Speed? What speed, this web assembly example is more than 5mb of .net libraries. We make apps for people on less than 3g.
Entity is one of the worst, least productive and most error prone frameworks we’ve ever had in our stack. Especially code first.
Linq almost made us stick with C# forever.
I think that hits the nail on the head; I never got why anyone used that. We never did and we have been using c# for a long time (all over to Core now) and all the horror stories never applied to our work, I think, because we never touched entity.
There were certainly a couple gotcha's and quirks to get used to, particularly around initial modeling, but the unit of work pattern made possible with task local storage was spot on.
JavaScript isn’t light either, if you look at the amount of stuff a major website loads.
C# on the server running on .NET Core is one of the fastest web stacks, and the async and threading help greatly with that. You can keep everything synchronous if you want, but it's good to have the flexibility when needed.
How is EF unproductive? What options are better?
Whether we gain a little efficiency or not from core is relatively irrelevant if it takes longer to produce the solutions.
We’re not Netflix, our max load is 60.000 concurrent users, and that’s relatively rare.
What isn’t rare, is someone loading an app in a remote area, where the mobile coverage is terrible, and if it had to load .net libraries in that setting, they’d frankly never be able to do their jobs.
So the speed of .net core is irrelevant to us, and to most people really, I mean, Netflix runs on node.
If you don’t know why EF is terrible, I’d wager you’d never used it. We use LinqToSql in our C# apps. Why? Because it’s productive, and again, it may be slower than entity, but it’s slower in a way that really doesn’t matter to us.
I mean, the video highlights it so perfectly when the guy goes “look how fast it compiles”, as if that’s ever useful when your application takes much longer to load for the user.
I don't get the comparison on the client-side with webassembly though. This is an entire UI framework, and hasn't been fully designed and optimized yet, as stated. It's no different than using React and neither would be good options if optimizing for low-bandwidth remote areas.
I've used EF since it was first released, and we haven't encountered any major issues. We migrated from nhibernate a long time ago and fallback to Dapper occasionally for complex SQL and performance. What do use instead? Or is the argument to not use ORMs at all?
We’ve not really seen any real trouble moving to dynamic types, possibly because we utilize stuff like SOLID. When you’re not really using object oriented to its fullest, because it’s fullest adds complexity and complexity costs a lot of money and you’re already pretty fascist in your approach to how responsibility and changes are handled in your systems, dynamic types aren’t really a problem.
If I was building a huge system with a lot of complexity, I wouldn’t pick JavaScript, but I probably wouldn’t chose C# instead of JAVA either. And that’s not the way I would’ve viewed the world 5 years ago.
Anyway, I think people should use what works, I just think C# has lost its usefulness compared to other technologies and I really think web assembly is s terrible move for Microsoft.
But I’d love to be proven wrong.