Javascript

Javascript (also and more properly known as ECMAScript) is a programming language that is implemented primarily in web browsers in order to let scripts control the dynamic behaviour of a web page, such as what happens when the user clicks on some region of text.

Computational Class

Turing-complete

Programming Paradigms

Defined by

http://www.ecma-international.org/publications/standards/Ecma-262.htm

Implementations

Supported on Platforms

Things written in Javascript

Compilers targeting Javascript

Commentary

Javascript, now there's a programming language rags-to-riches story. Well, it still wears rags, but you know what I mean.

In the beginning, the World Wide Web was just a bunch of interlinked static documents, which was just fine. Hypertext, they called it. Then immediately it grew fill-out forms and queries which were sent to web servers, which could respond with dynamically-generated content, like the results of a web search, which was great.

And then along the way, the Web succumbed to the inviolable law of software engineering that states "Any sufficiently complex program contains a buggy, half-implemented, undocumented version of Lisp". If you've ever been on the receiving side of requirements, you might also know this as, "Can we add a scripting language? That'd be awesome." (Because taking a nice, predictable system and making it Turing-complete is always awesome.)

So, even though web pages at the time hardly justified being scripted, Javascript was born. And, to be fair, it's really not such a bad language for having been designed in two weeks. Of course, the name was pure marketing; it shares almost nothing with Java except curly braces.

And so the Web went through a painful period where Javascript was used to make sites that tried to stand out from the crowd by annoying the user in more advanced and petulant and irritating ways. And during Javascript's childhood, every vendor implemented it slightly differently, with different bugs and different reckonings of the DOM (the API that refers to the parts of a web page).

And then, Ajax happened, which meant, in essence, that, you could now use Javascript and XML to reload part of a page without reloading the whole thing. Which meant, in essence, that web pages started to look a lot more like traditional user interfaces. Which meant, in essence, that there was actually a (somewhat) justifiable reason for using Javascript.

And then a standard was written for Javascript (sort of) and jQuery was developed (which handled some of the discrepancies between browsers for you) and JSON took over from XML (but we still call it Ajax, not Ajaj) and vendors' Javascript implementations started to do JIT compiling and got reasonably performant and some clever wag coined the term "web app" and at that very moment it became an acceptable fact of life for a web page to hang or crash. (Because it's now an "app", you see.)

And then it got even weirder. Developers decided they wanted to run Javascript outside of the browser. Which, for the purposes of automated testing of the scripts used on web pages, makes some sense. But then some exceedingly clever people decided it should run on servers and that new, back-end software should be developed in it. And the next thing you know, it has an ncurses binding. I give up.

Our policy regarding Javascript on catseye.tc is as follows:

  • If you don't like it, turn it off.

    Unless it's one of the fancy pages that actually requires Javascript for some HTML5 craziness, like running an Esolang in the browser, the page should gracefully degrade when there's no Javascript. (The site is even decently readable and navigable without styling. So if you don't like our far-out background graphics, or you want the genuine experience of surfing the web circa 1996, try turning off CSS too.)

  • Use commodity components.

    There's still too much variation between different browsers that whenever we can use a third-party Javascript library such as jQuery that's been battle-tested on different browsers, we probably should. There's an argument that jQuery is large and bloated, but really, it's not that bad, and since we grab it from a CDN there's a good chance the user's browser already has it cached.

  • Keep it simple.

    Of course, the availability of many high-quality, battle-tested Javascript libraries is a bit of a double-edged sword; there is the temptation to use every library and plugin under the sun in a vain attempt to make the user's web experience totally bitchen, man. But one cannot underestimate the number of things that can go wrong, and that by Murphy's law, will. For example, clever proxies used by 4G providers which concatenate and compress the Javascript used on a page and include it inline. (Did you just assume that that Javascript file you externally referenced really was external? Oops.)