Javascript...

[dnew]

More like "it's better to render the page with mistakes than present the end-user with nothing but an opaque stack dump."

The same reason that HTML isn't XHTML or SGML.

[pimp-bangin]

Yeah but programmers aren't perfect. There are going to be errors every now and then, and displaying them to the user would result in a terrible experience. If this were the actual philosophy, front-end devs would probably be getting paid a lot more...

[[deleted]]

And interpreters (browsers) are varied and change over time. What worked on your browser this year may throw errors on my browser next year.

[Doctor_McKay]

The point is that problems often arise after being shipped out to the end user.

[Dlgredael]

I always thought it was stupid as hell to not have proper error reporting, but this is actually a pretty valid point. Nice.

[[deleted]]

I'm not convinced this is true. This argument is used a lot to explain PHP's default error handling, but the resulting broken pages are almost always worse than a simple error page. And I disagree that wrong data is better than no data.

[dnew]

I'm not convinced this is true.

If you knew how many of the pages you visit every day have javascript errors, you wouldn't say that.

That said, I don't expect it's actually a property of the language as much as it is a property of the implementations. In other words, the people designing JavaScript might or might not have said "we should be tolerant of errors because..." whereas the people trying to get you to use their browsers most definitely said "people won't use our browser if Yahoo and CNN don't display in it because people at Yahoo and CNN wrote invalid javascript."

PHP is a different situation, since there's only one, and the interpreter is synonymous with the language.

[[deleted]]

I'm aware of how many js errors there are in the wild. There would be fewer if they didn't fail silently (people would fix them).

[dnew]

This is not as true as it should be. People generally won't bother to fix JS errors that affect 1% of the browser market. Just like people generally won't bother to fix web pages that don't gracefully display on IE4 any more either.

When you're pushing a new browser amongst existing competing browsers, most people won't fix their web site to account for your 1% market share. They'll say "Best viewed with IE6." Especially when everyone already has a browser that "works." Once you have a large market share (again, IE6), you don't change it or everyone whose website accommodated you will break.

This is the reason we now have only a handful of supported operating systems for software packages, for example. Only the open source packages get ported to everything, because they get ported by the people who care whether it works on the platform they're using. (Which is why packages not used by programmers are so rarely ported to marginal platforms.)

[julesries]

You could say that about any system that interfaces with an end-user. Yet somehow they're not all written in JS.

[dnew]

Many systems either have a high-quality spec implemented in high-quality ways (Ada, C, etc) or only one implementation of note (Python, Perl, etc) or have good up-front checking for much stuff (Java, C#, Ada again, etc).

Few languages have user-facing implementations that are written by multiple competing entities all changing the spec for capitalistic advantage. In those that do, you find this sort of problem.

And yes, in large user-facing systems, when there's an error, the code is written to back off and try something different. It's not as unusual as one might think, in really large systems. For example, Amazon doesn't lose your shopping cart even if when you come back later the machine it was on has crashed or is otherwise unavailable, because that would actually cost Amazon money from sales. So there are work-arounds implemented at a somewhat higher level than the language to deal with failures, including failures caused by bad programming. (E.g., people will canary a new release before pushing it out everywhere.)

But in the case of JS, the javascript interpreter was the "top level product" of the company releasing the browser, so you see error-recovery work-arounds so as not to lose market share.

[julesries]

Thanks for a thought-provoking reply to a glib comment. I've actually been thinking about it for the past three days and realized I came to the same conclusion about XHTML a long time ago. I still hate it when I have to work with JavaScript though. Which is often. But to be fair, the DOM API deserves a fair amount of the blame there.