> make things so much more complicated Simple pre-processing and code-to-code transformation is typical in many different languages and environments. Pretty mu

> make things so much more complicated Simple pre-processing and code-to-code transformation is typical in many different languages and environments. Pretty much every time you start a Java or C++ project within some IDE you're essentially generating a lot of code automatically. And in the case of various JS preprocessors/transpilers it's not even that complicated. It's mostly trivial transformations, which in more capable languages would be expressed as macros, f-exprs or something like that. Maybe try writing your transpiler sometime? It'll take a weekend, and you'll see how easy and simple it is. > Everything is too abstracted. That's only because of your background. ASP.NET or GWT guys would not agree, I imagine. > it would sacrifice a lot of control and would become a huge lock-in liability. Control over what exactly? You still have an external database you need to manage. You handle backups, schema migrations and so on. I'd say Opa's abstraction of data storage is on par with "normal" ORMs (like Django ORM) in terms of flexibility/power ratio. I don't see a lock-in potential here, as long as data store used by Opa is available to other languages and environments. You can always just load the raw data directly from DB and do anything you want with them. Would be another story if Opa used in-memory, built-in in-process data storage (which is an approach I quite like) but it doesn't.