Just happened across this exchange.
This REALLY gives me a clue (many actually) on
productive ways to view and use JavaScript.

Ray Heinrich

P.S. Just babbling today so…
An old hippy “programmer” (she refuses any other
title) friend of mine read your exchange at my suggestion.
She told me that, for someone at my level, a convincing
myth was often very helpful. She’s an elitist who
sometimes wears a 50th anniversary LISP T-shirt with
a picture of John McCarthy on it made out of parentheses.
LISP, she says, is very much alive. She used it at Boeing
and knows people who use it for writing video games.
(I ask her for tips on writing in ALGOL.net just to bug her.)

So there appears to be at least _some_ selection bias going on here.

Alas, there seem to be no absolute numbers to compare against.

This is how I felt about Javascript about 2 years ago. Let me tell you what changed my mind.

Firstly, a lot of credit goes to Douglas Crockford. If you haven’t already, I heartily recommend reading this — it opened my eyes, and I kept reading. Fundamentally, Javascript is not an OO language with classical inheritance. It is a functional language with OO influences and prototypical inheritance. You already know this, I think, but your code doesn’t reflect it yet — so you probably don’t understand it on a deep enough level yet. Let me demonstrate:

For matters of scope, you should be doing:

function A() {
var self = this;
self.X = 5;
self.B = function() {
this.X = 5; // this refers to ‘B’, I’d think.
self.X = 10; // now we’re changing ‘A’.
};
};

Basically, alias ’self’ or ‘me’ or some other obviously-named variable to “this” as a first step. Gains you a lot of readability, and stops you from making debugger-unfriendly mistakes.

The reason that you’re having difficulty with early and late binding is because you’re thinking about binding instead of scope. Binding is always late-binding, so don’t think that you can get around that. Instead, think about capturing context with scope. You’re thinking in an imperative model, but you should be thinking in a functional way. Let me “functionalize” your example, and you’ll see what I mean.

var invariant = 10;
for_each(range(0,10), function(idx, item) {
$(‘#button-’+item).click(function() {
alert(item); alert(invariant);
});
});

What you have done here is separate out the invariant — which is what you want to bind “early” — and that makes the logic much clearer … and, IMO, it also looks much prettier. Do not use “for” loops, use something like jQuery’s $.each() or roll your own. “for” loops introduce a variable into the scope that will be handled badly by closures, and Javascript is a language that relies on closures for its power.

I consider the equality system of JS to be a silly hack (“===”? Come off it), but for 99% of things it doesn’t get in your way, so I can live with it. You seem to like strongly-typed languages, which is fine, but if you use Javascript you just need to get out of that mindset. It’s a barrier to your understanding, just blow it away.

Again, even if you’re streaming JSON, you’ll need to stream each attribute and other little data, and it’s very hard for a designer to make changes and see how things are supposed to work, especially if you follow some cryptic logic like Paul Graham’s Arc-based hacker news backend to generate the structure.

I think that when you get to stream JSON across, you’ll see that this isn’t as much of a concern as you might think it is. If anything, it forces you to think more explicitly about what the front-end needs, and that’s an excellent thing. When you get into the habit, you are able to visualise your objective much more clearly.

I had once found a minor security hole in JSON based JS

Heheh, yes, that’s been around since Day 1. Becoming very much a concern of the past, due to the browser implementations native JSON parsing that we have now, and libraries that do parsing properly even without native implementations. I class this one with “SQL injection”: easy enough to avoid, but people (through ignorance?) don’t avoid it.

In summary — I can see why you’ve had trouble with JS. But that’s because you’re trying to impose a strongly-typed classical system on it … it’s like trying to write Python as though it were C. It can be done, sure, but why would you want to? Get used to Javascript, read the Crockford article and go from there, get comfortable with it, play around a bit … and hey, you might ever get a bit attached to it in the end .

All the browser headaches aside, I have specific qualms with Javascript as a language as well. It’s nice to make the function a first class citizen as a variable itself; but to make it a class? That doesn’t make sense.

Consider this for example:

function A()
{
this.X = 5;
this.B = function()
{
this.X = 5; // Does this refer to the one from B or A?
};
};

There are tons of confusion about scope, what the “this” keyword refers to, and tons of other issues. If I just had a “class” keyword, object oriented programming would be so much more easier.

Even late binding and anonymous functions are really bad. Consider I have ten buttons with ids button-0 to button-9

for(i=0;i<10;i++)
{
var x = i;
$("#button-" + i.ToString()).click(function(){
alert(i); // should be late binding
alert(x); // should be early binding
});
}

I had huge issues making sure anonymous delegates and the binding and scopes work the way they are supposed to. You have to go through a massive hack to make early binding work, that involves creating another anonymous function (don’t remember, and too doped up with monorphine to care.)

Apart from that, let’s not forget the flimsy equality system, the type system that almost is, gentle encouragement to pollute the global namespace, the inability to query a HTMLElement properly unless it’s actually part of the DOM (I’ve had to use some

As for your suggestion to use a JS MVC and stream JSON, that’s relatively saner. I actually got to use Google’s internal JS library when I interned there. It’s called closure, and was originally open sourced but now it’s been taken down. It’s actually pretty good and might even give jQuery serious competition because it has so many features, but manages to segregate them into a way to cherry pick features that you want.

Again, even if you’re streaming JSON, you’ll need to stream each attribute and other little data, and it’s very hard for a designer to make changes and see how things are supposed to work, especially if you follow some cryptic logic like Paul Graham’s Arc-based hacker news backend to generate the structure.

My RoR friends don’t write any JS or HTML at all, they have some weird way of representing the hierarchy of content in their code, but ruby code for me looks like someone took out all the symbol keys from my keyboard, loaded it up into a twin barrel shotgun and shot me in the face with it.

Oh, btw, I had once found a minor security hole in JSON based JS. Since a lot of people use “eval” to deconstruct JSON objects, you can inject script into that.
so with a string like “}}};alert(“hello”);// we showed that we could make browsers of users execute unsafe code by sending them to tainted links with strange GET parameters. If you’re using the JSON.js library or Mozilla’s you should be safer from this hole.

Man it feels good to rant!

Well, I agree with you on the browser issue. Fortunately, most JS that I’ve written is for intranet apps, where I only have to code to one browser. Using jQuery, it generally works on other browsers, which is nice. Perhaps I’ve got a better opinion of it due to the environment I’ve used it in. The situation is getting better, though — I remember when we had to deal with IE5, and the horrible “layers” of NS4, and so forth. And then MS put out that ridiculous nonsense about closures being evil … sheesh! Nowadays, there’s more commonality than difference …

I agree with you on the testing, and the debugging. That’ll also get better, I trust, and it’s come a long way since having to write “alert” statements. Threading is coming — see the “web workers” from Mozilla — but in the interim, the only thing that stops setInterval/setTimeout from being used as good-enough replacements is a lack of mutex primitives.

We disagree on method. With respect, I don’t think that the correct thing is to generate the DOM on the server at all. I’ve found a RESTful client-centric approach to be much better: stream JSON to the browser, create your DOM there, and just send back JSON as you need to. This also minimises server load. Takes about 1.5x the time to set this up (although MVC is making it easier), but once you’ve got it set up for a particular application domain it’s a remarkably flexible and modular way of doing things.

I also agree with you on the language aspect: Javascript is, fundamentally, a good language (with some bloody idiotic features, such as making global creation very easy). However, Javascript+browser or Javascript+DOM interactions are painful, and I therefore try to abstract away as many of those interactions as possible with jQuery. These are the same interactions that you point to as being therapy material. Are you sure that your hatred should not be directed at the DOM/browser, rather than the language?

I am deeply offended by your comment. I own an “I hate javascript” T-Shirt and I stand by it. All the jQuery plugins in the world won’t save you from the hell that are regressions introduced on a single browser. I’ve written a good bit of javascript in the past and it still gives me nightmares bad enough to consider therapy.

As a language, it’s great – I can use anonymous functions, it has rock-solid closure support, loose binding, etc. I can extend classes on the fly with prototype(the language concept, not the library).

The problem comes in when you start doing it in the real world – you have to check for regressions on multiple browsers, and unless you’re patient enough to write functional-tests your app with something like Selenium or Webdriver, you’re going to find that one day, something breaks and nothing works. Unit tests like fireUnit or jsUnit won’t save you as dom manipulations can’t be easily tested.

Debugging javascript is a pain. Yes I know about firebug and Aptana’s debugger, but in a statically typed language, most of those kind of bugs don’t arise in the first place. Absolute lack of threading support, timers that are giant hacks, and such horribly different behavior across different sessions, let alone different browsers make it a really bad experience. jQuery and the DOM tree is nice, but it requires a lot of trouble, especially if you’re generating the DOM from the server and you need to keep your ids in sync with the one your JS expects.

The only thing is that with the web-apps coming into place, everyone _has_ to write javascript, and support atleast IE7, which is a big pain. One could use something like Google Web Toolkit, Webforms, script#, or any other framework which won’t require you to write javascript, but it significantly sacrifices power.

TL;DR:
Javascript as a language is fun to show off in a rhino shell at conferences, somewhat like them ruby blokes do, but when you’re writing it for a large browser-based application, you can’t help but hate it.

Javascript? EW