I think it was a reasonable decision at the time. The idea was that JavaScript was not going to be some language people wrote hundreds of thousands of lines of code in, and that the target audience would become frustrated if the language didn't "help" them. For example, if JavaScript truly were to always require semicolons at the end of lines then that means this would be a syntax error:
<a onClick = "someFunc()" > ...
> Error, missing semicolon after ")" on line 1
That could get pretty annoying pretty fast, and simple little event handlers like these were probably the main use of JavaScript for the first x years. It also matched the existing philosophy of HTML which was to really go out of its way to make sense of whatever was in the file.
Now of course, the constraints are different: people want to use JavaScript for huge codebases and serious projects, so it makes sense that these decisions are no longer appropriate.
<a onClick = "someFunc()" > ...
> Error, missing semicolon after ")" on line 1
That could get pretty annoying pretty fast, and simple little event handlers like these were probably the main use of JavaScript for the first x years. It also matched the existing philosophy of HTML which was to really go out of its way to make sense of whatever was in the file.
Now of course, the constraints are different: people want to use JavaScript for huge codebases and serious projects, so it makes sense that these decisions are no longer appropriate.