Why is it that open source software which adds unnecessary complexity and slows down development tends to become popular but open source software which takes away complexity and speeds up development tends to not get any attention. It's like there is some kind of conspiracy.
public List<Customer> Find(Expression<Func<Customer,T>> expression) {...}
and then your client can use any random expression...
Find(c => c.age > 18 && c.age < 65 && c.gender == “M”)
and have that expression translated to either SQL, MongoQuery, or anything else that has a LINQ provider.
If done correctly, not only can you switch between RDMSs, you can switch between an RDMS and a Nosql data store without changing any client code.
When you are writing your unit tests, you can use in memory Lists to mock your data store and still test all of your queries without using a database.
Of course you also get type safety, autocomplete, and in the case of NoSql data stores, you enforce a schema over a schemaless data store and get to work with strongly typed objects.
I’ve never seen any purpose of an ORM outside of LINQ. They just add another level of complexity and still don’t integrate with the host language naturally.
all because of an inability to manage versioning change across the standard browser js api...
great for a giant megacorp looking to waste money on busywork and divide the workload across more employees (front-end devops?!?)
less useful when you already have to compile a backend, don't really have a problem with ES5, and understand that you are basically only tasked with making your dom updates dependent upon data model changes, YMMV
what does versioning has to do with bubbling, wtf?
In fact, the parent does see (and called) that "obvious problem with being stuck on a single version of anything forever".
That's why he doesn't cheer for the band-aid solution that's webpack and doesn't thing it "represents progress".
I should be clear though, from an architecture standpoint I think it's much better to go straight to SQL, and keep the data unnested. Like anything in life, it's a trade-off. It requires more up-front data model knowledge and more up-front work, but it's much easier to debug, more flexible, and performs better.
For juniors, it's best to have a less abstractions.