Transcript from the "The Script Tag" Lesson
>> Douglas Crockford: Brendan invented the script tag because he had the problem, where do you put the scripts that go on the page? And since HTML was a text format, he decided to deliver the programs to the browser in text form.
>> Douglas Crockford: Which is unusual because most languages will deliver an executable to the execution site.
[00:00:53] And that was because of the HTML rule, if you see a tag and you don't recognize it, just keep going. And that was hugely embarrassing. And there is no way they could go back in time and tell those older browsers not to do that, so they came up with this terrible hack.
[00:01:11] They wrapped the script in HTML comments. And as long as you're not using a minus minus, then the script will be hidden and no one will see it. I still see people doing that. So if you see anybody doing that, tell them this hasn't been necessary since 1996, so knock it off.
>> Speaker 2: [LAUGH]
[00:02:34] If if you put scripts into separate files, then they can be minified, they can be gzipped, they can be cached. All of which are extremely good for page startup performance, which is critical. If you put them on the page, you don't get any of those benefits. So everything should be in separate files.
[00:02:55] Then finally W3C didn't like the language attribute because they didn't make it up. So they replaced it with their own thing and they say that it's required. But it turns out, if you're using a source attribute, and you should, it is the server that is authoritative on what the MIME type of the asset is, not the tag that requested it.
>> Speaker 2: [LAUGH]
>> Douglas Crockford: I see advertisers use this a lot. In the early days of web advertising, there was a huge amount of fraud.
[00:04:17] All the ad companies were ripping each other off. Misreporting image views and other things. So they came up with this agreement that the way an ad placement can work is you put some ad script on your page. It will do a document.write of a script tag going to an ad server.
[00:04:42] And that one will then return code which will do a document.write of a script tag going to another server. And they can do several of those things, going off to different places and it allows all of these different companies or agencies to separately count the thing. So they can all agree on what actually happened.
[00:05:01] But one of the consequences of that is they can add huge delays to the rendering of the page. Because everything has to wait until all those ad redirections get finished, and it's also a huge security vulnerability. Because any of those servers can be sending anything they want. And if they send something nasty, bad things happen and there's no way to defend against it.
[00:05:24] So that's all pretty awful. So I don't recommend anybody use it ever again. So unfortunately where you put a script tag on a page can have a huge impact on the page loading time. The correct place to put script tags should be in the head. Because it's meta, right?
[00:05:47] Scripts are not content, they're meta. So that's what the head is for. Unfortunately, browsers are extremely incompetent at script loading. And so if you put scripts in the head, then all parsing blocks until the scripts load, compile, and execute. Which means that if there are any images in the body that need to get loaded, they don't even start to load until all the scripts are finished.
[00:06:13] That's not good. So Steve Souders figured out that we need to move all the scripts to the bottom of the body instead. Which is great for performance but terrible for reliability, but that's what we do now. He also recommended that we minify and gzip the script files, which is very good advice.
[00:06:33] He also recommended that we reduce the number of script files as much as possible by concatenating them all together. And they're really good reasons to recommend that because HTTP is incredibly incompetent at loading script files. And so the serial delays in HTML request transactions really hurt you badly there.
[00:06:54] So Souders recommended that you can count meet all of your script files together, and turn them into one big file and that way you avoid some of that HTTP overhead. Unfortunately, that leads to other problems. It completely breaks caching because every page will have a different combinatorial set of scripts it's gonna load.
[00:07:15] So the likelihood that one combined script file is gonna be reused again is extremely low. It also introduces bugs because there are certain errors that can happen, which are not correctable if you put lots of files together. For example, you might have one file that's written by an incompetent idiot who depends on semicolon insertion and that's concatenated onto someone else's file.
[00:07:42] And the place where the semicolon would be inserted is no longer an insertion site because of the concatenation and now the file fails.