The surprising rise of JavaScript
radar.oreilly.com
radar.oreilly.com
I think it's actually an instance of the simple idea that products are only adopted when they meet a need - an "application" of that product. Hence the term "killer app" for a new technology. Platforms are often products that are needed in themselves; therefore, anything that improves them a bit, expanding their capabilities and usefulness, is also needed. It seems quite common that a language, in itself, doesn't meet a particular need; similar to the idea that code, in itself, doesn't solve problems; and pure mathematics, in itself, isn't of practical use. All these need to be applied to a problem. (Of course, some people do adopt all these despite their "uselessness" - it's just that this is a tiny minority).
In addition, people need to know about it (you can't adopt a compelling solution to your urgent problem if you've never heard of it). A successful platform helps here too - its scripting language is right there, installed, ready to use even before you need it.
In the case of Java, it seems to be have been useful in itself, because it was safer and easier to use than C and C++; it rode the rise of "OOP"; had a reassuring industry backer (Sun) and complete toolchain, libraries, support; and was heavily promoted by Sun. At that time, python, ruby and javascript were slow (because of slow hardware and lack of optimization) and C# didn't exist.
BTW: A blog/essay introduced the term "scripting language" to describe C (which is striking because C is not one, by the usual definition), but I've not been able to find it since.
So people bend over backwards to make javascript workable, improving it, adding libraries, finding the good parts, writing front-ends for it, writing back-ends for it, because it is the scripting language of the browser. If you do all that, is it still javascript? Yes, in that it uses the adoption channel of javascript, and maintains compatibility with javascript as an interface. So Javascript is no longer a thing, but a conduit - a platform customized by other scripting languages.
The standard API is the reason that people care about "the good parts" of JavaScript. jQuery is so popular is because it allows you to turn away from the document.getElementById sort of operation (ugly code) and turn it into $("#id").filter().each().etc().
People don't like JavaScript because of what it is, but what it can be. There are so many examples to choose from: jQuery (DOM API, data requests, standard library "extensions"), jPlayer (multimedia), Node.js (server, native API), Mustache (templating), Meteor (dynamic MVC). I am by no means an expert, but I can appreciate that JavaScript has turned into a serious language. JavaScript is not the holy grail of web programming languages, and I am sure that something greater will succeed it, but for now there is a lot we can do with it.
document.getElementById() isn't part of JavaScript but part of the DOM Level 2 spec that came out years after JS.
JS was first seen in Netscape 2.0 in 1995 whereas DOM level 1 was specified in 1998 but didn't in fact yet contain document.getElementById. That one was added in DOM Level 2 in 2000, so five years after JS.
As such it was not designed by Brendan Eich, nor was it created in 10 days.
No. This is the work of a committee that was heavily influenced by the way Java does it which is understandable because when DOM1 came out it looked like Java is going to be the be all end all of Computer languages.
The "library" that comes with JS is really small (methods on String, RegEx, Date and Array). Everything else we owe to the W3C which has created an API that was all but made for the language it was going to be used from most of the time.
(edit: I got my dates and dom levels mixed up - fixed)
Meh. I still have to write that rant, but javascript's "prototypes" are a boondoggle, they've got nothing to do with Self's prototypes[0] and don't provide anything more than classes do in nice dynamic languages (you can, in fact, do more fucking around with Python's types than with Javascript's prototypes). For all intents and purposes, Javascript's so-called prototypes are shitty single-inheritance classes without the sugar.
> dynamic function scope (not sure if there's a proper name for this)
Not sure what you mean by "dynamic function scope", since you don't seem to like `this` (which is indeed complete garbage, but is sorta dynamically scoped) I'm guessing you mean lexical closures? The part where a nested function has read/write access to bindings created in its outer functions/scopes?
> for now there is a lot we can do with it.
There's also a lot we could do with Fortran and Cobol. That's no bloody excuse.
[0] in Self, prototypes are just the thing you clone to get a basic object, they're just a template. They're not a unit of code reuse or inheritance: that's the job of mixins[1]
[1] which, again, are very different from what you get in JavaScript or Ruby (though Ruby is closer): in Self, a mixin is an object you link to your own via a "parent slot", a special type of slot used for message resolution. When a message is sent to an object, the runtime first checks all of the object's non-parent slots and if there's no match it follows the parent slots recursively to try and find a slot matching the message.
While the final result of a prototypal class hierarchy is in fact very similar to pseudo-classic inheritance, remember that it's just the result of an internal, manual, modifiable process.
All of which (and more) is available in class-based dynamically typed languages
How would you do in-place method mutation in something like Python or Ruby?
a = "hello"
puts a.size #=> 5
class <<a
def size
1
end
end
puts a.size #=> 1
foo = "Hello"
def foo.to_s; "Hello world!" end
foo = "Hello"
old = foo.method(:to_s)
foo.define_singleton_method(:to_s) { old.call + " world!" }You're right. I would much rather have Java's or C++'s inheritance models in JavaScript. JS's object model is mutable, which is a plus for me, but it is far only language with mutable object methods or properties. I'll have to move prototypes from the "awesome" pile into the "meh" pile.
> lexical closures
Beyond closures, which I am glad to see in JS, I am referring to the call and apply functions which allow the user to set the scope of the functions during the function call. Again, I am hardly an expert, so the term for this escapes me. Your reply has been very helpful in that regard.
> There's also a lot we could do with Fortran and Cobol. That's no bloody excuse.
Very true, but I'd really like to know why you would put JS in the same class as Fortran and Cobol.
Ah yes, so it is indeed about `this` and its dynamic scoping.
I can't say I'm much fond of it, I'd rather have correctly bound methods (à la python) and actual, optional dynamic scoping when needed (à la Common Lisp)
> Very true, but I'd really like to know why you would put JS in the same class as Fortran and Cobol.
I don't, I'm just saying being able to do "a lot" with a language does not mean the language is good in and of itself, and Fortran and Cobol are good examples of that: few under 50 will try and defend them (as opposed to PHP, an unmitigated disaster of a language which still finds defenders), and there are fucktons of code written in these languages and still running.
The fact that we still haven't found a way to use anything else easily after about 15 years and are still being somehow coerced into developing with it is what's surprising really :/
I recall that 14 years ago DHTML was the all the rage and javascript was the key to DHTML. So I took up JS and bought books and went in head first.
Conclusion: it was impossible to take that language seriously. Javascript was a hack.
So for me, the rise of javascript as anything more than a browser helper language has been very surprising. I still have some prejudice towards it. Maybe others feel the same way and knowing how O'Reilly comes from the UNIX tradition, I'm sure that's what they meant with that title.
That said, the development ecosystem around Javascript is very immature. To really write decent amounts of server-side JS as a team, people often employ linters and other things to sanity check their code. Debugging? Mostly printf's (or equivalent). Scoping rules can also be pretty annoying.
It is useful for getting things done, but it generally isn't my first choice (at least server side).
I suspect the toolchain will eventually get there, but it is a big step back if one is used to more integrated ecosystems.
Funny thing is that ended up going into embedded hardware; he almost never touches Javascript, except for some personal stuff. I still find it mindboggling how right he was, but part of me still feels like he was just shooting in the dark.
With respect to JavaScript, it's like front-end developers are all enlightened today, after living in the dark ages for about 10 years.