The Changelog: Software Development, Open Source - JSON and JavaScript (Interview)

Episode Date: June 8, 2010

While at TXJS — Adam and Wynn caught up with Douglas Crockford, author of both JavaScript: The Good Parts and the JSON spec, and a global namespace unto himself.

This is John Resnick, you're listening to The Change Log. Welcome to The Change Log, episode 0.2.6. I'm Adam Stachowiak. And I'm Winn Netherland. This is The Change Log. We cover what's fresh and new in the world of open source. If you found us on iTunes, we're also on the web at thechangelog.2.6. I'm Adam Stachowiak. And I'm Winn Netherland. This is The Change Log. We cover what's fresh and new in the world of open source. If you found us on iTunes, we're also on the web at thechangelog.com. We're also up on GitHub. If you go there, you'll find some trendy repos, some feature repos from our blog, as well as our audio podcast.

If you're on Twitter, follow changelogshow. And I am Adam Stack. And I am Penguin. P-E-N-G-W-Y-N-N. Such a fun time in Austin at Texas JavaScript this weekend. Got to interview one of our idols, Douglas Crockford. Yeah, he's probably more of your idol than my idol, but definitely a high up on me. He's the man when it comes to JavaScript, the author of the Jason Speck,

JavaScript the Good Parts, seems to be the rock star of the JavaScript community. Yeah, he seemed to have a very biased opinion against what's going on with HTML5, too. Yeah, I know. Called for HTML5 to be reset, as he saw it, and focus on less of the whiz-bang features and more on cross-site scripting, which he saw as the more pressing need.

Yeah, he put a real big emphasis on that with his talk. He also had the slide, IE6 must die. I think, yeah, and then John Resig stood up and said, hey, what about IE7? I think we'll take what we can get right now. His tagline was and we must kill it.

We must kill it, exactly. We must kill it. That's right. Speaking of Resig, he's going to be we also chatted with him about some mobile web development with jQuery. He'll be in a future episode. Excited about that. Speaking of future episodes, he's going to be, we also chatted with him about some mobile web development with jQuery. He'll be in a future episode. Excited about that. Speaking of future episodes, we've got some Skunk Works news that we just can't share quite yet, but we're excited about it.

And if we've slowed down on the blog, I guess that's why. Yeah, we're definitely doing some cool stuff. So just be patient, sit tight, and we'll impress, I'm sure. As will this interview. Should we get to it? Let's do it. Hi, we're joined today by Douglas Crockford from, I guess, Yahoo. Author of JavaScript, The Good Parts.

Also the JSON spec. Douglas, why don't you introduce yourself and for the three people out there that may not know who you are. I thought you did just fine. Let's go on. All righty. So the story of Jason, the Jason saga. Just got your session here at Texas JavaScript. Give folks the Reader's Digest version of that talk

about how the Jason spec came about and what problem you're trying to solve. I was in a startup in 2001 that was trying to do what we now call AJAX applications. We needed an efficient way of exchanging data between the browser and our servers.

I had an epiphany that we could use JavaScript object literals to do that. That was the creation of the JSON notation. We tried to convince our customers that it was a good idea. And they basically said, no, they couldn't use it because it wasn't a standard. So I declared that it was a standard. And since then, it's taken off and become one of the most popular data interchange formats. Probably succeeding because of its simplicity.

Yeah, simplicity, minimalism was an essential part of its design. The theory being that the less we need to agree on in order to interoperate, the more likely it will successfully interoperate. And so the specification is really, really simple. And because of that, one of the promises of JSON is that it perhaps won't change? It'll just become obsoleted? JSON can't change. There's no version number on it.

So there's no way to declare JSON 2, for example, in a compatible way. So JSON will always be JSON. And that limits it to an extent, but it also makes it more stable. It means there's one part of the stack that you can guarantee is not going to ever break on you, and that's going to be JSON. JSON is stable. JSON spec itself is somewhat stable, but a lot of activity happening around the language. Talk a bit about JSON parse, JSON stringify,

some of these new approaches that are finding themselves into the browser. So support for JSON is now built directly into JavaScript, so you don't need libraries anymore. So JSON.Pyerson, JSON.Stringify are standard equipment. They're very fast, they're very secure, very reliable. You mentioned in the talk a bit about YAML. Was YAML an influence of JSON at all? No, I was unaware of YAML when I was doing the JSON work. I ran into the YAML guys later,

and we sort of discovered that we almost had a subset-superset relationship. And very often when you see standards like that that are kind of similar, they will try to grow apart. And we did the opposite thing. We tried to bring them together. You mentioned in the talk also about how JavaScript using JSON is excellent for state machines. Can you expand on that a little bit? No, just JavaScript by itself is excellent for state machines.

Because you can put functions into your state transition tables, you can come up with really, really efficient state machines. What sort of applications are you building with JavaScript and JSON these days? I'm actually not doing a lot of JSON stuff myself right now. I'm working on trying to fix the browser. We've got some really serious security problems that are not being addressed by the OPC. And we just had a crash here at Texas JavaScript, if you heard that. In your talk, you had some pretty strong opinions, since we're talking about the browser, about HTML5 and that it needs to reset. Can you talk about that a little bit? Yeah, so the browser has one of the best security models

of any application delivery system in the world. But it's not good enough to do the applications that we need to do. And one of the symptoms of that is known as the cross-site scripting problem, where if third-party code gets onto a page, it can do terrible things. And there are a number of causes for that problem. Some are in HTML, some are in JavaScript, some are in the DOM. We need to fix it. It's the biggest problem facing web developers and sites that use the web.

And it's been with us for 14 years, and the standards community has not fixed it yet. So I'm demanding that we change the priority on HTML5 to get security right first before we do anything else. Just for brevity's sake, what exactly is cross-site scripting, and what is it? It's a confusion of interests attack. So if third-party code can get onto a page,

for example, through user-generated content, that script can do anything that the site's own script can do. The browser cannot distinguish between the interests of guest code and its own code. So that will give you the right to read the document, to change the document, to dialogue with the user, to ask things of the user as though you are representing the site, but you're not. It gives you the right to communicate with the site and its servers and its databases.

So the security problems are huge. And fortunately, we know how to fix them. There was work done at Google on Kaha and my own work on AdSafe, which show us how to do secure cooperative applications in a browser context. And we've put a lot of the knowledge that we've demonstrated in those systems into ECMAScript 5 and more into the next edition. But that has not gotten into HTML. The HTML5 community is going, in my view, the wrong direction.

And they're making the system significantly more complicated and making things significantly worse from a security perspective. And so while many of the things that they're talking about are nice and useful, we need to get the fundamentals right first. So what are you suggesting happen to HTML5? I'm proposing that we reset it, that we toss it out and start over with a new charter, which is to solve the security problems in as short a time as possible. Once we've done that, then we can go back to the pile of stuff that HTML5 was proposing,

but review each of those features in the context of the new security model, and the stuff that can be made to conform to the new model, then we'll add. If we didn't have the kind of the graying meaning of XSS, that acronym in our brains now, with the proper security model, cross-site scripting is actually a good thing. It's an essential thing. It's mashups. So we want to be able to have code representing multiple sites

interacting on the same page. We're working really hard now to make that happen. The problem is that the browser did not anticipate that. And so it's not possible for each of those modules to defend themselves from the others, or for the page to defend itself against the modules, or for the modules to defend themselves against the page. In order to do that, which is essential and valuable, we need to fix the browser.

So one of the techniques that we use today is JSONP or JSON with padding. How did that come about? Jason P. was not mine. It was the observation that the same origin policy prevents getting data from another server, but doesn't prevent getting script from another server, which, when you think about it... Crazy. Yeah, it's crazy, absolutely crazy. But it's a workaround, okay?

So if you load data as script, you can get around the same origin policy, which is really nice, except it comes in as script, not can get around the same origin policy, which is really nice. Except it comes in as script, not as data. So anything that it wants to do, it can do. And there's no way that the page can defend itself against JSONP delivery. So it's an extremely dangerous practice. But the browser doesn't present us many good opportunities.

I noticed that in the last talk you mentioned the logo for JSON and how you designed that, and it's an incredibly creative logo. JSON is the kind of lingua franca for APIs now, and Adam and I are starting a new podcast to cover APIs, and the working title is JSON-FM. I wanted to know if you would bless that. Sure, that's fine. So I intentionally in JSON put no IP protection on it.

So the Jason name is not trademarked. The Jason logo is not trademarked. So everybody is free to use it however they like. You did mention it's MIT, except you can't use it for evil. No, the reference implementation has an MIT license on it with the added provision that it must be used for good, not evil. Gotcha. I don't think we will fall into that scenario with this particular project. Usually part of the show we ask our guests, what's on your open source radar? I know that JavaScript is a big part of your world.

What else that's open source has you excited that you really want to play with? My concern about open source is that we're seeing more and more competition against the browser. The browser platform is basically 10 or 15 years old now, has not aged well. There are lots of much more modern systems that are attacking it. The browser will always be lagging behind because it's based on web standards, and standards have to be slow in their development. It's just an absolute requirement. But it's fallen way far behind.

So part of the energy behind HTML5 is trying to catch up, which is commendable. But as currently practiced, it's misguided. So you see this cycle that we're in between native and browser-based applications seems to be like, you know, pant-style fashion. It comes and it goes. Are we just on another ebb, or do you see it? Well, the thing that the browser got right is that its security model, even though I've been saying bad things about it, is actually better than everything else. All of the other application delivery systems don't even distinguish between the interests of the user and the interests of the program. The browser at least doesn't make that mistake. So ultimately, I think the security,

reliability, integrity of applications is going to be more important than their whizziness. And that's why I think the web is worth saving. One last question for you, and a comment first. I really enjoy your talks on how you give the history behind certain specs and things. For young guys like Adam and myself, how much lacking are we in our history, our roots as programmers? I'd say it's pretty tragic. There's so much history in our profession, and it shocks me sometimes how little intellectual curiosity some of the practitioners of this craft have about the stuff that they do.

You know, where did it come from? Why do we do things the way they do? Sometimes we do things for good reasons. Sometimes we don't. And you can get a big leg up by understanding the difference. I like the way the first semester of physics is usually taught, as history, as biography. You know, this is what Galileo did.

This is what Newton did. This is what Copernicus did. You know, that's great. We don't do that for computer science, and I think we should. Thanks for joining us today. Thank you. Thank you for listening to this edition of The Change Log. Point your browser to tail.thechangelog.com

to find out what's going on right now in open source. Also be sure to head to github.com forward slash explore to catch up on trending and feature repos as well as the latest episodes of The Change Log. Safe in your arms As a dark passion shown Was mine alone

I'm back I'm back All roads to track Bring it back Bring it back to I'm back Outro Music