I've been meaning to blog about this for a while, but just haven't gotten around to it. ECMA-262 is the specification for ECMAScript, which is the core of JavaScript, providing syntax, operators, keywords, default objects, and more. The third edition of ECMA-262 is the one implemented by almost all browser vendors (though to varying degrees of completedness). The fourth edition is currently being developed and will be the basis for JavaScript 2.0, its progress can be tracked at wiki.ecmascript.org.
While I don't really like ECMAScript 4 for a lot of reasons, the part I really don't like is including JSON serialization and parsing as part of the core. ECMAScript has never cared about data formats; there's no native support for XML, why should there be native support for JSON?
Undoubtedly, JSON has been very important to Web 2.0. It is being used everywhere by almost everyone who's doing anything online. I understand that the popularity requires better tools, but I don't believe this is the answer. I think the proposal for a parseJSON() method on the String type is ridiculous - it doesn't make any sense. The String type isn't a parser, it's a string! It shouldn't have any more functionality than is necessary for dealing with strings. Adding the toJSONString() method to the Object type also doesn't make sense to me. Since Object is the base of all objects in JavaScript, this means that all objects must implement it, even for objects on which it won't make any sense (think Date, RegExp, Error, etc.).
Is better support for JSON necessary in browsers? Absolutely. The ability to parse JSON without using eval() is something that really needs to be provided, but I don't think what's in the ECMAScript 4 specification is the answer. I'd rather see one of the browsers take the lead and provide a generic interface that makes sense. Mozilla started the trend of using having DOMParser and XMLHttpRequest...take the lead again and create something for JSON that makes so much sense that the other browsers are forced to implement it too.
My please: let's keep data formats out of the JavaScript core. A good programming language shouldn't care about the data formats it uses, instead, it should provide enough functionality so that any data format can be used. This is necessary because data formats come into and out of style frequently, and a programming language shouldn't have to adapt to those trends. JSON, XML, and any other data formats that come along should not be part of any language's core, and certainly not part of JavaScript's core.
1) """ECMAScript has never cared about data formats; there's no native support for XML""" What about E4X? http://www.w3schools.com/e4x/
2) """Mozilla started the trend of using having DOMParser and XMLHttpRequest""" Ahem... it was actually Microsoft and IE that introduced XMLHttpRequest:http://en.wikipedia.org/wiki/XMLHttpRequest#History_and_support
3) What data formats are you referring to that are coming in ant out of style? XML, YAML, JSON.... those are not going anywhere anytime soon. Do we really want to force all developers who use JSON (that's a lot of developers) to providing their own core support for JSON?
@Chad - 1) E4X is not core JavaScript, it's an extension. I think extensions are fine for specific uses, I just don't think it should be in the core.
2) Microsoft started out using XMLHttp as an ActiveX Object, Mozilla was the one who created XMLHttpRequest as a native JavaScript object and their implementation was copied by Opera and Safari.
3) You're making assumptions about data formats. Five years ago, we never would've anticipated JSON would nearly replace XML as the data format of choice over the Internet. You replace "data format" with anything else. Web services with SOAP were huge a couple years ago, what about now? What if built-in support for web services had been added? There would be a whole lot of the language was suddenly no longer relevant.
I completely agree about the proposed String.parseJSON. In fact, even the json.js that adds this functionality to String.prototype is a mistake, IMO. I'd much rather see parseJSON implemented as a global function, as the "good twin" to eval.
However, toJSONString makes sense as a native function on the Object type, so that it applies to hash tables, and could be nulled out or return "" for types where it doesn't make sense.
Regex is pretty easy if we're strictly talking about Javascript, since it has a regex literal form of /(etc)/. But JSON is all about portability, and unless you're strictly talking about Perl and JS, that's no good. Date could be done, but a unix timestamp would be more portable than a string.
In my opinion, only native datatypes can be meaningfully json-able: boolean, number, string, hash table, array, null. These datatypes exist in some form in most languages, so they're highly portable. Any other data type should be transformed into the closest possible representation or omitted from the encoded string.
@Nicholas
I would have made the xact same comment as ChadL
E4X is an extension to 3rd edition, but it's integrated in the 4th edition
from people using AS3 daily, it never been so easy to parse/use XML with E4X, I bet even Java and C# can be jealous of that :)
For JSON, I personally think we can have better data formats, but still having JSON as default make perfect sens, that means in a blank ES4 environment you will at least have JSON, that's nice.
@Isaac - Yeah, I'm not sold on json.js either. I really think more thought has to be put into this.
@zwetan - Please don't get me wrong, I think E4X is an utterly brilliant extension. It beats anything I've seen in any other language for manipulating XML. I'm just saying that data-format specific functionality should be made as an extension, not as part of the core.
Right.... how do you think toString() functions work in languages? Each native type needs a corresponding toString() method for this to work. How would a toJSON() be any different?
""I'd rather see one of the browsers take the lead and provide a generic interface that makes sense""
Good idea, I suppose. But wouldn't this have to start with a proposal of sorts? Would you seriously feel comfortable with Microsoft pushing a standard here? Maybe. But what happens if what a browser comes up with is something completely bizarre and misses the mark. At least to me, this seems to cry for a committee or workgroup to propose solutions so the browser can at least know what to aim for and what to steer clear from.
Now, because, what's being proposed *does* seem to make sense to me, can someone please remind me why it's so wrong to support JSON at the core. Because, technically, isn't JSON not just a data format, but also a powerful syntax for defining javascript objects? That's right, the object that is core to JavaScript.
So why again does this seem so wrong? I really don't get what all the fuss is about.
@ChadL - I'm not sure what point you're trying to make about toString(). I would definitely be comfortable with a company like Microsoft or Mozilla taking the lead and developing something. This is how we ended up with the DOM, XMLHttpRequest, DOMParser, and more.
And technically, JSON is just a data format. It is based on the JavaScript object literal syntax but it is not a way to define objects; it's a way to define data in a structured way. And I'll say this again: programming languages should not have native support for data formats. It should be up to host environments and even developers to define interfaces on top of the language to handle data formats.
I agree with Nicholas (no surprise there). JSON is a data format that uses ECMAScript syntax to organize data; it shouldn't be part of the core language. Instead, it should be a tool browsers provide.
var obj = (new JSONParser()).fromJSONString(myJsonStr);
var str = (new JSONParser()).toJSONString(obj);
Simple, effective, and it doesn't bloat the core language with unnecessary additions of data formats. If they're hell bent on including JSON to the ECMAScript language, it should be done like all other native objects: create a new object called JSON and use methods of that object to parse data.
And I'll take this moment to again say I don't like ECMAScript 4 ;)
I like it when objects know how to serialize themselves.
I propose that every javascript object inherent a prototype property called Serialization. This Serialization object shall contain a method called toJsonString which will perform the conversion.
If another data format comes along, the standardization board can simply add additional methods to this one (Serialization) object: toXmlString , toYamlString, etc.
When coding, it's nice when an object knows how to do stuff to itself because its more concise than creating a new object to do the conversion for the current object that needs the conversion.
Plus, the instantiation of a new object takes up unnecessary resources, while a prototype object can persist once in memory and serve all objects.
So, supporting a data format at the core doesn't significantly bloat the core; it just adds one object that all other objects have a lean pointer to.
Last, it will be nice for there to be one authority for Json conversion. Putting it at the core, makes it there for everyone to use. If they don't do this, a bunch of people will attach it there anyway, and they will all name the object differently and use different code to do the intended conversion. Now you have potential for compatibility problems. Each time you work on a new code base, you'll have to discover the JSON idiosyncrasies (interface) of their implementation.
So, with the standardization board putting this functionality at the core you have:
-programmer efficiency
-standardized interface
-performance (instantiation is avoided)
However, I propose that they make one prototype object to hold all future data formats that will be supported. No since cluttering a string object's immediate interface:
var str = "Ho ho ho";
str.Serialization.toJsonString();
str.Serialization.toXmlString();
str.Serialization.toYamlString();
-Lonnie Lee Best
@Jeremy, Nicholas - Your comments concur w/thoughts on the JSON.
I've been wanting to have a native JSON class in JS for those very reasons.
I posted not too long ago on ES4 list: "JSON Methods":
"...A parse method always parses a string, and in any well-designed API, returns an object of the class it's bound to. We've already seen this with Date.parse(), in other languages, like Java, there are Integer.parseInt, Double.parseDouble..."
Then Lars pointed out that Date.parse returns a Number, not a Date.
I've worked on enough projects where JSON was used to "save space" on the wire. The code was extremely difficult to debug and quite buggy.
JSON parsing and wire transfer is fast for the data. The javascript transformation layer is where that efficiency ends and maintenance problems begin.
JavaScript is not a good templating/formatting language. Mixing HTML into the JavaScript makes both harder to debug.
Write a sound proposal. Explain the current proposal vs a native JSONParser or JSON class. This will be far more productive than blogging about it. You've already got some people who agree with you who might help out.
Here is a good description of how to write a proposal if you really want to be thorough:
http://lists.w3.org/Archives/Public/public-html/2007Jun/0953.html
@Garrett - All good points. I've actually wanted to put together a proposal for an alternative, just haven't had the time. I do have a couple of long flights coming up, perhaps that'll give me the extra time to do it. :)
From my understanding, the ES4 group has already decided to eliminate String.prototype.parseJSON and Object.prototype.toJSONString in favor of JSON.stringify and JSON.parseJSON (not sure if I got that exactly right), partly due to pressure applied by people like Garrett and even Douglas Crockford suggested that latter and changed his ever popular library to stay out of the String and Object prototypes.
I think the ES4 specifications that are available online are just not up to date enough.
And much more intriguing and open question regarding JSON in ES4 is how it will serialize namespaced properties...
Post Comment
Your e-mail address will never be shown, only your URL. Please, no HTML in your comments, as it will be automatically stripped out for security purposes.