Welcome back! Glad you’re feeling better.
I’ll try to kick the can down the road, at least on some of the bigger items.
Your comment about relational databases has been a huge topic, and is becoming bigger all the time. Many of us have been agitating for alternate database support, and pointing out that if you want to go from ‘green’ to ‘brown’ (i.e. startup/new code to enterprise/existing code) customers and applications, you will NEED to integrate with other data stores. This is a huge blocker for Meteor’s market penetration, IMO. Since there was an architectural decision to marry up so closely with Mongo (especially the minimongo bit), replacing it is major surgery. I do know they’re working on this, though, so you might find that within some relatively short amount of time (on a planetary epoch scale ;)) you would have those options.
The noscript tag is a good point - about site developers. I know we’re guilty. It’s a poor assumption on our parts. I will say there are people working on SSR packages that could serve as a fallback or alternate solution somehow. shrug
All of which is a bit of a regrettable departure from the clarity of your original question - I liked that you were trying to find the “so what” of Meteor, and now we’ve gone down into the weeds.
As I step back and look at where this conversation has gone, I think maybe the DAG answer is buried in the question.
In other words, maybe you’re exactly right. Trying on a new thought, here…
Maybe Meteor really is best-suited for apps that will not likely scale beyond X users (simultaneous, MAU, whatevs) or Y team members or integration with Z external services, nor will it ever implement Favorite Features A, B, and/or C. I’ve found that every new programming language, framework, paradigm, etc. is a response to the state of the industry that birthed it, and Meteor is an attempt to say “Web pages are changing. They’re not the 1997 front page of Yahoo anymore. We need them to feel more like mobile apps”, and everything flows from that. No-one likes to talk about what you CAN’T build with a framework (especially when you’re building the framework), and I think that’s what you’re doing here, raising questions about how far it can go and what it can do. I think that’s great - you should know what a tool does before you use it.
So - if we start with the destination “framework for rapidly building responsive web apps that solve a single problem”, and derive from first principles, we can tick off the design decisions. Relational database. Required? Nope. Chuck it. Globals? Who cares - this is a single-page-web-app. Noscript? Well, then I’m sorry, it’s not me, it’s you, this isn’t going to work. Dependency injection? Meh. This app is a walled garden, and we’ve built a templating engine to handle management of the body. We know what’s going in and coming out, and we can always check your Meteor.userId().
Maybe the DAG is “No, right. Exactly. What you said.”
If you haven’t watched Geoff Schmidt’s talk from the August Devshop, I think he does a great job of encapsulating this. (In fact, I suspect I’m just parotting the Kool-Aid for you.)
Actually, now I’ve gone back and re-watched it - here’s the closest bit to a DAG that I could find:
You really need to watch the whole talk to grok it - he really does do a great job of setting it up - but I’d say if you watch that and you still don’t buy it, or don’t see the value, then Meteor might not be meant to solve the problems you want to solve.