Tuesday, January 19th, 2010
ECMAScript Edition 5: WebKit JavaScriptCore Progress
Category: JavaScript
Over on the Qt blog, Kent has posted on the progress that has been made, and what there is to go, for this to be seen in JavaScriptCore (normally the V8 team releases once the language is out there):
Features implemented in JavaScriptCore
This is stuff that’s already in WebKit trunk. I’ve included links to relevant Bugzilla tasks in case you’d like more information (e.g. have a look at the patches).
- Object.getPrototypeOf
- Object.getOwnPropertyDescriptor
- Object.keys
- Object.defineProperty
- Object.defineProperties
- Object.create
- Object.getOwnPropertyNames
- Date.now: Has been in JSC for a long time.
- Date.prototype.toISOString
- Date.prototype.toJSON
- “Array extras”: Array.prototype.{indexOf,lastIndexOf,every,some,forEach,map,filter,reduce,reduceRight}:
These have been in JSC for years. I’m not sure how conformant the implementations are, though.Features not implemented in JavaScriptCore
- Object.seal, Object.isSealed
- Object.freeze, Object.isFrozen
- Object.preventExtensions, Object.isExtensible
- Strict mode: I’m not aware of any work that’s been done to support strict mode yet. It involves making the parser/compiler recognize the “use strict” directive and adapting execution according to the rules given in annex C of the ES5 specification. (The annex lists 20 restrictions/exceptions that apply to strict mode.)
Hopefully work is moving fast for Mozilla, Opera, Google and Microsoft too!
Related Content:
4.5 rating from 33 votes
I still think JSON.stringify and JSON.parse are awfully named… why not just JSON.encode and JSON.decode?
What rasmusfl0e said. I have hard times remembering which does what. Maybe I’m too used with PHP’s json_encode/json_decode, but still… stringify?
Theses names are for backward compatibility.
But I agree, they are awfull, I don’t know what Douglas Crockford was thinking when he named his methods.
.
JSON.parse()/serialize() would have been such a better choice. ECMAscript 5 should have standardized ‘serialize’ and suggested a ‘stringify’ alias. The backward compatibility/performance argument isn’t so revelant, considering that most of the time you serialize on the server and parse on the client.
“I don’t know what Douglas Crockford was thinking when he named his methods”
So the guy who complains about JS having “bad parts” is a total retarded designing languages as we can see.
Stringify??? what a stupid joke, now our beloved language gets more “bad parts” so he can write more books, now I see the point.
I vote for encode/decode and parse/serialize
Hey everybody, quit on the Crock hatin’!
I’d go for ‘serialize’ over ‘stringify’ but I always seem to get mixed up with encode/decode as to which one I should be doing. But regardless, it’s too late now.
JSON.toString() would have continued the conventions already in JS… Ah, well.
@rasmusfl0e: Using JSON.toString() one would expect it to give a string representation of the JSON object, as it does with other Javascript objects. In my eyes this is an even worse idea than JSON.stringify(), because it breaks peoples expectations.
BTW: JSON.stringify has been around for a long time in Crockfords json2.js, so people are used to using it. Seems kind of strange to me that people start bashing Crockford only now ECMA has made his idea a standard…
Only Ajaxerex bashed Crockford, the rest simply makes a valid point.
.
To me, “stringify” is simply too cute… yuk
PS. nitpicking aside, YAY!
Yeah. How dare they suggest that one tenth plus two tenths does not equal 0.30000000000000004! I think that ECMA’s decision to keep the existing float standard was the right choice, given the circumstances, but the circumstances were broken to begin with. IBM’s preferred float standard was not the best choice, but no other alternatives were offered. And the argument offered for keeping the highly imprecise standard (that changing it would break existing applications) is just obtuse. There’s no reason that a better float standard couldn’t be enabled with strict mode, which we’re all meant to start using anyway. It’s absolutely ridiculous that IBM has to take the heat alone for a bad decision (among bad choices) made by everyone involved. Their preferred float standard was not the best choice, but their rejection of the existing float standard is correct.
JSON.stringify is a ridiculous method name. Douglas Crockford has contributed a lot to the Javascript “world”, but he’s not infallible. And since when is library convention considered “backwards compatibility”? I’m not even sure I agree there should be a native JSON object. Why not Object.prototype.toJSON and String.prototype.toObject (I can see how this might be problematic, but I’m sure more thought put into it would find a better solution than a dedicated JSON object)? JSON.serialize certainly would have been better though, and it’s quite a lot more obvious what its purpose is. “Stringify” is actually quite vague: given the restrictions on what types are permitted in JSON, it’s not completely ridiculous to think “stringify” might mean “convert object’s invalid property values to strings as they would be represented in JSON”. Or something else equally ridiculous. “Serialize” is unambiguous and a conventional term for the behavior.
I’m also not too fond of the naming of Function.prototype.bind. It is, of course, based on PrototypeJS convention, but it conflicts with jQuery convention. If library convention counts for “backwards compatibility”, Function.prototype.bind should be verboten. Why not Function.prototype.scope or the no-more-verbose-than-the-rest-of-Javascript Function.prototype.assignScope?
Mozilla’s ES5 progress:
https://bugzilla.mozilla.org/show_bug.cgi?id=es5
Its likely JSON functions are named `stringify` and `parse` because its quite easy to swap the semantics of `encode/decode` and `serialize/deserialize`. With `parse` and `stringify` I don’t need to stop and think what the input and output to the function should be.
I guess it’s pretty clear that (rightly) the only thing people need is native JSON support. The rest of it seems to be based on this proposition > the rapid and massive growth/usage of javascript, coupled with the demonstrably excellent browser-based applications it powers, considered alongside the growing body of extremely confident libraries and articles promoting only the vast possibilities of this language, shows only that the language is broken. Speaking of Crockford.
For goodness’ sake, what is wrong with JSON.parse and JSON.stringify as an API? It’s two names, and they’re quite clear and easy to remember. @eyelidlessness: “Function.prototype.bind should be verboten” because it’s different to jQuery convention? jQuery is a JavaScript library designed to make DOM interactions easier. Its API is not perfect and I see no reason why its conventions should be applied to the language specification.
Just fix it yourself in your libraries…
JSON.serialize = JSON.decode = JSON.stringify;
JSON.deserialize = JSON.encode = JSON.parse;
Function.prototype.proxy = Function.prototype.scope = Function.prototype.bind;
It’s common practise to abstract away from a language’s native API, just look at jQuery or any JS framework for that matter.
Don’t like it? Switch to a language where you actually have valid reasons to whine.
The fact that I put encode/decode the wrong way around, also shows that stringify/parse are more unambiguous than the other method names suggested here as well…
timdown,
Did you read my comment, or just scan it for things that didn’t seem right? Because I was pointing out that Function.prototype.bind should be verboten according to the logic of using JSON.stringify for “backwards compatibility” with a library that is not part of the core language at all. If JSON.serialize needed to be JSON.stringify for “backwards compatibility” with existing JSON libraries, then Function.prototype.bind can’t be used because it is impossible for it to be “backwards compatible” with existing libraries implementing a bind method.
You’ll note I think all this logic is wrongheaded, and that API naming should be based on clarity of meaning, not what market leaders do. I noted one case in which “stringify” isn’t clear but “serialize” is, and I also noted that a native JSON object is unneeded.
Indeed. Likewise json2.js.
* * *
BenGerrissen,
There is no way to fix the JSON mistake in your libraries, if you believe that it is incorrect to have a native JSON object and that its methods should rightly be part of the Object and String prototypes (or some other, equally disruptive solution to implement in code rather than the engine). I mean, it’s “possible” to add the methods to those prototypes and to delete the JSON object (assuming access to the global object), but it will break quite a lot of existing code. So much for “backwards compatibility”, eh?
When I’m benevolent dictator of the universe, I’m going to make it a capital crime to tell people that they should go away instead of complaining. ECMAScript 5 isn’t perfect, and there are valid reasons to complain. I’ve covered but a few. If you don’t like complaints, don’t read them. Javascript is my preferred language, which is why I’m on guard when it is changed. I shouldn’t need to defend my complaints by stating my preference, but there it is.
I don’t really understand this, even though several people have expressed it. Encode means to convert something operable to “code”, and decode means to convert something from that “code” to something operable. It’s quite literal about what it does. “Parse” is also more or less literal about what it does. “Stringify” is not even a word, much less one that is literal about what it does: there’s no reason it couldn’t mean “convert object’s invalid property values to strings as they would be represented in JSON”, as I noted in my earlier comment.
* * *
Overall, I have no major qualms with the ECMAScript 5 specification. I think the reasoning behind rejecting a better float standard was wrong, but it only affects me in theory really. I think the reasoning behind using certain libraries’ method naming for “backwards compatibility” is wrong, but I’ll get over it eventually. I don’t really think ES5 adds a lot of value, but it wasn’t really meant to. Overall, it’s a minor update to ES3. That’s fine. But poor reasoning should be called out, because it will affect the standard process moving forward with Harmony, which will eventually see major overhauls.
@eyelidnlessness
To quote myself a few comments earlier:
\o/ for typos in formatting…
It’s a joke son, I say, a joke. You can tell because, you know, it was so absurd.
You are lying. You said, “Don’t like it? Switch to a language where you actually have valid reasons to whine.” By saying that, you’re saying that the opinion is invalid, and that those holding that opinion should switch to another language—to go away, rather than expressing the opinion.
Oh, please. I live in Seattle, passive-aggression is so old here it’s rotting.
And while it may be trivial to you, it may not to others. As Douglas Crockford (har!) says, changing a standard is an act of violence.
Huh? My mommy says I’m special. Anyhow, spare me the armchair psych.
“stringify” is a lisp/scheme cultural thing. Javascript is based on scheme. “serialize” is a java thing. Which you prefer rather depends on which programming subculture you come from. There’s lots of programming words that aren’t really words.
.
” I mean, it’s “possible” to add the methods to those prototypes and to delete the JSON object (assuming access to the global object), but it will break quite a lot of existing code. So much for “backwards compatibility”, eh?”
.
Yes I suppose that if they’d done what you wanted, a lot of applications would have broken. Just as well they did what they did instead.
.
“If JSON.serialize needed to be JSON.stringify for “backwards compatibility” with existing JSON libraries, then Function.prototype.bind can’t be used because it is impossible for it to be “backwards compatible” with existing libraries implementing a bind method.”
.
prototype implements a bind method on Function.prototype which is compatible with the ecmascript version. No conflict there. jQuery implements a bind method on the jQuery.prototype object, and does not modify Function.prototype. There’s no conflict there either. jQuery’s bind does happen to do something different than Function.prototype’s bind, but neither clobbers the other so there’s actually no backwards compatibility issue here. You seem to just be grasping at straws.
.
In any case, everyone here had plenty of opportunity to complain on the ecmascript list over the past 2 years if it actually mattered to you.
@eyelidness o.O I will respond with a barrage of smileys to further elaborate context. =) =) =) =) =) =)
Thank you for choosing me as a target to pee against, I feel priviledged ;)
Breton,
Maybe so, but it seems the majority prefers “serialize” over “stringify”. The former is a real word, and the latter in this case wasn’t carried over from Scheme, but from json2.js.
No they wouldn’t have, and that’s not what I said. Existing applications would be broken by implementing Object.prototype.toJSON in Javascript rather than natively. Implementing it natively would have no effect on existing applications.
The conflict is that jQuery() is a function, and therefore overrides Function.prototype.bind for a purpose different from Function.prototype.bind. It is sure to create confusion. But I don’t care that they specified Function.prototype.bind, I care that their logic of “backwards compatibility” with libraries (as opposed to the specification) was applied inconsistently. If the purpose of “stringify” is “backwards compatibility” with existing JSON libraries, then they undermine this purpose by using Function.prototype.bind. I cannot imagine how this is unclear.
jQuery.prototype.bind does clobber Function.prototype.bind. jQuery inherits from Function.prototype, and overwrites the bind method. If existing library implementations’ naming conventions are to be respected (as with JSON), then they failed to apply this logic to Function.prototype.bind.
This is as useful as BenGerrissen’s “Don’t like it? Switch to a language where you actually have valid reasons to whine.” Anyhow, as great as Javascript is, ECMA has proven their inability to consider valid criticism and find working solutions: 0.1 + 0.2 = 0.30000000000000004. And criticism here or anywhere else doesn’t become invalid simply because ECMA made final decisions on the “fifth” version of ECMA-262.
I don’t really understand why anyone is so offended by criticism… as that is how standards (or anything) improve. But if you don’t like criticism, you don’t need to read it. You’re certainly not making it go away by dismissing it. (Your earlier challenges to my logic are not being addressed here, only your last comment.)
* * *
BenGerrissen,
I don’t feel that I “peed against” you, I simply responded to the things you said—and more than that, clarified the things I had said earlier. Attaching emoticons to statements does not necessarily remove weight from those statements, and while I understand that you were being somewhat lighthearted (and I’ll clarify that I was too [insert emoticons here]), I think the dialogue itself has merit and was worth addressing.
Take none of what I said at any point as attacks on you, but rather as challenges to your opinions. I think challenging opinions is valuable. If you don’t, I’m sorry, but you should be aware that expressing your opinions will probably attract responses.
“The conflict is that jQuery() is a function, and therefore overrides Function.prototype.bind for a purpose different from Function.prototype.bind.”
.
Bzzzt. Absolutely incorrect. jQuery is a function, jQuery() is a function invocation that returns a jQuery object, on which you would find the bind method, and which does not inherit from Function.
.
Good try though.
“This is as useful as BenGerrissen’s “Don’t like it? Switch to a language where you actually have valid reasons to whine.” Anyhow, as great as Javascript is, ECMA has proven their inability to consider valid criticism and find working solutions: 0.1 + 0.2 = 0.30000000000000004. And criticism here or anywhere else doesn’t become invalid simply because ECMA made final decisions on the “fifth” version of ECMA-262.”
.
If you go there now maybe you can get your rants in before the next version is standardized. Your complaints about Ecmascript 5 now are about as useful as a quadriplegic complaining about road laws. Maybe you can help future potential victims, but Ecmascript 5 is a done deal. You’ll never grow those nerve cells in your spine back, dude.
“Maybe so, but it seems the majority prefers “serialize” over “stringify”. The former is a real word, and the latter in this case wasn’t carried over from Scheme, but from json2.js.”
The former is a real word- in the united states. In every other english speaking country it is an infantile mispelling of serialise. Now just imagine all the english speakers of the world spelling serialise correctly, and getting a type error, undefined is not a function, and spending half an hour trying to figure out what’s wrong.
At the very least, stringify is weird enough to have one canonical spelling that everyone in the world can agree on.
Besides, you have no statistics on preferences for one or the other. That is merely an assertion on your part. Majority Shmajority.
Breton,
My first reaction was “wow, you can’t possibly be so pedantic as to misinterpret my use of parentheses to distinguish the function from the library name as the invocation result”. Then I stopped and thought, “no, that sounds right. I doubt there is actually a jQuery.bind method. I can’t believe I’ve been so wrongheaded about this.” So then I checked, to be sure. And there is a jQuery.bind method.
console.log(jQuery.bind); // function() {...So I’m back to… wow, you can’t possibly be so pedantic. But apparently you can. jQuery.bind overwrites Function.prototype.bind in ES5.
What difference would it have made? If IBM didn’t have enough weight to get the change in, how would little, insignificant me at http://null/ have tipped the scales?
Needless to say, I don’t agree. Many, many people who have influence on Javascript read (and write for) this site. I think public opposition to mistakes will help to pressure ECMA to avoid repeating those mistakes. If you disagree, feel free to ignore me.
Oh, more pedantry. Well, I don’t care to debate the merits of “correct” spellings between American English and other English dialects (my position, for what it’s worth, is that neither is “more” or “less” correct). But I will point out that they are the same word, spelt differently. Words are symbols for concepts and entities, not meaningless collections of letter-shaped symbols. It is a real word, whether it contains a z or an s.
I prefer for a language to be consistent with its naming conventions. I’m only aware of one native Javascript component that differs between American and non-American English, the Math object. So I would expect any native appearance of the word “serialize” to take the American English spelling. Otherwise, I wouldn’t care which was implemented.
And not that ECMA should let the DOM specifications influence spelling, but where Javascript does interact with the DOM, spellings are entirely American where there is any potential conflict.
Nearly all programming languages favor American English. In fact, I can’t think of any localized to non-American English.
With all of that said…
I sincerely doubt this would happen too often. “Serialize” is used in many languages… I’m not aware of any using “serialise”.
This is a really poor reason to choose any particular name for anything. “Everyone in the world” is obviously limited to English speakers, which is quite obviously not everyone in the world (and a shrinking proportion of the programming profession). By your logic, we should do away with any human language-based naming and adopt symbols that have no localized meaning whatever.
While I have no idea how you can know this, you’re right. I have no hard data. I was stating an observation.
I thought you would check, so I checked myself before I posted. This was my result:
console.log(jQuery.bind); //undefined
I think maybe you should double check your work.
“What difference would it have made? If IBM didn’t have enough weight to get the change in, how would little, insignificant me at http://null/ have tipped the scales?”
You obviously have no concept of exactly how hard they tried to satisfy IBM’s demand. Fixing that problem is way more difficult than you seem to think, and they simply ran out of time, so rather than standardise an even more broken and awkward version of ecmascript, they decided to put it off until the next version. If you have some brilliant idea of how to make it work, I can gaurantee that everyone on the committee is eager to hear it.
.
“Needless to say, I don’t agree. Many, many people who have influence on Javascript read (and write for) this site. I think public opposition to mistakes will help to pressure ECMA to avoid repeating those mistakes. If you disagree, feel free to ignore me.”
.
And you can contact the people that have influence on the standard directly, via the ecmascript list, without having to go through these passive agressive indirect routes where you expect them to come to you.
.
“This is a really poor reason to choose any particular name for anything. “Everyone in the world” is obviously limited to English speakers, which is quite obviously not everyone in the world (and a shrinking proportion of the programming profession). By your logic, we should do away with any human language-based naming and adopt symbols that have no localized meaning whatever.”
.
Non english speakers program in javascript too. There are no non english localized versions of javascript, at least none that I’m aware of. There is no reason why non english speakers should object to “stringify”, as it’s just as opaque and meaningless (outside the context of javascript) as any of the other javascript words.
console.log(jQuery.bind); //undefined
//check whether this is jQuery’s bind, or native bind, or prototype’s bind. Simply verifying that it is a function proves nothing.
So you are right. I just looked at my open tabs and checked in the first which had jQuery active. Apparently that site adds jQuery.bind at some point during runtime, no other instances I’ve checked have it. I concede this point, as well as my objection to Function.prototype.bind. I do not concede my point about treating library conventions as “backwards compatibility” for the language. While the conflict I thought I had identified turned out to be a mistake, it’s easy to see how these conflicts could arise where there are competing libraries whose “conventions” may differ.
Actually, I wasn’t really fairly representing it. IBM’s demand wasn’t for a solution to the poor float standard, but for a specific replacement that had its own problems (speed). This was part of the reason it was rejected. The other part was that, supposedly, “it would break existing applications”. I addressed this in my first comment to this post.
Douglas Crockford can rattle off a few replacement float standards that would work. It’s not that difficult, the work is done.
Horseshit. They had years and years and years.
This much is true.
Let me be absolutely blunt. You are not going to stop me from posting on Ajaxian, in a post about ES5, what I think about ES5. If you don’t like it, you can tell me so, but it won’t stop me. You do not know if I do or do not post on the ECMAScript list, and doing so would not prevent me from expressing my opinions in other venues. And not doing so would not invalidate my opinions.
You missed my point entirely. By saying that native objects and methods and reserved words must use spellings which “everyone in the world can agree on”, you have already eliminated every single word in the language.
HI
A great information about the new volume of Java Script and the compiler recognize the use strict directive and adapting execution according to the rules given in annex C of the ES5 specification.
http://www.bid66.com
“I do not concede my point about treating library conventions as “backwards compatibility” for the language. ”
I assume then that you object to the Array extras for the same reasons?
I’m not aware of any of their names being justified based on “backwards compatibility” with libraries. If that justification was advanced for those, then yes I object to that justification in those cases as well.
I should clarify, because it’s unclear to me whether you’re aware or not, that I don’t object to the functionality of any of the ES5 additions. I object to one name (“stringify”), the unnecessary creation of the native JSON object where its methods would be better suited to the Object and String prototypes, and primarily the use of library conventions as justification for names. I don’t even object to library functionality being made part of the native standard—just treating one library’s naming conventions as if they are retroactively part of the standard.
The array extras were all adopted and compatible with the prototype library.
.
I think they’ve avoided adding anything to Object.prototype for backwards compatibility. json2.js, with the JSON object, exists for a similar but different reason. json.js did exactly as you propose, but methods added to Object.prototype are enumerable on everything that inherits from Object. Native methods can be made non-enumerable, but I think that there would still be name collisions with existing libraries, frameworks, and scripts that copied the json.js convention.
json2.js is already widely deployed, and from the start was setup in a certain way to fall back to some future native version. To deviate from that would be to either break any page that uses json2.js, or to ignore the forward compatibility built into the design of json2.js, for reasons of taste, rather than practicality. To take advantage of the improved speed of native JSON, you would force everyone to rejig their page to use the native library? to either totally rewrite their scripts, or update to some newer version of json2.js that falls back to what actually got standardised?
.
Oh well, nevermind all that. Millions of dollars in maintenance work is totally worth not being pushed around by some library author, right?
Breton, do you have any reference about that?
seriously who gives a fuck how its named. Its works, its there and its native (soon). Stop complaining.
@eyelidlessness, jQuery breaks standards (which where defined well before jQuery was launched) all over the place (.css() .click() .hover() etc.) and thats OK, since jQuery adds convenience methods which make all our lives a lot easier.
.
JSON.js adds never before seen functionality in JS, it’s THE first library that implemented JSON, it IS THE standard before it was an official standard.
.
Standards are created on utility thats commonly and widely used and preferably, through methods already know by it’s users. Ergo ‘parse’ and ‘stringify’. Before that, there was no JSON or JSON utility.
.
Before jQuery, there already DOM methods for manipulation and jQuery steered away from that to create an abstraction that was muuuuuch easier to use.
.
So your argument is actually the other way around, imagine if ECMA suddenly changed all DOM methods, it would break jQuery. And THAT’s why the method is called ‘stringify’.
.
And I still agree, it’s not well named, but THATS the reason it is what it is. NOT the other way around. Hope I made myself clear enough and that you stop using jQuery (or any other library thats build on standards for that matter) as an example.
.
phew.
ECMA or W3C
@igstan no, I was just there as it happened. One day there was a new library, called prototype, and one of the things it had was array extras, and it was neat. Then firefox added the same array extras, so they would work faster. Then a couple other browsers added them. Then they were standardized into ecmascript 5.
I could look into it more deeply if you want real evidence.
Ah okay, the inspiration is a little bit looser than I thought.
http://www.prototypejs.org/api/enumerable
but still a lot of those methods look pretty similar.
and also
http://www.prototypejs.org/api/array
@breton, prototypejs ported, collected and added a lot to JS we take for granted now ;)
Breton,
Let me ask again: was the justification for the naming convention of those methods that they needed to maintain “backwards compatibility” with Prototype? If so, that justification is wrong. If not, I don’t see how it’s relevant.
How do you figure? Adding to Object.prototype can break backwards compatibility only when adding in Javascript, not natively.
And if that is meant to justify never adding non-enumerable native methods to Object.prototype, then its logic extends to never adding any semantics to the language whatsoever. The new native JSON object may not break json2.js, but it might break some other library or script. How can they ever know?
Why is json2.js so special? How does ECMA determine which scripts to break and which not to break? This doesn’t make sense to me.
If some other naming had been adopted, it would not be hard at all for json2.js to be updated to support it. Nothing else would need to change. Yes, sometimes code needs to be updated when languages change. This is still the case even though json2.js wasn’t broken.
I’d say that when ECMAScript changes get implemented, millions of dollars in maintenance work is an inevitability. I think you’re exaggerating the consequences of breaking the single json2.js library, however.
Only one of the Array extras methods appears (at least by the same name) under Enumerable (and two under Array). Hardly analogous to the claim that JSON methods must maintain the naming of json2.js for “backwards compatibility” with that library.
* * *
V1,
I do. But more importantly, I give a fuck about why it’s named what it’s named.
No. Why is it that so many people insist on complaining about people complaining, insisting that those people stop complaining? Is it like… some kind of a competition to see who can be the most hypocritical by saying exactly the same thing? Uphill battle, my friend. If you don’t like my complaints, or the fact that I’m complaining, feel free to ignore me. I will not stop complaining because you don’t like it.
* * *
BenGerrissen,
jQuery isn’t “breaking standards” by providing convenience methods. Those standards still work. I don’t see how this is relevant.
You may be right. But json.js was not the basis of the ES5 JSON standard, json2.js was.
Parse and stringify did not appear in json.js, which came before json2.js. Your argument is incorrect.
I agree that standards are (or ought to be) created on common-use utility. I don’t think that carries over to naming conventions necessarily, and I certainly don’t think that it’s right for ECMA (or any other standards organization) to treat user code as if it’s retroactively part of the standard—to refer to json2.js or prototype.js or jQuery or any other library as if it is part of the ECMA-262 standard and therefore a source of “backwards compatibility”.
And so did Prototype. And Mootools. And a bunch of other libraries. All of which conflict. Which becomes retroactively part of the standard and a target of “backwards compatibility”, and which get broken or neglected?
ECMA doesn’t have any control over the DOM. And changing existing native methods (ECMA-262 or DOM) is not analogous to inventing whole new native objects and methods, which is what was done with JSON.
How the hell do you figure? There was never a JSON.stringify (or a JSON object) in ECMA-262 before.
You’ve made your argument clear (it was never unclear), but it’s still wrong. And why would I stop using jQuery or any other library? It has nothing to do with this discussion.
Agreed. And truth be told, I’d probably still prefer Prototype over jQuery if it weren’t for the fact that Prototype has stagnated while jQuery has progressed and become the de facto standard DOM library.
“How can you be right – when you disagree with me?”
@rasmusfl0e I went to your site, and I thought it was broken in firefox. I was going to warn you about it. But then I realized that your site’s navigation is just confusing and inscrutable. If you have a page saying “This is my work, have a look!”, and all I can see are two squares with diagonal lines through them, I have to tell you it’s damn baffling. I didn’t think to look and see that the navigation was changed. The change was not very obvious- since there’s no visual hierarchy it didn’t seem as though it had changed at all until I happen to look and watch very carefully as I clicked through the site.
@eyelidlessness
When new browsers that support native json fully replace old browsers that don’t, it would be nice to just simply get rid of json2.js so that users don’t have to download it anymore, and I don’t have to rewrite my whole site.
@Breton: Thank you for the I-thought-it-was-broken-but-it-apparently-wasn’t-warning, Breton :)
Great i love it!
Breton,
I think you’ve demonstrated that you’re competent enough to know that you wouldn’t have to rewrite your whole site if the spec’s naming had not been based on json2.js, and also to know that your argument doesn’t hold water for sites using JSON libraries besides json2.js, and also to know that it will be years before you can safely remove json2.js and expect all of your users to be able to use the native functionality. I think it’s you grasping at straws.
If you disagree with my premise—that it is unwise to treat favored libraries as retroactively part of the standard—argue against that point. What you’re arguing here is largely irrelevant and based on emotional appeal that doesn’t stand up to much scrutiny.
@eyelidlessness:
Re. your “Did you read my comment, or just scan it for things that didn’t seem right?” For what it’s worth now, yes, I think that phrase just stuck out at me and I didn’t read the context correctly.
that it is unwise to treat favored libraries as retroactively part of the standard
Make a better premise, because this one is faulty. For one, it did not become part of the standard “retroactively”. JSON2 was adapted by ECMA Standards since it was THE standard. JSON.js and JSON2.js also weren’t “favored” libraries, they where THE libraries that provided THE implementation of the functionality everything else are “convenience” libraries.
.
Also consider ‘getElementsBySelector’ and the entire debate on how to name it. I think we saw ~5 versions pass by at one time? An utter waste of time in a language where it’s crackerjack easy to create aliases and convenience wrappers.
.
I am also sure that in hindsight, Doug would’ve renamed it as he did with Object.beget, but then JSON2.js was already THE standard.
.
Stringify is ok, not perfect, but I can work with it.
timdown,
Thanks! I was wrong about that example though heh.
* * *
BenGerrissen,
Yes, they did. That is the fundamental part of the logic of calling it “backwards compatibility” to respect the library’s conventions in the standard. It has to have some point to look “backwards” to in order to be compatible with it.
How did json2.js become the standard? When was it standardized? We’re discussing the ECMA-262 standard, in case you’re not aware. And since json.js and json2.js conflict, how is one favored over the other?
Note first that this is a DOM API, not ECMA-262. Note second that the decision was made to make its naming consistent with the rest of the relevant DOM API, rather than use the naming convention of some favored library as if it had retroactively become part of the standard.
It didn’t become part of the standard until September 2009. You’re incorrect. You’re abusing the term “standard” to reflect a concept it doesn’t mean in this context. The standard refers to ECMA-262. What you’re discussing is a de facto standard. I accept that de facto standards are a real part of shaping a formal standard, but I don’t accept that by adopting them we are to treat them as targets for “backwards compatibility”. Doing so unnecessarily assigns them a value they don’t have.
Agreed.
* * *
I want to revise a point to Breton that I made earlier too:
(Emphasis mine.) This is a basic “best practices” issue. Whenever introducing a new global object or method in Javascript, it’s wise to default to the native version if it exists. json2.js is not special in this respect, and certainly not a predictor of future standards evolution, and certainly not warranted special privileges of influence on this basis.
Basically, we agree on the main topic and am just going to ignore your nitpicking on whats what wether you’re right or wrong… You’re entitled to your opinions, you’re just not making yourself popular by going at it in this way, but hey, to each his own.
.
Enjoy.
I’m not really interested in being popular, but I am interested how you think I should “go at it”. I’m not sure what else I can do but express my point and clarify where it’s misunderstood. I’ve tried to steer clear of making it about personality, instead focusing on the substantive facts and context. What am I missing? This is a genuine question.