Check out a free preview of the full The Good Parts of JavaScript and the Web course

The "A Better JavaScript" Lesson is part of the full, The Good Parts of JavaScript and the Web course featured in this preview video. Here's what you'd learn in this lesson:

Doug talks about the history of ECMAScript and recommends working in ES5/Strict. He also explains what the goals for ES5 were and how they wanted to improve the language for the users of the language.


Transcript from the "A Better JavaScript" Lesson

>> [MUSIC]

>> Douglas Crockford: ECMAScript 5, The New Parts. So complete implementations of the fifth edition are now in all the best web browsers, and also in IE10. So, it's almost everywhere. So again, to review the history of the standards, the third edition was ratified in December 1999. Work on the fourth editions started almost a year before that.

The fourth edition was attempting to solve some problems that I think were unnecessary. And eventually, it got so big and so complicated that it was not completable. That project slipped a year per year for ten years. So it was eventually abandoned and instead, we did the fifth Edition which started with a working title ES3.1, indicating that it was going to be a much less ambitious attempt at adding goodness to the third edition and it adds two languages or describes two languages.

The default language and the strict language. And of the two, I recommend not using the default language, but using the strict language exclusively and we'll talk later about what's in the strict language. So, that the goal of the ECMAScript 5 project was to make a better JavaScript. There are a lot of people who wanted us to not make a better JavaScript, but to make a different language and there's certainly good arguments for doing that, but I think standardization is not the correct place to try to do that.

So instead of trying to do a big thing, we tried to do a lot of little things. We tried to make the standard conform better to reality. There are some cases where the standard said, implementations must do this and none of the implementations did that. So we said, okay, well, the standards obviously wrong.

We should make the standard conform to what people actually do. We should try to make the browsers conform better to each other. There are cases where three browser makers would do things one way and Microsoft would do things another way. Microsoft very generously agreed to do what everybody else was doing, that was a very nice thing.

In cases where all of the browsers disagreed, where every browser did something different, we took that as license to fix something deep in the standard. That we assume that the web doesn't care, if every browser does something different. In that case, we can go in and do deeper changes.

As a result of all of this work, interoperability is improved. JavaScript was already very good at write once run everywhere. With ES5, it gets even better. So our number one goal for ES5 was don't break the web and that's a really difficult goal to keep, because any time you change anything, something will break.

And we did break some stuff with ES5, but we tried really hard not to. Now you could argue as I did, there is a lot of stuff out there, which deserves to break, but we tried not to break even that stuff. We wanted to improve the language for the users of the language.

Most of the critics of JavaScript are people who do not use the language and would not use it even if we did everything they told us to. So we tried not to listen to them too much, not always successfully. We tried instead to listen to you. We paid a lot of attention to third party security or mash ups.

We want to make it possible for you to add someone else's code to your page and have it not violate your security or your customer's security. We decided not to try to protect stupid people from themselves, because that is just too hard. So we, in fact, added new ways that stupid people can do outrageously stupid things and we'll get to that little bit later.

And we decided to have no new syntax and the reason for that is that at the time that we were doing this work, IE6 was still the dominant browser. And our concern was that if we launched a new version of the language and if IE6 is still dominant, then if the value of that new language depended on syntax and it's going to fail, because every new feature means total failure and that's not helping you at all.

So, we tried to add as much value to the language as we could without changing the syntax of the language. Hoping that eventually we would solve the IE problem and then later editions of the language would be able to be freer with syntax.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now