Division of Labor

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

[00:00:03]
>> Douglas Crockford: Finally, one more thing about living in the browser is a problem of division in labor. Cuz we're now doing client server programming, and for some people working in the browser this is the first time to be doing client server programming. And that means you're writing distributed application where half of the application is running in one machine and half of the applications running in another machine.

[00:00:25]
How do you divide the work, how you decide what goes in which machine? And I've seen people make mistakes in every possible dimension. For example, early on in the web everything was in the server. The browser was treated as a terminal, specifically as an IBM 3270 terminal. And you would send information to the server, and the server would generate a new view and send it out.

[00:00:52]
And that was hugely inefficient, and it was recognition of that inefficiency which got the Ajax thing so popular. So when Ajax started, it went the other way. People started putting the entire application in the browser and they were treating the server as a file system. And I saw people trying to basically replicate their database in the browser.

[00:01:15]
They'd say take everything we got cuz who knows if we need it or not, and they'd send everything over. And then they'd complain well, why does it takes so long to send all that data? That turns out not to be a good way to do it either. So what's the right way?

[00:01:30]
It's to seek the middle way. That you want to create a pleasant dialog between specialized peers, you want to minimize the volume of traffic, you want to be sending stuff on a just in time basis. You don't need to send the browser everything it might ever need to know, you just need to send it what it needs next.

[00:01:47]
And that's usually a much smaller set of data, something you can send very, very quickly, particularly as our networks have gotten so performant.
>> Douglas Crockford: And that's the end of the browser. Any questions about that? Yeah.
>> Speaker 2: I'm just curious what your thoughts are, kind of the virtual DOM approach, like diffing, and I don't know if you have any opinions, or.

[00:02:14]
>> Douglas Crockford: Yeah, I got opinions, I don't know if they're useful opinions. So generally the DOM is a horrible model. And propagating that horribleness onto the other side of the network, I think just keeps you stuck in that awful model for longer. I'm hoping someday we figure out a way to liberate ourselves from the DOM, cuz it really is dreadful.

[00:02:36]
And the thing that's encouraging to me about the library is that they provide a way of doing that. That, for example, jQuery is so much superior as an API for addressing graphical elements on a page to what the DOM provides. I'd like to see us get better in that dimension.

[00:02:55]
>> Speaker 3: Is the jQuery just a wrapper around the DOM?
>> Douglas Crockford: It is.
>> Speaker 3: Okay.
>> Douglas Crockford: But it turns out you don't need much wrappage to make the DOM significantly better. The DOM is so horrible, I recommend don't use anything that I've showed you in the last hour, don't use anything.

[00:03:09]
>> Speaker 3: Don't use getElementById ever, just use jQuery?
>> Douglas Crockford: Find some library, I'm not recommending jQuery necessarily.
>> Speaker 3: Okay.
>> Douglas Crockford: But some library, every library is better than the DOM, I'm happy to say that. Even, I don't know what the worst library out there is, but whatever it is, it can't be half as bad as the DOM is.

[00:03:29]
>> Speaker 3: How can, if jQuery just calls getElementById, how can using a jQuery CSS be better than get on.
>> Douglas Crockford: It's hiding that stuff for you, it's adding a level of abstraction. It's adding enough in direction so you're not thinking in terms of what the DOM does, you're thinking more in terms of what you need to do.

[00:03:49]
>> Speaker 3: Okay.
>> Douglas Crockford: And it's very effective at that. A lot of other libraries are too.
>> Speaker 3: Okay so, other question. I kind of thought that the DOM was the browser. How'd the browser work without a DOM? Because you said there was HTML, and then right around the same time that HTML was going from all caps to lowercase, the DOM was invented.

[00:04:11]
How would you have a browser without a DOM?
>> Douglas Crockford: Before there was JavaScript there was no need for a DOM, right?
>> Speaker 3: There was no modeling of the DOM, but the DOM existed in some-
>> Douglas Crockford: The browser had a tree, but it had no API for the to get access to that tree.

[00:04:33]
>> Speaker 3: Okay, all right.
>> Douglas Crockford: Yes?
>> Speaker 4: I guess listening to just the history of everything, and it might not be a question. But what, everything is funneled into what it is right now. And it seems like things are pretty stably moving in a very succinct way. And then when I listen to your stories of how this came from this, and this came from this, and all these languages came from all of these other languages.

[00:05:08]
Do you have an opinion or an answer to why such a minute, how come everything is focused so much? How come there isn’t so much of this development of these different ideas? When you were saying the idea of having a, returning a function took years to figure that out.

[00:05:35]
Why, is that still going on, and what's going on with that, why the slowdown?
>> Douglas Crockford: It has always been slow, we'll talk about this on the third day. We think of ourselves as being the most innovative of industries, and maybe we are. But we're also humans and humans tend to be extremely change averse.

[00:06:03]
And the people who are the last to recognize the value of a new technology are often the people who would most benefit from it. And there are lots of examples of that in software technology and then we will look at those.