I just ran a few of my longer files through jslint.com and it looked like all the errors were related to me using two spaces for indentation instead of four, and some missing semicolons. But I don't know what sort of errors I should be expecting?

If you're working on a project with just a few people and on the first version, you'd probably not see many of these problems. But imagine your project grows, you keep modifying the code, and often times you'd make typing mistakes..

Let's say originally you have this.

  // Run node to the end
  for (; node.next != null; node = node.next);
  doSomethingElse();

After a few months of team work on the same code, one day, somebody got careless with the "x" key in vim and deleted the semicolon after the for.

  // Run node to the end
  for (; node.next != null; node = node.next)
  doSomethingElse();

And your web page still works! It's just become mysteriously very slow, sometimes. Must be caused by the latest Chrome update.

There're lots of other ways for a pile of JavaScript code to accumulate bugs like this over time without a strict standard in place to lint everything. e.g. people forgetting to add "var" before variable declaration because they've been writing Python as well, causing namespace leaks that DON'T seem to break anything at first.

If you team has a standard practice to always lint everything, always do data binding in a certain way, never modify the DOM directly (combined with the proper libraries), etc. Then, yea, maybe you can scale up your team and the code size without always fixing funny bugs that pop up only after the original mistake was made 6 months ago.

But, standardized development practice with JavaScript? hmm.... how many hotshot frameworks and major updates to hotshot frameworks have we seen in the past 2 years? Compared to that, people using inheritance carelessly is just a minor problem.

> After a few months of team work on the same code, one day, somebody got careless with the "x" key in vim and deleted the semicolon after the for.

Not to detract from the subject at hand because you do have a point, but that sort of error is caught by patch reviews. Even on my own projects I review diffs before/after I commit them.