And the standard entry point for a NodeJS package is "whatever is defined as the main property in your package.json." Do otherwise at your peril.
That's actually good to know (or perhaps be reassured on). While key-value stores have their place, I've wondered if the rise of NoSQL in web dev was triggered in part by the widespread move a few years beforehand to ORMs, which trained a generation of developers to look at databases through the lens of object relations rather than table relations. I'm (re-)learning Rails with the Pragmatic Studio's Rail 6 course currently, and reminded of why I liked it -- but in the last few years I've also come to renew my appreciation of pure SQL.
(I also suspect that the tradeoff of abstraction layers -- in exchange for having little to no database-specific functionality, we give up any and all specific to the database we're using -- may not be a good one, but that's a different argument.)
Indeed. I'm currently in the process of porting my companies product from Firebase to Postgres. We're making full use of postgres-specific features where that makes sense. I can't see why we'd ever want to switch.
Most DBs are much, much better if you commit to them and actually use their features. I dislike the practice of treating them as interchangeable and think it's rarely a good idea.
As someone with experience from many more backgrounds than "old php", my dislike of rails has nothing to do with what you're claiming. Plenty of frameworks have had convention and structure prior to Rails.
That said, I'll admit it does have some good things going for it, even if it wouldn't be my first choice in most cases.
My biggest gripe is the autoloader; it makes finding where something comes from extremely confusing when ramping up new developers on large, mature projects.
The enforced, common convention is a boon and a curse- consistency across projects is an obvious benefit, though I prefer a different structure myself.
Beyond that my gripes are more related to ruby and the tooling rather than strictly with rails itself. Of course you can tweak and configure rails to behave any number of ways, but the more you do that the more you lose out on the primary benefit, which is the community one-true-way mindset.
I've seen quite a lot of "Rails-hate" over the last view years, and it can only be coming from people who never got to experience the world that was web development before Rails: Every project had it's own, usually quite creative, structure. There'd be configuration values in `config.inc.php`, but also in `configuration.php3` and `config.old.inc`, and `index.php` and so on. Just by establishing a standard folder structure, DHH probably made web devs everywhere twice as productive.
I also think its reputation of being too restricting isn't entirely deserved.
As but one example: I often opt to use SQL instead of the canonical query builder, especially for queries that do not return individual models but aggregate values or the like. You can even mix-and-match to your liking, i. e. writing individual clauses of the query (select/where/join/having/count) in SQL and using the ORM for the others.
So here' to hoping for another 6 good releases at least!