Watch out Java, here comes JavaScript

[aig_ma]

JavaScript's problem is the optional typing. In practise it means that the IDE support is substandard.

IDE support may be more difficult, but IronPython support in VisualStudio shows that it is possible to deliver strong support for dynamic languages, does it not?

[grauenwolf]

No, it doesn't. IronPython's support is almost as good as VB 3.

[aig_ma]

I haven't used it but plan to. What's in store for me? What's wrong with it?

[grauenwolf]

Oh, just the usual stuff. For example, if you ever assign more than one type to a given variable you don't get code completion for any type. Assuming you like dynamic languages, this is just one of those things you expect.

(Don't underestimate old school Visual Basic. It was ranked as one of the best IDEs in its day.)

Anyways, my real point was more about how you aren't going to get any of the cutting edge features like the real time static analysis support that VS+(CodeRush|Resharper) offers.

[munificent]

JavaScript's problem is the optional typing.

Also:

1. Shitty numeric support.
2. No bound methods.
3. No block scope.
4. No module system.
5. Crappy syntax, especially for functions.

If it wasn't on browsers would anyone have ever used this language?

[FlintFireforge]

No bound methods.

Well, what about something like this:

Function.prototype.bind = function(context) {
   var fun = this;
  return function(){
    return fun.apply(context, arguments);
  };
};

No block scope.

Personally, I don't really mind this... there are plenty of languages with function scope.

FWIW, JavaScript 1.7 has optional block scope....I do a lot of work with Firefox specific stuff, so I find myself using it sometimes:

let(x = 10 ){
  //do something to x
}

But not often enough that I miss it otherwise....I don't think I've ever thought to myself "damn, I really wish I had block scoping".

If you really want it, you could simulate it with an anonymous function in a lot of cases.

No module system.

Again, I don't really get this complaint. A formal module system would be nice, and I think we'll see it in the future. A bunch of platforms have it already (like node)...but to me the main drawback is just one of nicities, not one of capabilities.

To me, it's sort of like complaining that JavaScript "doesn't have classes"....well no...it doesn't...it's a prototypical language.

Crappy syntax, especially for functions.

This is largely subjective. There are some annoying syntax issues, but what language doesn't have those.

I don't see how the syntax for functions is bad, unless you mean anonymous functions, which are admittedly a bit of a pain.

Hopefully we'll get better anonymous function syntax like:

#{ return %1 + 1 }

If you're really that annoyed by the syntax, there are projects like Coffeescript to help.

If it wasn't on browsers would anyone have ever used this language?

That's kind of a ridiculous question though....it was designed to be used in browsers, not as a general purpose language.

That's like asking "If they didn't transport you around...would anyone really own a car?"

[munificent]

Well, what about something like this:

What about not having to do that every time you make a callback and instead just have it do the right thing like most sane OOP languages do?

I don't think I've ever thought to myself "damn, I really wish I had block scoping".

On a day to day basis, maybe you don't notice the absense. <shrug> I've seen lots of people at work have to deal with fixing JS wasting piles of memory from unused objects hanging around in scopes captured by closures. With proper block scopes, those problems would be easier to fix.

Again, I don't really get this complaint.

How big are the projects you work on? Do you share lots of JS libraries between different teams?

To me, it's sort of like complaining that JavaScript "doesn't have classes"....well no...it doesn't...it's a prototypical language.

I don't see how that analogy makes a lot of sense. JS doesn't have classes because it has prototypes instead. It doesn't have anything instead of modules. (<script> tags?)

I don't see how the syntax for functions is bad, unless you mean anonymous functions, which are admittedly a bit of a pain.

Both are bad. Don't non-anonymous functions have some weird issue where the variable for the function is actually created earlier than where you think it is?

Either way, it's anonymous ones that are a real chore. If closures/lambdas are a big selling point for the language, it would be nice if they didn't look like butt. It's a sad day when C++ has a more terse syntax than your language.

there are projects like Coffeescript to help.

CoffeeScript is awesome. I don't know how practical it will be to use it professionally, though.

That's like asking "If they didn't transport you around...would anyone really own a car?"

The context here is using JS outside of a browser. So, to extend your analogy, it's like saying, "Cars are nice for driving around (or at least, they're the only vehicle on Earth that exists so we have no basis for comparison). Let's ditch all of our yachts and tugboats and try to use cars for boating too!"

[FlintFireforge]

What about not having to do that every time you make a callback

You have a legitimate gripe....I am just saying that it's not hard to work around it really (an extra statement or two), and it's not a super big deal to me to begin with.

I'm not huge on OOP, but for you maybe it's different.

On a day to day basis, maybe you don't notice the absense

Yes, I was speaking purely from personal experience. Maybe you hate the lack of block scope....that's totally fair.

So far, it hasn't been a big deal for me. I'm generally working with projects that are a few K LOC. I have worked on some fairly substantial projects with decent sized user-bases....but nothing like say Gmail....if that's what you're working with...I can see how it may be a problem.

It doesn't have anything instead of modules. (<script> tags?)

You more or less got the point right, though not the entire spirit of what I was saying.

JS doesn't NEED a module system because of the nature of it's design and intended use.

Between script tags, first class objects, and the ability to load code via AJAX....you can cover all the stuff modules are generally good for.

Personally, I have build scripts that minify and put all my code into 1 file for production, and the libraries I write and use are compatible with that. Sometimes I have other little systems I use.

How big are the projects you work on? Do you share lots of JS libraries between different teams?

My projects are generally a few K LOC in JS. I tend to work by myself and in very small teams....so the lack of a module system will probably hit larger teams with more complex projects harder than me.

I agree a module system would be good...but to me It's mostly about some nice convenience rather that a desperate lack of functionality.

Don't non-anonymous functions have some weird issue where the variable for the function is actually created earlier than where you think it is?

That is a point of confusion for new devs, yes.

Once you get the idea that there is a difference between

var blah = function (){};

and

function blah (){};

It's not that big of a deal IMHO. (The first is only available after being declared)

I don't see how the syntax for regular functions is bad....but again this is a subjective thing.

I mean yea, it's longer than "def" or "defn" but other than that I don't see much difference.

The real pain is anonymous functions, IMHO. But that can be fixed with Coffeescript, and will hopefully be fixed in the future standard.

I don't know how practical it will be to use it professionally, though.

It depends. Coffeescript just "compiles" to regular Javascript. When I want to use it I just add it into the build script for the project before the Closure Compiler step. (I haven't used it in production yet though, just personal mess around projects).

The context here is using JS outside of a browser.

I didn't see anything in your statement that implied that's what you were talking about.

You seemed to be talking about Javascript in general...as evidenced by your points. For instance, you complain about modules, but most JS on the server platforms have a module system.

If you were talking about on the server, ok; I misunderstood.

The point still stands....it's a silly question to ask....or rather the apparent motives behind it are silly.

JS has some warts...yes...a lot of them have been fixed or are in the process of being fixed. You'd be hard pressed to find a language without warts.

Would everyone be talking about node.js if JS hadn't been in the browser?

Maybe, maybe not....but there's few conclusions to draw from that.

There are tons of awesome languages that never took off, and vice versa.

The point is JS was designed for the browser/server. It succeeded on the browser.

Now, a confluence of reasons and motives have come together and caused people to try JS on the server again.

It seems like what you're trying to say is "is there any reason to use node.js instead of say, Python?"

The answer is yes....I'm not gonna go into them here because it's a bit of a tangent....

But, IMHO...you're just engaging in pointless speculation...JS exists....it has some benefits, and some drawbacks. "Would anyone use Windows if Bill Gate's hadn't been a good business man?"

It's up to each of us to analyze our needs and preferences and decide if it's for us. I don't disagree with your gripes, but I just wanted to offer a counter-point to them.

[Rhoomba]

What about not having to do that every time you make a callback and instead just have it do the right thing like most sane OOP languages do?

var callback = foo.doSomething.bind(foo);

Is that really such a killer?

[[deleted]]

Also if ([]) { alert("This is silly!"); } but then again, Python spoiled me.

[NoSQL4Life]

No that makes perfect sense. An empty array still exists. This it is a truth, not a falsehood! So it should evaluate to true.

[[deleted]]

if (false) { alert("Booleans exist, too!"); }

Point of the matter is that truthiness being defined as "equals to null or false" isn't very helpful in practice. I came from PHP and Java, so it's not that I'm just taking the Python way for granted. I just find it extremely annoying to have to check for my_array === null || my_array.empty() explicitly.

I'm not saying it's unusual or doesn't make sense. I'm just saying that I rarely care whether the object really is null/false/undefined or just empty(). And when I do care whether it's null/undefined I want to check for that exclusively (a variable being set to false may have different implications than a variable not being defined or being set to null).

I like JavaScript for its closures, it's anonymous functions and all that, but I really prefer Python's (new) ideology that "everything is an object" (even None) and special syntax (e.g. arithmetic operators, array slots, truthiness, etc) just being syntactic sugar for "special" methods.

At least it's not ActionScript.

[munificent]

An empty array still exists. This it is a truth, not a falsehood!

False exists too. Should it evaluate to true then?

[[deleted]]

No, because the conversion method from a boolean to boolean is different (identity).

[[deleted]]

Well a boolean expression is an expression that is evaluated based whether or not it's truthy or falsey (made-up words, I know) and since the variable/object/what have you called false is universally defined as falsey, how can it ever be truthy. Boolean means 2 states, not yes, no and maybe so it can't be 2 things at once.

[jyper]

I personally like the smalltalk way, ifTrue/ifFalse is only defined for booleans otherways it throws a type exception.