The Script Tag

[00:00:00]
>> [MUSIC]

[00:00:04]
>> 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:30]
JavaScript delivers source to the execution site and it was because of this problem. So one of the very first things they found when they started writing pages to take advantage of JavaScript was that when you display those pages on Navigator 1 and on Mosaic, the script would show up as text.

[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.

[00:01:33]
>> Douglas Crockford: Microsoft added a language attribute because they intended to kill off JScript and replace it with their own VBScript, VBScript being a dialect of Visual Basic. That didn't happen, and the irony is, the reason it didn't happen was because they did such a good job on JScript. If they'd done their usual thing, then JScript would not have gotten critical mass and JavaScript probably would have failed, and they had a chance to steal the market, but they didn't.

[00:02:07]
So as it turned out, JavaScript was the only language that ran reliably on all browsers, and so that was the language everybody used. The only people I've seen using VBScript are criminals and advertisers.
>> Speaker 2: [LAUGH]
>> Douglas Crockford: Everybody else is using JavaScript. They added the source attribute which was a really good idea cuz it turns out, you should not put script tags onto pages.

[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.

[00:03:18]
So the browsers are required to ignore it. W3C says it's required. I say leave it out, it's not necessary. It's just a waste of space. So, document.write is I hope the worst idea Brendan Eich ever has. The way he thought that interaction with the browser was going to work was that JavaScript would run as the page is being loaded incrementally.

[00:03:51]
And that JavaScript, as it's running, can insert new HTML text into the document as it's being parsed. Which was kind of awful. So I don't see it being used very much anymore except by criminals and advertisers, okay?
>> 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.