Brendan Eich Explains ECMAScript 3.1 To Developers

VonGuard writes "On April 9, ECMA International produced the final draft for the first major update to JavaScript since 1999. It's called ECMAScript 3.1, but will soon be known as ECMAScript, Fifth Edition. You'll know it as JavaScript, the Next Generation. Mozilla will begin implementing these features after Firefox 3.5, and Microsoft is already showing prototypes behind closed doors. The question, however, is what this will change for JavaScript coders. To get those answers, I tracked down Brendan Eich, Mozilla's CTO and the creator of JavaScript. I transcribed the interview without any editorial since he explains, perfectly, what's changing for programmers. Long story short: Json will be safer, getters and setters will be standard, and strict mode will make things easier to debug."

Sweet!

[coryking]

First, JavaScript is a very nice language indeed. If you've never learned functional programming, JavaScript is a good language to learn in. Why? You can actually do real work while learning! As for the new language spec...

Getters and setters are nice, but I'm not sure they serve a purpose in javascript--javascript is more functional than it is OO and I think people learning the language should change mindsets rather than the langage get bastardized to something it is not. I dunno, somebody can challenge me on this.

Good to see they are thinking about adding a "use strict". You aren't an adult language until you have a way to force variable declaration. Hopefully "use strict" will apply to a module or block, not to the entire project. I want to "strictify" my own JavaScript, but I dont want the browser to choke on some sloppy copy-and-paste deal from AdSense or analytics.

Lastly, JSON. There are a couple "gotchas" with it... namely when you generate JSON using a loosely typed language like Perl and try to feed it into a strongly typed language like C# (i.e. silverlight). Depending on the serializer [codeplex.com] / deserializer [microsoft.com] used on the strongly-typed side, you'll run into things.

For example, the deserializer in C# just might choke on this:
"themes": [ // it will puke on this:
        {
                "theme_id": "34", // i am a string!
                "last_mod": "2009-04-09 13:04:27.232-07" // I am a postgresql date, but I'd also barf on ISO8601
        }, // puke free:
        {
                "theme_id": 34, // I am an int!
                "last_mod": new Date(3000, 00, 01, 00, 00, 00) // i am a legit Date()
        }

]

Why? Perl serialized [cpan.org] the integers as a string. Depending on the deseralizer, it might choke on those strings if it was expecting a number. YUI would also be pissed off about the date not being a javascript Date()--good luck finding a serializer that produces such a thing! My point? These are some surprise gotchas you have to worry about when dealing with JSON. Not sure who is to "blame"--perl for being loosely typed, the deserializers for being to strict. This would be a problem with XML as well though.

Re:Json vs. XML

[radtea]

Json has dethroned XML for pure data interchange

I wish I could figure out why this is so, given that XML was already a standard when JSON was invented, and is widely supported and just as compact. Here's an example of a JSON specification:

{
        "name": "Jack (\"Bee\") Nimble",
        "format": {
                "type": "rect",
                "width": 1920,
                "height": 1080,
                "interlace": false,
                "frame rate": 24
        }
}

And here's exactly the same thing in XML:

<o name="Jack (&quot;Bee&quot;) Nimble">
<format type="rect" width="1920" height="1080" interlace="false" frame_rate="24"/>
</o>

The XML is 129 characters, the JSON is 142 characters (counting each white-space sequence as just one character in both cases.)

So JSON is fatter than XML and less standardized, or was when it was invented. There is a minor impact on the naming because XML names can't have spaces in them, but this seems to me insufficient to justify the invention of an entirely new language when a simple XML specification would have worked just as well.

I've looked at this question a couple of times, and never been able to find any argument other than "Badly written XML can be incredibly bloated compared to JSON" but this seems to me entirely inadequate. I'd really like to be enlightened regarding alternative justifications for JSON.