I don't have a problem with javascript, as I do make stuff with it. Done right, you don't have as much impact on the bandwidth as you think. If you have megs of javascript libraries being referenced from external CDN's, you're doing it wrong.
It's going to go down that road anyways till the end. Web browsers have ceased being about document markup and rendering, which is how it started, to running external code in complicated sand boxes. You can't put that genie back in the bottle.
The issue is being able to trust that javascript, which is really about trusting the sandboxes to not allow malicious code to be run. Tracking is a problem of course, but that is mitigated by blocking software that stops those specific scripts and domains from working. Once a Big Data company like that gets big enough, they'll just get shut down by the blockers, which is a very good thing. It protects our privacy as well as our computers.
If you don't want javascript and external code libraries you're only other option is to have a single universal API developed that ALL browsers adhere strictly to. Blocking tracking software is simple as a permissions setting at that point to not listen to any tracking tags or events set up in the page. AJAX type events would need to be classified accordingly and secured. An event going toward a different domain than the page? Blocked by permissions. Image not from the domain? Don't even download it based on permissions. CDN's should be registered in the browser as an alternative for any file that needs to be downloaded for a "page".
Above all, that API should have plentiful RBL's that outright disable all external calls. We want accountability? How about within an hour of malware being downloaded those RBL's are proactive like some email services and browsers start blocking that particular site or CDN automatically? That would make propagation of malware a real bitch in production. Not to mention if you are a big outfit and that happens people will start getting fired till it's fixed. I've been in a major company that got their email shut down by Cisco IronPort (Over half the vendors they dealt with were rejecting mail). Some yahoo in the data center thought it would be cool to run his own little server which got hacked and delivered out 9 tons of spam that shut down corporate email for 4 days till IronPort finally cleared it up.
Can you even imagine what would happen if one of those RBL systems blocked Yahoo by default a week or two ago? Shit storm indeed, but a needed one.
We don't have any of that.
What we *do* have is a clusterfuck of technology that developed from an interesting idea to effectively share a word processing screen at universities that is fundamentally toxic to us. We spend billions cleaning it, defending it, and developing it, etc.
It just needs to be scrapped and start over.
So no, blocking javascript is not the answer either. Unless you want to be left behind with non-working pages because people like me are getting really tired of needing to expend those resources for graceful failure. We don't have the time or the money to do that anymore (not in this economy) and javascript and JQuery (along with the other JS frameworks) are here to stay. So many of the "shiny" features out there only work in an event based framework where I can modify the DOM without reloading the entire page.
The whole mess is just terrible and we keep refactoring code to old email and document markup systems without addressing the underlying issues at all.