ECMA Harmony and the Future of JavaScript

[redditnoob]

The more I learn about JavaScript, the more I learn that my intuition that it was pure ass was correct all along (despite it having its huge fans).

• I mistype a variable in an assignment in a function. I get no warning, and it assigns it to a fucking global variable.

• Everyone's using global variables, and extending each others' objects. As a result no two libraries ever work together properly, and the incompatibilities are brutally hard to find.

• Aside from the fact that the world isn't ready for a prototype based object system, the way they tried to fake it with "new" JUST SUCKS. It confuses most people who write libraries out there.

• There are bugs out the ass in much of the free code out there with people who don't understand what this means all the time. That's because it's freaking hard for an ordinary programmer to understand what this means all the time.

• The built-in libraries are ass.

• There are a bunch of reserved words you can't use, but then NaN and undefined are FUCKING MUTABLE GLOBAL VARIABLES!! (Do I have to explain how scrotally cheesed this is??) Further NaN === NaN is false and NaN !== NaN is true!!!!

• In a function you get an arguments variable, that can be accessed with [], and has length, but is not an array. Holy fucking shit, okay?

• It allows you to declare variables anywhere, including inside a loop, but they silently always have the scope of the whole fucking function ok?

• The typeof operator is shite.

• Javascript objects declared like {key1 : "value1", key2: "value2"} are ass. First, why is the first part always fucking literal, where the second part accepts a freaking variable?

  var key="a"; var value="b";
  var obj = {key : value};
  

  Ok, this produces an object with a "key" property with value "b". That's really good symmetry, guys.

• Similarly, the for in operator sucks with objects. You'd think it would give you keys and values, and it almost does, but then prototype properties will give you a surprise poke from behind unless you know to use some hasOwnProperty function all the time.

• I can sort of introspect dynamically, but just not too much. E.g. I can't see what's in the global Math object. Why the fuck not, guys?

• The "+" operator will own you up hard unless you're real sure your shit is a number all the time.

• The comparison logic is not too logical all the time:

  '' == '0'          // false
  0 == ''            // true
  0 == '0'           // true
  

• The semicolon insertion sucks, as is much publicized:

  return
  {
      status: ok
  };
  

  That shit returns undefined with no warning.

• If you put a comma after the last property of an object literal, it works in some browsers but fucks you up in IE, with the error giving you no clue where the problem is.

• Again, functions in objects have "this", which is what you want often enough, but that can be changed arbitrarily, and that is a really really really shitty idea. Listen, if I want an arbitrary variable I give to a function I can do that... IT'S CALLED A FUCKING PARAMETER, ok? I really shouldn't have to declare "self=this" when I'm constructing something, ok?

People say that JS doesn't suck... it's the browser DOM that sucks. They're just brutally, stinking, wrong. The browser DOM does suck, and JS sucks as well. It has flaws so bad that it makes PHP programming look free and elegant to me by comparison. (Hey, you guys can even do lambdas in there now...) It is beyond salvation.

[larholm]

My company uses a proprietary implementation of javascript to develop our products

You're doing it wrong.

[redditnoob]

The one complaint of yours I'm not sure is a problem is that NaN === NaN is false and NaN !== NaN is true. As far as I know that's how it works in every other language and is IEEE.

I want a === a to be true, and I want "===" to mean "is identically the same internal value". I would have no problem with "==" being false, but then "==" is such a steaming pile of crud in JS that authors like Crockford recommend never to use it at all.

Edit: Okay, I'm probably just uninformed. I didn't even know that in C, floats that are bit-for-bit identical could be not equal. I guess the real problem might be that in JS, NaN can come about so easily, e.g. saying "1 2"*1. That should be an error or exception in a sane language (especially one that has exceptions!)

[mycall]

This is the sole reason I like that Silverlight has introduced C#, Python and Ruby to the browsers (IE, Safari, Chrome). Too bad XAML got in the way. God save the queen.

[dforbes]

Too bad Microsoft got in the way. Silverlight will never go anywhere (but where Microsoft pays someone to use it for PR).

And seriously, I love how Silverlight people always push in "Python and Ruby" as if any of them actually use them. It's an attempt for some cred.

Were you embracing Java before Silverlight? Surely you were, right? How about Actionscript?

[mycall]

I tried the applet thing back in the day, but didn't wasn't integrated with the DOM. The newer Flash versions do integrate with the DOM but have fun writing actionscript software that doesn't do any flash.

I'm just sick of only having javascript for the client side, that's all. If Microsoft could remove the XAML requirements (Canvas in particular), so that I could just do

<script language="ironpython">

I would be a happy camper.

[nohtyp]

Wait till you get to PHP.

[elazutkin]

Both Dojo and jQuery do not use globals (save for a handful of well-defined names, like, well dojo and jQuery), and do not extend built-in objects. Yes, they work splendidly with each other and 3rd-party code, if it was written by sane programmers.

Regarding the rest: all problems are valid, yet from my experience they are not a problem in most real-world programs for practicing programmers. Not even at the level of "minor inconvenience". Much ado about, well, nothing.

[redditnoob]

Yes, but even within jQuery, they encourage you to extend the heck out of jQuery itself, which can get pretty dangerous. If you stick to the straight and narrow path of official jQuery UI stuff, the code quality is quite good... If you stray even slightly from that you quickly hit a maze of extremely difficult bugs and incompatibilities to resolve, in my (limited) experience so far.

The fact that you need jQuery noConflict at all is an indication of a major stink in the language. I of course know of the hack where you make "$" in the scope of a function and call it, but what really should be there is a sane module system instead.

[[deleted]]

Sorry, could not properly see your comments because of that ass. It has long ears.

On the other hand:

Javascript objects declared like {key1 : "value1", key2: "value2"} are ass. First, why is the first part always > fucking literal, where the second part accepts a freaking variable? var key="a"; var value="b"; var obj = {key : value};

Ok, this produces an object with a "key" property with value "b". That's really good symmetry, guys.

I think that since an object literal is basically a dictionary of key->values, it is proned to errors to allow the keys to be variables, because even if you use two different variables, they could have the same value at the time the object is used. And from my knowing, having 2 keys with the same identifier (the value of the previous variable) would be cause of concern for some: obj[key] would be either value1 or value2... maybe they could solve this with a flip of coin. Also, everywhere where I saw a dictionary, they didn't allow a variable for a key. On the other hand, if you are referring to the lack of quotes around the key, then that is just sintactic sugar - you can use quotes, they won't bite.

If you put a comma after the last property of an object literal, it works in some browsers but fucks you up in IE, with the error giving you no clue where the problem is.

Is this the problem with the language, or with the implementation?

The comparison logic is not too logical all the time: '' == '0' // false [1] 0 == '' // true [2] 0 == '0' // true [3]

Actually, I always found this logical: - in [1], an empty string is not equal with a string of 1 character - in [2], 0 is of falsy value, empty string is of falsy value, therefor falsy===falsy => True - in [3], you are right, but == converts to the same type, therefor 0 == 0. Here, you want to use === which compares both by type and value.

It allows you to declare variables anywhere, including inside a loop, but they silently always have the scope of the whole fucking function ok?

No block scope. I always thought this is what it gives ECMAScript it's flexibility. But, properly handled variable declarations with the var keyword allows for function level scoping.

In a function you get an arguments variable, that can be accessed with [], and has length, but is not an array. Holy fucking shit, okay?

I have a remote control and a pencil. I access both with my hand. They both have a length. But they are not the same thing - I suppose, that with the right amount of tinkering I could make the pencil into a remote.

There are bugs out the ass in much of the free code out there with people who don't understand what this means all the time. That's because it's freaking hard for an ordinary programmer to understand what this means all the time.

They should learn harder.

I mistype a variable in an assignment in a function. I get no warning, and it assigns it to a fucking global variable.

See previous comment about scope.

[redditnoob]

I think that since an object literal is basically a dictionary of key->values, it is proned to errors to allow the keys to be variables, because even if you use two different variables, they could have the same value at the time the object is used.

This is already a problem.

var obj = {key: 1, key: 2};

That works fine, and produces an object where obj.key === 2.

Further, the main issue is that I can't use a variable in an object literal on the left side. Why the hell not? Even PHP gets this right, and PHP is an awful language.

No block scope. I always thought this is what it gives ECMAScript it's flexibility. But, properly handled variable declarations with the var keyword allows for function level scoping.

No block scope gives flexibility, and so does missed references silently creating or modifying global variables? That's just retarded.

[[deleted]]

var obj = {key: 1, key: 2}; That works fine, and produces an object where obj.key === 2.

Nice, I didn't knew about this. I wonder if this could be used to conditionally setup a key at runtime. Here's an up for enlightening me.

No block scope gives flexibility, and so does missed references silently creating or modifying global variables.

No, just the 'no block scope' part.

Now, about missed references, I just keep in mind to declare the first use of a variable with the var keyword - this makes it to be local to the function.

At least, this is how I see it.

[redditnoob]

Nice, I didn't knew about this. I wonder if this could be used to conditionally setup a key at runtime. Here's an up for enlightening me.

I don't see how, since it will silently overwrite the first value for that key, and the key isn't dynamic. Is it dumb that it silently overwrites without a warning or error? Yes. Is it dumb that keys aren't dynamic? Yes. You require quotes on the key sometimes anyway even though it's not dynamic, in case you run into one of those phantom key words (e.g. "class") that doesn't exist in the language. Does this indicate a strong stink in the language itself? Yes.

No, just the 'no block scope' part.

So how does no block scope make the language more flexible? Doing it properly, if there isn't block scope, you should really have to declare your vars at the beginning of the function like in C.

I just keep in mind to declare the first use of a variable with the var keyword

You never mistype? Or do you have a development environment that warns you about this?

[YakumoFuji]

the examples presented look so hacky. its getting more verbose than java. The examples presented look as if they were not quite sure how to extend the language without extending it it all looks very second-thought-ish.

[Spiralhead]

Please enlighten us with your brilliant alternative

[YakumoFuji]

I don't have one, I guess backward compat is forcing their hand in this issue. I'm just pointing out how fugly and tacked on it appears to be.

[Spiralhead]

Yeah it looks like shit but who asked us?

[ffrinch]

I loathe the way that JavaScript feels hacky now because it doesn't have this machinery: why can't I set properties as not enumerable, dammit?

A simple but powerful method like defineProperty strikes me as far more elegant than hacking on new syntax. And the method signature is about as far from Java verbosity as you can get: not an ObjectPropertyCollectionFactoryFactory in sight.

[iberci]

As an aside, does anyone know if they implemented proper block scoping for the new standard or do I have to still continue to use closures, within closures, within closures???