The problem with JavaScript is, somewhat paradoxically, too much flexibility. There are no standard language features for very basic things like namespaces and modules, also what it provides for OOP is so confusing that it makes people want to roll their own OO system from scratch. Objects as dictionaries and first-class functions make it possible to implement those features in hundreds of ways and almost every JavaScript program tends at least in some places to use some own, original solution for one of the very basic problems of structuring programs, because it is so easy to built one. It is good that this is possible, it is bad that people _have to_ do this (or choose one of the countless existing solutions) before they can actually write the program they want to write.
A lot of the problems would go away if the following was part of the language and present in every browser:
* namespaces/modules
* a sensible OO system people would actually enjoy using
* the ability to require/import/include a file/module
* the functionality Underscore.js provides
Then, at least the basic structure of the code would be consistent across programs from various people, and I wouldn't have to work out the details of yet another OO system, yet another way of just laying out the code across functions/objects each time I want to read another JavaScript program or yet another way of doing function () {}.bind that works across the browsers (here the problem is also the long time it takes for the majority of people to install a browser new enough to adopt the revised standards). And it's not only about reading code, how do you write an object-oriented refactoring tool if every program realizes OO in its own distinct way?
The situation is probably slightly better with server side JS where you are free to adapt the newest version of the language/runtime and also the server-side frameworks at least to some extend tend to encourage to use a common structure for all the modules.
Your 4 points are exactly why I always use Require.js, Backbone, and Underscore in all my large projects.
Require.js solves point #1 and point #3.
Backbone solves point #2.
Underscore solves, well, point #4.
In my experience, the other important thing to maintain coherence and sanity while creating large JS apps is to have a system that makes dependencies between modules very, very clear. Require.js basically also does that for me; it requires every module to define their dependency on other modules on top of its file.
I highly recommend people creating large JS apps to at least check it out : http://requirejs.org/
Let me explain to you the two large projects that I'm currently working on that are both using Require.js (it's hard to explain one without the other):
The first is basically a web framework that lets you compose a fully working website from a whole slew of independent, pre-built, unique components. Each component is made of Require.js modules (like its own HTML, CSS, JS). This isn't exactly the largest project, but Require.js really comes in handy with its ability to conditionally load modules (or components, in this context.) because you simply won't use all the components in the system, and also its ability to treat pure text file as regular modules (for HTML and CSS part of the components).
The second is a visual drag-and-drop web builder that lets you visually build a working end product of the first project that I mentioned. This is a large project simply because there's usually quite a lot of that you have to do in order to make a completely visual system work. I simply can't imagine building this system without explicit module dependency that require.js enables.
I think a better starting point is defining how large does something need to be to be significant. Otherwise we are nothing better than the guy in the back of the room shouting "Does it scale?", which given the amount of context in the question renders it impossible to answer.
The ability to enforce and optimize modular Javascript is one of the primary benefits of Google Closure Compiler, I've seen. I've only used it for one project so far but I can't envision writing another Javascript project without it.
A lot of the problems would go away if the following was part of the language and present in every browser:
* namespaces/modules
* a sensible OO system people would actually enjoy using
* the ability to require/import/include a file/module
* the functionality Underscore.js provides
Then, at least the basic structure of the code would be consistent across programs from various people, and I wouldn't have to work out the details of yet another OO system, yet another way of just laying out the code across functions/objects each time I want to read another JavaScript program or yet another way of doing function () {}.bind that works across the browsers (here the problem is also the long time it takes for the majority of people to install a browser new enough to adopt the revised standards). And it's not only about reading code, how do you write an object-oriented refactoring tool if every program realizes OO in its own distinct way?
The situation is probably slightly better with server side JS where you are free to adapt the newest version of the language/runtime and also the server-side frameworks at least to some extend tend to encourage to use a common structure for all the modules.