[johnnygood]

I came here to post that too. The only thing I can think that means is that it is laid out better for large teams to program on without stepping on each other's toes. Sort of like a Java argument against dynamic languages - those cool scripting languages are fun and productive for an individual, but large teams would just screw each other up with that.

There really isn't "scalability" in client-side JavaScript. Scalability is usually thought of as the ability to serve many users at once (as opposed to speed which is how fast you serve one person). So, sure Ruby is slower than Python, but it doesn't matter too much since you can have 4 web servers and a load balancer rather than 2 web servers and a load balancer and you're fine.

However, client-side JavaScript isn't serving multiple users at once. It's trying to serve one user as fast as possible.

Maybe someone has a better explanation? It's early and I haven't had my coffee.

EDIT: It seems like YUI might allow you to pull independent pieces by calling YUI.use(some-cool-piece-of-functionality). That could reduce download times, but it could also increase HTTP requests and the associated overhead. That's pretty cool. If 90% of your users aren't going to be using a piece of functionality, it doesn't load that code, but can load it dynamically if needed. While cool, I don't think I'd call this more scalable - this is about speed. And I don't know if it would be faster in a meaningful way since JS can be nicely cached. I shouldn't have said that - in the absence of evidence from testing, I shouldn't make assumptions. Maybe someone else can shed some light on how well this works in the real world.