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

Comments

I'm going to call it Javascript

[Anonymous Coward]

Even if it continues to cause confusion with "Java", I'm not going to call it ECMAScript because it sounds like a skin disease Eczema script

What's the catch?

[plover]

With Microsoft cooperating to improve the language, now we can move on beyond the fifth edition, toward ECMAScript harmony.

Microsoft? Cooperating? Whatever happened to Embrace, Extend, and Extinguish? How can we keep hating on Microsoft if they're going to cooperate?

Re:What's the catch?

[Rik Sweeney]

With Microsoft cooperating to improve the language, now we can move on beyond the fifth edition, toward ECMAScript harmony.

Whatever happened to Embrace, Extend, and Extinguish?

Extend is right there in bold

Re:What's the catch?

[lenski]

I remember when Microsoft was "not unfriendly" to developers, before they decided that everyone producing a broadly useful application was their competition to be either absorbed or destroyed.

It is possible for them to be competitive without being the force of destruction that they became in the mid 1990's.

Re:What's the catch?

[shutdown -p now]

Not really. In "EEE", "extend" implies that the company unilaterally extends the standard that they've previously implemented ("embraced") with new features - for example, what MS did with Java in J++ in the past. In TFA, "cooperating" meaning "working as a part of language committee" - and that committee consists of many other companies, including direct MS competitors. There's no hidden catch here - MS is participating in proper discussion process, not overriding it.

In a similar vein, Microsoft "cooperates to improve" ISO C++, by having a number of people on the corresponding ISO committee (e.g. Herb Sutter). The same goes for HTML5, WS-* stack, XQuery, and many other standards that are implemented in whole or part in MS products.

Re:What's the catch?

[Plaid Phantom]

Ah, so they can't even do EEE right anymore? ;)

I'd imagine the "Extend" bit is much harder if you're sharing your extensions with the community.

very incremental

[anomalous cohort]

From TFA, it sounds like they are moving a lot of the stuff you normally find in the more popular libraries into the language itself. That makes sense, but hardly a game changing innovation that web application development companies should be gearing up for.

Re:very incremental

[Touvan]

The last line from TFA, "That's the proper role of standards." describes that. Standards standardize innovations that become common - usually some common set of incompatible implementations (hence the need for standardization). It's inappropriate to use standards in an attempt to innovate. The W3C learned that lesson with xhtml 2.0.

ECMA International

[Elektroschock]

ECMA, you mean the Oooopen XML ISO fast-track scam machine "ECMA International".

Why don't they publish the specification on their servers down in Redmond instead? Do the standard developers have a girl friend in Geneva? Or do they think it is more fun with free beer parties with Mozilla?

And finally, what has the current hugging to do with what goes on in Brussels?

Re:ECMA International

[moranar]

How are thee irrelevant, inflammatory and offtopic? Let me count the ways...

Seriously, what the eff does this have to do with the new release of JS? Pointing out that there was a bit of a struggle between Eich/Mozilla and Microsoft about the new additions to the language would at least have been on topic, but this?

Seriously, get out of the basement, wash and stop the useless bashing. There's such a lot of useful bashing to be done...

Re:ECMA International

[Elektroschock]

"ECMA" tells it all.

Specification does not dictate implementation

[riyley]

FTA: A lot of JavaScript is forked. If the DOM is IE, use this version of the code, otherwise use this.

Until this changes throughout the entire web, ECMAScript will only be that other part of css. It's just too problematic to have to code separate DOM funtionality for every browser on the market.

Re:Specification does not dictate implementation

[e4g4]

It's just too problematic to have to code separate DOM funtionality for every browser on the market.

These days, most of the forking is done in the library you're using - I rarely need to fork my code based on specific browsers anymore.

Re:Specification does not dictate implementation

[ThatsLoseNotLoose]

For some features, specification is just playing catch-up to the implementation.

The world couldn't just sit around and wait for JSON.parse.

Re:Specification does not dictate implementation

[somethinghollow]

Any "forking" I've had to do is, e.g.:

if(window.addEventListener) {
window.addEventListener('load', init, false);
} else if(window.attachEvent) {
window.attachEvent('onload', init);
}

It's unfortunate, but not a huge bother. It's rare in my day-to-day JS programming that I run into major compatibility issues beyond whether or not a particular feature is implemented in various JS engines.

Re:Specification does not dictate implementation

[Hurricane78]

Yeah right. It's just that I did exactly that from 2001-2006.
You write some intermediate standard layer, and you're done with it.
Maybe you just don't know how to abstract things away. ^^

JavaScript is surprisingly powerful. And you can even fix the whole missing/buggy DOM functionality in IE, by adding functions to the prototypes of the DOM objects.
For CSS fixes, there is even a library.

Re:Specification does not dictate implementation

[DrXym]

FTA: A lot of JavaScript is forked. If the DOM is IE, use this version of the code, otherwise use this. Until this changes throughout the entire web, ECMAScript will only be that other part of css. It's just too problematic to have to code separate DOM funtionality for every browser on the market.

Well not necessarily. Ajax libs like Dojo abstract away the differences so the end program doesn't have to care (too much) whether they're on IE, Firefox or something else. The client code just makes an xml http request via the lib for some JSON but doesn't care how the object was created or the response was evaluated. There would be nothing to stop these libs testing (for example) if json is implemented natively and calling that, otherwise falling back on their own homebrew solution. As far as the calling app is concerned the change will be transparent, except that the browsers with native support will presumably be that little bit faster and safer.

OOP?

[jez9999]

Will ECMAScript ever become sane to do OOP in?

Here's how you create an instance of a class in ECMAScript.

You start by creating a function (function foo). This will serve as the constructor. Why a function? Because EVERYTHING in ECMAScript is an object, even a function. But hey, why are you using an object instance as a class? Because ECMAScript does it that way.

Then, you take that object and set its 'prototype' member to another object that contains various members (foo.prototype = {var a; var b; var c;}). This is how you declare an object's members-to-be once it's instantiated, in ECMA script.

Finally you say "var bar = new foo();". And bar is an 'instance' of foo.

In short, when will ECMAScript have a way to do OOP that isn't totally retarded?

Re:OOP?

[johnnysaucepn]

Probably around the time you realise that object-oriented doesn't mean class-oriented.

Re:OOP?

[Anonymous Coward]

It is very sane right now. It is just a matter of thinking a bit differently than you were used to when having your c++ or java course.

Take plain c - it does not have classes either, only "objects", i.e. structs with function pointers. You have to construct the objects yourself.

Many people can live without c++/java style classes - they have for years and have created fantastic software. Javascript is fine the way it is, please don't opt to change it into something it is not. If you want something else, write a java interpreter and push it into firefox yourself.

Re:OOP?

[BlitzTech]

If you don't understand the expressive power and usefulness of functions as first class objects, you should really try using JavaScript differently. As for why you're using Object instances as classes, have you never used Java?

Also, you don't have to set the prototype all at once in a single object. The prototype keyword is used for functions that are common to all instances of the object; you can just as easily set the functions inside the constructor, but that creates a new function object for each instance instead of using one function object defined in the prototype and thus requires more memory. This allows you to change your object's behavior on the fly (if you so choose).

In short, OOP in ECMAScript is not 'totally retarded' at all, just outside your comfort zone. Try it first, THEN flame it, if you still think it's awful.

Re:OOP?

[bishiraver]

ECMAScript is a prototypal functional programming language. You don't just set members of an object by defining its prototype in an object literal.

You can also, by the power of closures, have private functions, private variables, and protected functions. (ECMAScript is interesting in that public member functions cannot access private variables, but protected functions can. Downside is that protected functions (defining them as this.foo = function() {}; in the constructor) are created new for each instance of the object, unlike the prototype (public) members.

While ECMAScript isn't built to enhance tail recursion, it's actually possible. For example, a continuous passing style fibonacci sequence calculator.

Not quite as readable as haskell or lisp, but still - proves that JavaScript is a true functional programming language.

Re:OOP?

[DragonWriter]

Not quite as readable as haskell or lisp

You know that for many programmers, that's sort of like saying "not quite as humid as Death Valley", right?

jQuery()

[Anonymous Coward]

As long as using jQuery doesn't change, I'm good. :)

Re:jQuery()

[Lendrick]

jQuery is what JavaScript *should* have been all along.

Re:jQuery()

[daemonburrito]

I think you're confusing the DOM api and javascript. jQuery makes the DOM api what it should have been all along.

Re:jQuery()

[chdig]

jQuery is what JavaScript *should* have been all along.

No, jQuery is a very good javascript framework, but its api should have no part -- at least yet -- in javascript itself.

Right now, the differences in coding an application with jQuery's framework compared to Ext/Prototype/GWT/etc are greater than the differences in coding javascript for IE vs Firefox. Frameworks are a personal choice of how you prefer to code, and one single framework should not be forced onto all coders.

To say jQuery is what JavaScript should have been is like saying that Ruby on Rails is what Ruby should have been, or that symfony or CakePHP is what PHP *should* have been. ie:apples vs oranges comparison.

While I hope, like the sibling poster mentioned, that the DOM api is improved, I certainly don't want jQuery to become the next standard of JavaScript.

Re:jQuery()

[beegeegee]

While I hope, like the sibling poster mentioned, that the DOM api is improved, I certainly don't want jQuery to become the next standard of JavaScript.

$("i").#{certainly}.#{agree}.childNode[0].with_that

Re:jQuery()

[Anonymous Coward]

True, but it does also "extend" plain old javascript language with nice additions. It of course uses whatever facilities javascript the language has, but some of the niceties (for looping, iteration etc) could conceivably be added straight into the language.

Not that that's necessarily a good idea -- proper amount of layering is a good thing, there is no point in flattening everything at the language level.

Re:jQuery()

[daemonburrito]

This history of javascript and the DOM is pretty complex and interesting. For example, the practice of wrapping native DOM objects has its roots in a cross-browser hack. IE's implementation of the DOM used COM, which meant that methods couldn't be added at runtime (maybe things got better with .net... I wouldn't know).

It turned out to be really useful, even aside from the cross-browser aspect. It allows jQuery to work with other libraries, and even multiple instances of itself. It gets around the problem of browsers deciding to implement new methods in the DOM, when your library had implemented the same feature earlier. Even Prototype has seen the light on this one... the assurance that your script will play nice with other unknown code is a killer feature.

With the iteration features, I'm guessing you're referring to stuff like each(). However, it's important to note that this is not a method added to a native DOM element; it's a method of a jQuery wrapper. And the practice of wrapping elements is now part of the architectural philosophy of things like jQuery (it's no longer just an IE workaround, it's useful on its own).

On the last paragraph in your comment... Yes. The death of ES4 was a good thing for this reason. We don't need classical inheritance and namespaces.

Also related to iteration, my #1 wish for implementations is optimization for tail recursion. The browsers currently only support 1000-5000 (I think) levels of recursion. After getting hooked on functional languages, using clunky procedural iteration hurts. There's tons of great functional code out there that would get ported to javascript overnight if browsers could manage the stack for recursion. Maybe Microsoft could get some of their Haskell guys to help out.

JavaScript, the Next Generation

[tttonyyy]

I fear for all those poor websites with red backgrounds...

Re:JavaScript, the Next Generation

[Anonymous Coward]

Mod parent up; Star Trek reference.

Re:JavaScript, the Next Generation

[Anonymous Coward]

Thanks Captain Obvious, there's no way anyone would have got that without your help.

Re:JavaScript, the Next Generation

[Shinmizu]

It sure did help me. By the way, in which series was Obvious the captain of one of the Enterprises?

Let's get this out of the way now

[Anonymous Coward]

I'm holding out for ECMAScript 3.11 for Workgroups!

Sanity?

[Millennium]

JavaScript does OOP in a sane manner. It's not the same manner as many traditional OO languages, to be true -it's prototype-based instead of class-based- but it's every bit as sane in its own way. It's just different.

The major reason you find OOP in JavaScript to be "insane" is that you are tearing your hair out trying to shoehorn in this particular paradigm that the language wasn't designed to use: sure, you can do it, but it's a lot of extra effort for very little gain in the end. That's not a problem with the language, but with programmers who resist the flow of that language. Just let JavaScript be JavaScript, and you'll find that things get much saner, or at least a lot less maddening.

Seriously: what harm ever came from learning new ways to do things?

Re:Sanity?

[BitZtream]

Ahh the sign of someone who isn't a programmer ...

'its prototype based, not class based'

If you really think these are different, you should probably stop calling yourself a developer.

Re:Sanity?

[Anonymous Coward]

Ahh the sign of someone who doesn't understand the difference between OOA/OOD and OOP.

The 4-digit /. ID you were replying to was referring to classes as they appear in 3GLs like C++, Java and C#, not to the "OO" word "class".

And that was perfectly clear from the context.

Go read good books on OO BitZtream, and try again later.
 

Re:Sanity?

[Anonymous Coward]

Did you really just say that? They are completely different!

Re:Sanity?

[Anonymous Coward]

fail

Re:Sanity?

[Anonymous Coward]

The parent comment needs to be submitted to the Daily WTF.

Re:Sanity?

[Anonymous Coward]

Says who punk?
Now get off our lawns, and back to study the fondamentals of OO!
OO is :
  - class based : C++, Java, ...
  - object/prototypes based : Javascript, Lua, Rebol, ...

Prototype-based programming

So who's not even computer literate?

what a joke

[Lord Ender]

Everybody knows TNG just copied half its stuff from the original!

Re:what a joke

[x78]

Meh, they're just Enterprising!

Json vs. XML

[dmmiller2k]

Json has dethroned XML for pure data interchange
</quote>

Somehow I don't think so. "AJAJ" just doesn't have quite the same ring to it.

Re:Json vs. XML

[oracleofbargth]

Somehow I don't think so. "AJAJ" just doesn't have quite the same ring to it.

Use YAML (a superset of JSON), and then you can have AJAY.

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.

Re:Json vs. XML

[daemonburrito]

Well... JSON wasn't really "invented". It's really just the syntax for an object literal in javascript. JSON parsing is not much more than eval() and a regular expression.

It works beautifully.

Not going to touch the rest of your comment. JSON is more useful in this context than xml.

Btw, Crockford's presentations are really entertaining: http://www.youtube.com/watch?v=hQVTIJBZook

Re:Json vs. XML

[tkinnun0]

I think it's a combination of bad initial impressions and the all-too common programmer tendency to look for small optimizations too early. A bit like the treatment Java gets.

Re:Json vs. XML

[beegeegee]

var name;
//JSON
name = eval(jsonString).name

//XML (at least in IE)
var xmlparser = new ActiveXObject("MSXML2.DOMDocument.3.0");
var doc = xmlparser.loadXML(xmlString);
name = selectSingleNode("name").value;


That's one reason.

Re:Json vs. XML

[K. S. Kyosuke]

So JSON is fatter than XML

Are you willing to claim that a proper XML parser able to parse XML in its entirety is thinner (smaller, faster) than a JSON parser able to parse JSON in its entirety? I would be very surprised if this were true.

Re:Json vs. XML

[Wraithlyn]

Well anyone can present a contrived example...

But in actual practice, XML contains a lot of redundancy in the form of open/close tags.

Or do you think everything should be expressed as attributes?

Re:Json vs. XML

[DragonWriter]

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.

Because XML isn't as compact in most real-world cases (which don't involve only one parent entity with a one-character name with exclusively empty children, meaning you have a much higher ratio of wasted characters in end tags than in your carefully-chosen example.) And because in JavaScript, JSON from a trusted source is trivially parseable with eval(), whereas XML takes more work.

Re:Json vs. XML

[radtea]

Well... JSON wasn't really "invented". It's really just the syntax for an object literal in javascript. JSON parsing is not much more than eval() and a regular expression.

This actually makes sense. Thanks.

I can see that the advantage of leveraging an in-built language capability can plausibly out-weigh the other advantages of XML, particularly, as others have pointed out, you have to suck the XML parser down over the wire. While it would obviously be possible to support a very light-weight subset of XML to do exactly the job JSON does, that too would require work to write and maintain. I didn't appreciate that JSON is so close to 'self-supporting' in Javascript.

To the people who seem to think that XML is inherently bloated: you're doing it wrong. There is absolutely nothing that requires XML to be bloated, and yes, I believe most values can be captured as attributes. The rule is: base types are attributes, classes are elements.

Re:Json vs. XML

[radtea]

Well anyone can present a contrived example...

My "contrived example" was straight out of the JSON docs, so if it was a contrivance it wasn't MY contrivance.

But in actual practice, XML contains a lot of redundancy in the form of open/close tags.

As I said in reply to another comment, if that's your actual practise, you're doing it wrong. Base types should be expressed as attributes, obviously. There is absolutely no reason to express anything as an element unless it has a complex structure.

This is why I've found JSON vs XML comparisons so difficult to grasp: people use XML badly, and then justify the use of JSON base one how bloated the XML is. The argument that you get JSON parsing naturally and almost effortlessly in JavaScript is compelling. "I use XML badly so my XML is bloated" is less so.

Re:Json vs. XML

[Wraithlyn]

Your XML version wasn't out of the JSON docs, that was your own contribution, and it was clearly minimizing use of tags and maximizing use of attributes.

If you're going to claim that's just the "right way", kindly link to some supporting documentation.

Would you say this is "bad" XML?

<menu>
    <menu-item>
        <portion unit="mL">250</portion>
        <name>Small soft drink</name>
    </menu-item>
    <menu-item>
        <portion unit="g">500</portion>
        <name>Sirloin steak</name>
    </menu-item>
</menu>

Because it's from an IBM article called Principles of XML design: When to use elements versus attributes.

The fact of the matter is, closing tags create redundancy that doesn't exist in JSON. Pretending that closing tags aren't a significant part of any real-world XML document is just asinine.

Re:Json vs. XML

[BraulioBezerra]

In ECMAScript you don't need quotes at the properties names, unless they have spaces.

Re:Json vs. XML

[spanky the monk]

Try a list

JSON:
{
listofstuff: [1, 2, 3, 4, 5, 6],
properties: { x: "asdf", y: "qwer" }
}

XML:
<root>
<listofstuff>
<i>1</i>
<i>2</i>
<i>3</i>
<i>4</i>
<i>5</i>
<i>6</i>
</listofstuff>
<properties x="asdf" y="qwer" />
</root>

This kind of foible really turns me off xml. Not to say XML doesn't have its place, but for AJAX applications I think JSON is much more appropriate. Also, parsing the dom tree is a real pain in the ass (not the donkey).

Re:Json vs. XML

[Anonymous Coward]

Your "JSON" example is not valid JSON, of course.

you 1nsens1tive clod!

[Anonymous Coward]

it junst 0wnz.',

Summary of JavaScript changes?

[sproketboy]

Anyone have a link?

Could we change the friggn name?

[sammyo]

Old story, "no it's not java" or "ECMAwhat?"

We get a new rev, add a name change update; let's call it something cool, oh, say ruby++ ?

Re:Could we change the friggn name?

[tesseractor]

If I had mod points today: Funny. Yes, replace one confusing, hype-linked name with one linked to the releatively new hype! Perfectly clear for the next 10 years! Just yesterday, a discussion with a PM (who I've been trying to get to understand the difference): He: Couldn't we just add some Java to the page? Me: ... well, we *could*, but I think it'd be better to do it in JavaScript.

Re:Could we change the friggn name?

[joeslugg]

let's call it something cool, oh, say ruby++ ?

I think you mean, "ruby-2sday"...

libraries are an ugly hack

[circletimessquare]

you should be able to code in straight javascript in all browsers the same. obviously, you can't do that now. but that doesn't justify the existence of libraries, it just means they are temporary bandaids that should go away with the implementation of the next javascript (crossing fingers)

Re:libraries are an ugly hack

[Hurricane78]

As I noted in my other comment: You can code straight JavaScript in all browsers. Even eLinks and IE. If you modify the object prototypes appropriately.

Re:libraries are an ugly hack

[maxume]

I agree with your premise, but many libraries, in addition to papering over browser differences, offer APIs that are more attractive than the DOM (for instance, CSS selectors, which are much nicer than element collection and node traversal).

Browsers are adding selectors, but javascript implementations have been available for ~5 years ( http://paulirish.com/2008/javascript-css-selector-engine-timeline/ ), waiting for the feature to be standardized and implemented at the browser level isn't something you can reasonably expect everyone to do.

Re:libraries are an ugly hack

[coryking]

but that doesn't justify the existence of libraries

Until javascript can traverse the DOM with something as elegant as $('.cat').click(function(){});, I'll be using jQuery for just about ever. Otherwise, I hope you are right. All these wrapper libraries are getting out of hand.

Re:libraries are an ugly hack

[rumith]

you should be able to code in straight C in all operating systems the same. obviously, you can't do that now. but that doesn't justify the existence of libraries, it just means they are temporary bandaids that should go away with the implementation of the next C (crossing fingers)

Makes about as much sense as what you said. Javascript libraries do more than just fix browser inconsistencies, they add many useful features and improve a programmer's life significantly.

Re:libraries are an ugly hack

[Tacvek]

WTF? I've written JavaScript before, but bever used jQuery. What the hell is that code doing? Clicking on all the ".cat"s using an empty function? Huh?

No seriously, why would a method named "click" take an argument? Any why would a valid value for that argument be an empty unnamed function?

Re:libraries are an ugly hack

[spanky the monk]

seriously, RTFM . This code registers an onclick callback to objects with css class cat. Try doing that with the built in dom methods in less than 10 lines of code.

confusing names

[bcrowell]

The names and version numbers are really confusing. The following is my understanding, which may be wrong -- if so, please correct me.

ecmascript 4==javascript 2==actionscript 3 ... If I'm understanding correctly, this was overambitious, turned out to be a dead end, won't happen.

ecmascript 3.1==ECMAScript, Fifth Edition ... This seems to be the more modest thing that they backed off and got a consensus for instead.

Re:confusing names

[Touvan]

ECMAScript 3.1 was used because they decided to back off the goals of ECMAScript 4.0 - 3.1 more readily describes the renewed goals as being less ambitious, only an incremental improvement over 3.0. When it's done though, it will be a whole new version - fifth edition or ECMAScript 5.0.

That's my understanding at least. :-)

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 / deserializer 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 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:Sweet!

[Tumbleweed]

First, JavaScript is a very nice language indeed.

Like any language, that depends on what you're trying to do. If you want to format the output of a date, there's not much built-in, so you have to do it yourself. If you want proper hash support, you're screwed. It can emulate it to a certain extend, but only goes so far.

I'd _much_ rather see a scriptable version of D.

Re:Sweet!

[jonadab]

> If you've never learned functional programming, JavaScript is a good language to learn in.

Most of the functional programming techniques I know, I learned in Perl.

It's interesting. I am sufficiently conversant in Emacs lisp to do significant amounts of useful stuff (including custom major modes for special editing situations), but I never understood lambda expressions in lisp. In Perl, though, anonymous subroutines are so straightforward, I immediately understood them and was able to start using them myself after reading barely a page of basic explanation. When I studies scheme I spent *hours* reading over and over and over again the chapter on closures and just couldn't figure the stupid things out. Then somebody on Perlmonks posted some Perl code that used lexical closures, and all became clear; I now use them myself without hesitation.

I've heard Perl6 is going to support continuations. I'm looking forward to it. Maybe if I see them in Perl code I'll understand those, too. I *sure* have not had an easy time trying to understand the explanations of them in the documentation for pure functional languages.

bedug

[MrKaos]

and strict mode will make things easier to debug."

aHahahahahahahahahahahahaha. Why it's the best thing about Javascript, writing the same code*browers different ways, and with chrome and safari Javascripting is just gonna get more and more fun. More Fun, MORE F.U.N.

The evil javascript hurts me. Evil I tells you!!!!

Re:bedug

[MrKaos]

Why am I Troll?

Surely other people who code in javascript have had the same issues as I do. Firebug is great but it doesn't help when you are trying to make sure your javascript works under IE. And no I don't want to buy all the proprietary Microsoft tools to debug javascript for IE and yes I do know about the javascript debug option under IE.

I'm not a Troll, Hrumph!!!

I'm glad they took an iterative approach

[drew]

It sounds like they decided to go with shoring up the language as it is currently used rather than make sweeping new changes. Good for them. I'm not sure if it was Adobe's doing or Macromedia's, but they really threw out the baby with the bathwater with the "transition" from ActionScript 2 to ActionScript 3. Rather than fixing up the obvious problems with AS2, like silently swallowing errors and gaping holes in the functionality of core objects, they abandoned it entirely and replaced it with some bizarre mutant language from a parallel dimension. I still have to wonder why, if they were willing to completely abandon both backward compatibility and developer familiarity, they didn't just decide to switch to an existing language. As far as I can tell, the only thing that AS3 really accomplished was to reimplement Java, and poorly.

For a while, it looked like the next version of JavaScript was following down a similar path. Glad to see that's not going to be the case.

Re:I'm glad they took an iterative approach

[Touvan]

I agree with most of what you said. AS3.0 made things a lot more strict, without addressing the main problem with AS2 - all silent errors. They can still fix it, that strictness is useful for larger undertakings and library authors (the browsers are even adding it to JavaScript).

The fix, default the timeline (and maybe even the entire Flash IDE) to non-strict mode, and add in a slew of warnings instead of throwing application halting errors all over the place. Auto-type marshaling is great! As long as you get a warning to let you know where it happened (so you'll know where to look when you just traced undefined or null).

Re:I'm glad they took an iterative approach

[Anonymous Coward]

Or, said differently, lazy-ass "Flashcoders" who couldn't code anything but silly timeline hacks have struggled trying to write code using standard OOP idioms in AS3, which is syntactically very Java-like.

At the same time, a large and growing market has grown around AS3/Flex development, filled by actual software developers - as opposed to graphic designers all impressed with themselves because they figured out how to write a loop.

Re:I'm glad they took an iterative approach

[Anonymous Coward]

I totally agree. And what's more.. as you pointed out this is a very non-traditional approach for the web world.

Look at CSS for layout. Here is basically how I see what transpired:

-w3c guy 1- although tables are a very logical way to arrange data in a user interface, and have become very common place both in our language and other programming languages, our tables were origionally designed for text, and as such have a few deficiencies that make them not 100% suited to the task.. despite that people have been managing fine for years.
-w3c guy 2- mm.. that's a big deal.. we should completely drop the idea of the table for layout.. and build something completely new, different, and unintuitive which will cause compatibility nightmares for years!
-w3c guy 1- uh.. why don't we just make a few slight alterations to tables
-w3c guy 2- you're fired!

Re:I'm glad they took an iterative approach

[drew]

I'm not taking sides on AS2 vs. AS3, and I'm not saying AS3 is necessarily a bad language. I'm just suggesting that it seems to me that AS2 could have been improved upon substantially without throwing out the entire language. Personally, I have relatively limited experience programming either version of Flash, and I wouldn't mind keeping it that way.

On the other hand, I have many years of experience with JavaScript, which I consider to be a wonderfully powerful and expressive language. I would hate to see all of that thrown out because some Java programmers can't (or aren't willing to) wrap their head around an OO model that doesn't have classes. Yet for a while, it was starting to look like that was exactly what was about to happen.

A few more names please

[wealthychef]

ECMA script, Java The Next Generation, JSon, WTF? Whatever happened to version numbers?

developers promptly respond

[nimbius]

...yes, but, does it work with java?

clean up your language

[speedtux]

C# and Perl happen to be also strongly typed and losely typed, respectively, but that isn't essential to your example. The distinction you're looking for isn't "strongly typed" vs "loosely typed", but "statically typed" vs "dynamically typed".

Re:clean up your language

[Anonymous Coward]

Not so fast. Perl allows implicit conversions between strings and integers that would cause a compile error in C#. However, C# still allows you to box things in a dynamically typed "object".

See: http://en.wikipedia.org/wiki/Weak_typing

Re:clean up your language

[Anonymous Coward]

As I was saying: Perl is weakly typed, but that isn't essential to the example.

As for C#, it has facilities for dynamic typing (as do most statically typed languages), but those don't represent the native type system.

Co3k

[Anonymous Coward]

these chaalenges by BSDI who sell Are incompatible

bi2natch

[Anonymous Coward]

Series of internal have an IRC client www.anti-slash.org ww.anti-slash.org

Very little of the *language* is forked...

[weston]

FTA: A lot of JavaScript is forked. If the DOM is IE, use this version of the code, otherwise use this.

Not much of *Javascript* itself is forked. The *DOM* is quite thoroughly forked. One might even say forked over. But as other people have pointed out, Prototype and Dojo and jQuery and the like tend to mitigate that problem.

JSON not always fatter

[weston]

JSON's not always fatter. Particularly when you have information stored as child nodes rather than attribute nodes (one-many relationships rather than one-one relationships tend this way), XML can get fatter pretty quickly.

I suspect the JSON love has to do with the fact that if you're already working in Javascript, it's just more javascript, and there's zero mystery about how to work with it. Not that XML is rocket science, but with JSON, it's pretty much as easy as eval() if you trust the server.

Overall, I like what Steve Yegge had to say: "XML is better if you have more text and fewer tags. And JSON is better if you have more tags and less text." It's probably a little more complicated than that (the fatter/thinner issue is one, compression is another), but it's a decent heuristic.

lol

[coryking]

You really think I was gonna fill in the guts of a sample function? .click() hooks the onclick event.

What

[omfgnosis]

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

Anyway, it's a difference of 8 characters in JSON's favor. Unlike XML attributes, no whitespace between JSON properties is necessary. And for that matter, while they can be shoehorned to present the same information, they can serve somewhat different purposes. But really, as a data format, the advantages that JSON sways me with are:

- JSON is identical in text form to the same data structure in JS, which is great since JS is where I do most of my work
- JSON is a hell of a lot more readable, particularly as the data grows (it is also less annoying to write, for whatever little you may be writing either)
- Parsing JSON is dead simple in every language I work with, which is not the case for XML

Yes, it also has marginal bandwidth benefits, but that's not the only thing one looks for in a data format.