JavaScript as a programming language

JavaScript has a bad reputation. It does have a few warts, but at its core it’s an okay language, and much of the ire ought to be directed at its users instead: amateur programmers with poor taste. JavaScript can’t be blamed for making it easy for them to implement their ill-considered ideas, but it often is. It is also significant that JavaScript has a somewhat unique relationship with its “users”, in the following sense. With most programming languages, one doesn’t know one is using the language unless one is programming in it. But think about what it means to have JavaScript enabled on your browser: you are basically inviting every random website to run code on your browser, and while your browser happily gives up control over all its aspects to the random code, it gives you no control over what code runs! Is it any surprise that a lot of people simply hate JavaScript for what it makes possible? The only surprising thing is that it took so long for control to be returned to the user of the browser, in the form of Greasemonkey. “Client-side” is a misnomer when only the computation happens on the client side but everything is decided by the server.
JavaScript does have its faults, though, and a strange history. It was thought-up at Netscape by Brendan Eich as a way for web pages to interact with the internals of the browser (Netscape) on which they were being viewed, and such was the popularity of Netscape at the time that Microsoft was forced to implement identical controls into IE so that these pages would work in IE (how times have changed). JavaScript having always been strongly coupled with the browser, there is a lot of confusion among users about where exactly the language ends and the set of interface elements of the browser — the DOM — begins. While both the language and the DOM have been badly scarred in the browser wars, with all parties to blame, there does exist a core of the language that is perfectly usable (even, in some ways, good), and as long as you don’t stray from it, you’ll be just fine. (For example, there is something called “eval”, which you should never use — it leads to the medireview problem, for one.)

Oh well, there was a point to this post when I started, but I’ve lost it now. :P

5 Responses

Javascript has certainly seen it’s share of collateral damage from the browser wars… Now that it’s recovering, things seem to be getting interesting… Earlier, we were happy living with this cross-browser compatible “core” as you call it. It was restricted but simple. Now that the dom and javascript feature-sets are seeing some serious action (standardization/optimization)… json, functions as objects, and other things that I used to shy away from are beginning to look both feasible and compelling. Client side computing power has grown and we have some very good javascript frameworks to hide the ugliness…

As a user, I am not sure I like things that much…. There is stuff like this and then stuff like gmail. As javascript gets more complex, the line between bad and good will blur and soon there may be a time when I wouldn’t know what to block and what not to…

As a developer, I think it’s inevitable… Javsascript will live and prosper. Might as well take advantage of it. The language is good.

Also, another idea I have been playing with for sometime is reading up on ecmascript, the parent language of which this is a dialect… looks interesting…

And the kind of stuff in your link is exactly what I think is bad about the state of things: every line of JavaScript code that ever executes runs on *your* browser. Why doesn’t your browser let you control what runs on it? Why doesn’t it warn you when some site tries to take control of your mouse, window, browsing history and what not? This is (to exaggerate a bit) like the Trusted/Treacherous Computing issue on a minor scale.

BTW how can you bear programming in JavaScript without using functions as first-class objects? :)

Also, ECMAScript isn’t the parent language, it’s simply the result of an attempt at standardising everything that was in Netscape/Mozilla’s ‘JavaScript’ and IE’s ‘JScript’. (So ‘ECMAScript’ is in some sense the correct name to use in many contexts…) But both implementations (and other browsers’ I presume) do not strictly follow the standard document, and being a post-facto standard, it does nothing to fix the mistakes that were made in the design of the language. Thus, apart from language-lawyering, I see no point in looking at ECMAScript. As long as Microsoft is a player, nothing depends on the standards anyway.

Oh I used to have a very touch but only with a 10 ft pole and wash your hands afterwards attitude towards javascript till I saw what jquery and prototype were being able to do! As for ECMAscript, I stand corrected. I really didn’t notice that it was a post-facto standard.

As a langauage, javascript itself is very capable, it is only the flawed implementations and differences between browsers and the engines that make it such a big pain. How many other main stream functional languages in common use can you think of?

The fact that is has such a simple system for create pseudo Object-orientated classes, and has been used for so long without developers realising either the true nature or the real power of the language is a credit to flexibility that was originally designed into it.

But at the end of the day, bad programmers will write bad code.

If everyone continues to regard javascript as a poor cousin to ‘proper’ languages, then it will stay that way.

The new libraries, like Prototype, JQuery, YUI, MooTools etc are all very nice examples of language extensions into the Browser & DOM domains, but they still fail to solve the underlying problem.

However, I am pleased to see new tools like JSTR appearing that seem to targeting these types of problem.

Exactly, it’s the fact that Javascript is the most mainstream functional language that makes it worthy of respect :) [This does not mean that everything about it is good, it does have some pretty bad ideas: its “secret linkage” system for one.]

Another thing I had in mind before writing this post (but not while writing it, unfortunately) is the fact that JavaScript, being loosely typed and dynamically typed, gave off the impression of being “not a real language”: something like shell scripting. (Its name didn’t help much either.) This was before languages like Python and Ruby became popular enough to make it clear that dynamic typing was perfectly compatible with being a “real language”, and possibly even a good idea. (They are both strongly typed, though, and don’t behave like JavaScript’s “1”+1 = 11, which sounds like a kindergarten joke.) (The Lisps don’t count.)