I'm not sure it's a leaky abstraction per se. But there are definitely issues with it—issues things like the Google Closure Compiler try to deal with. One of th

I'm not sure it's a leaky abstraction per se. But there are definitely issues with it—issues things like the Google Closure Compiler try to deal with. One of them is this: eventually, Rails realized you should probably link your application to a particular version of a gem (see bundler), just like the Java world realized web apps probably shouldn't be resolving dependencies at runtime (see WAR files). Right now, JS apps are often just serving the latest version of libraries for things like DoubleClick and Google Analytics. Google can update what they're serving at any time without letting you know. If you use a build system to bundle the library into your code, you lose the benefits the user could get from already having the library cached. If you don't, you're exposed to someone else's whims on library updates, and you add HTTP requests to boot. The same goes for bundling something like jQuery into your app. You can bundle it in, but that data has to be sent downwire to the client when the JS goes down, even if it is just in one HTTP request. Or you can include it via CDN and a lot of users won't have to download it again, despite having to do an HTTP request. So it's all about choosing the right tradeoffs. Also, JavaScript runs as it downloads, in page order. So you don't have to wait for all 30/X round trips, though you may have to wait for X round trips for the last file (in page order) to run. Then it becomes a matter of prioritizing what needs to load first. Naturally this is stuff we wish we didn't have to worry about, but worrying about bandwidth and latency and how and when and in what order things download has always been necessary for network applications, and I don't see that need going away anytime soon. I'd love to be proven wrong though :)