I agree that it's a bad tool in many ways, but even if the language (and environments) were beautiful, the problem at hand is often the way that people use it.
In this case, a poor craftsman uses his tools to do the things that the browser already does for you.
I've seen some JS that reinvents lots of what the browser rendering engine should handle (recalculating & reflowing heights of elements every time something was added or subtracted from the DOM, for example). Expand this kind of thinking to an entire project, and you start to find yourself in the kind of mess described in the slides.
If/when Dart replaces JS, some of the enforced structure may help prevent badly organized or buggy code, but it won't fix poor assumptions of what concerns scripting should and should not handle.
In this case, a poor craftsman uses his tools to do the things that the browser already does for you.
I've seen some JS that reinvents lots of what the browser rendering engine should handle (recalculating & reflowing heights of elements every time something was added or subtracted from the DOM, for example). Expand this kind of thinking to an entire project, and you start to find yourself in the kind of mess described in the slides.
If/when Dart replaces JS, some of the enforced structure may help prevent badly organized or buggy code, but it won't fix poor assumptions of what concerns scripting should and should not handle.