Good question. I should be clear and state that when I say 1-2s page load times I meant the time from when one requests the page to when one can see it. In general API requests are fast, what is slow is having to always deliver a large JS bootstrap across the network (JS files, templates, etc) and then having to make the relevant API requests to produce the UI. Caching is generally touted as a good solution to this problem, but in my experience it tends to be insufficient. Yahoo did an (older now) study showing that 40-60% of visitors arrive at your site having an empty cache (http://www.yuiblog.com/blog/2007/01/04/performance-research-...). Another solution is to pre-fetch data for the UI and deliver that with the bootstrap but it's still difficult to speed up a ~1 or ~2 MB download. This is what really ends up killing the experience.
Only pull the bare minimum to render the initial page on the first request, load everything else you need, when you need it, asynchronously in the background. There is no way the 'bootstrap' is 1-2MB. There is absolutely no reason to load every single bit of javascript you could ever need on the first page load just like you don't load every image on your site on the first request.
It's really easy to armchair-engineer and just declare bad design. What's harder is to actually build a system that scales well in the very unusual circumstance that sites like Twitter, Google and Facebook find themselves in.
Let's take your solution: it's really difficult to build a development environment that allows a large team to work efficiently which is not based on having essentially a single bootstrap file when deployed in production. When you break apart your files into smaller chunks you are asking your developers to understand the intricacies of asynchronous loading of each file and impose dependency management on everyone. This is a huge problem at Twitter's scale.
I do agree it's very hard still and that many of the 'it's just an API' posts are wishful thinking for the next year or two.
However twitter is a perfect example of how not to do it, they inadvertently shot themselves in the foot with the hashbangs so they never know in the first request what's being asked for. That's kind of a mix between HTML5 history being so slow to come out and Google encouraging the # stuff in the first place. But everyone's still learning. Full page postback-less js applications are still a pretty new field.
Twitter were a very early trail blazer. As much as people hate it, kudos to them for having the balls to try it and let us all learn from their mistakes. I've got a project that's a horrible mix between postback and postbackless stuff. It's almost dailyWTF worthy, but I don't regret doing it as it's getting closer to getting it done right. And there are people using it right now and it works as much as I cringe about it.
For example if you look at the 1.5Mb js file they send when I do an anonymous request, it's got every possible action I could ever do regardless of whether you're on a tweet page, the main page, a profile page, etc. It doesn't matter if I'm signed in or not. They're all in there as templates. And then for some reason they wack in a load of compressed jQuery stuff, etc. It has how to sign up, how to add people to follow, congratulation screen for when your first few follows, etc.
That, to me, is just nuts. Why is there no split in the js dependant on the kind of user they're going to be? On reflection they probably think that too.
With regards to development environments, I do think you should force your programmers to understand your infrastructure. Give new programmers a couple of simple examples to play with on how to manage dependencies and loading files and that's that. In my view it's no different to saying 'we use these parts of C++, not these' or 'this is our coding style, you must follow it or your checkins will be rejected'. Or 'this is how the industry this app is for works, these are the general business rules most of them have, this is the general workflow'.
New programmers to your organisation always have to pick up some contextual information over time. It's your job to train them in the most relevant key information asap. I think far too often it's just a case of 'you're a programmer you're smart, let's just throw you in at the deep end and see if you can swim. Oh, why did you swim into the shark pen? Silly n00b.'. Very relevant: http://news.ycombinator.com/item?id=3736800
