It's universal because it's the only language that runs in the browser, not on its merits though. That alone made it big and ubiquitous. If Python had been picked as the scripting language for the web, or even Lua or Ruby, they would be the "universal" languages.
And how many new native apps were submitted that day?
Calling it a "trend" is a bit over the top, imho.
Also consider the nature of the app — basically to display some content.
How is the rise of the (unfortunately) sole technology that the ubiquitous multimedia platform of the beginning of the 21st century understands "surprising"?
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 :/
> How is the rise of the (unfortunately) sole technology that the ubiquitous multimedia platform of the beginning of the 21st century understands "surprising"?
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.
Similar story for me. Except that in 2010 I re-learnt JavaScript and discovered how beautiful, flexible and powerful it can be as a client side / server side language
I've been node'n it up a bit myself lately. The language is easy to write, pretty easy to get things done, and server-side node provides a lot of great libraries.
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).
Adrian - I have and it is a very useful tool. I guess my main gripe is the fact that the tool set is there in some form, but each has its area and none of them are really connected/integrated.
I suspect the toolchain will eventually get there, but it is a big step back if one is used to more integrated ecosystems.
The title is unfortunately ambiguous. I think I said I was surprised it took so long for JavaScript to take off as a language for serious Web work rather than it being surprising full stop.
There was JavaScript (including the good parts) before Douglas Crockford started disseminating his ideas about the language and long before jQuery was released. So it was like a powerful and possibly quite elegant language all along, but it needed to be 'discovered' and 'evangelized'.
With respect to JavaScript, it's like front-end developers are all enlightened today, after living in the dark ages for about 10 years.
Consider that in the browser, JavaScript is (with a few minor exceptions) the closest to a universal scripting runtime/VM that we can get. Targeting the browser, therefore, requires compiling down to JavaScript. So JavaScript (the language) and CoffeeScript can both be awesome in the way that Scala and Clojure have their different niches on the JVM.
I remember back in high school, I think like 1998 or so, my friend told me, "You should really learn Javascript really well. It's going to be really big and around for a really long time." I laughed at him.
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.
As the title is ambiguous, my surprise is at how long it took for JavaScript to gain the stature and position it has now, not in it actually making that rise.
There's a theory that languages hitch a ride on platforms that do something useful, as a way of "scripting" (customizing or configuring) that platform. The obvious one for Javascript is the browser, but we can see others: C for unix; perl and PHP for the server-side; ruby for rails; objective-C for iOS; C#/VB for Windows/Office and so on. Though not all languages seem to fit this, e.g. Java.
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.
JavaScript is a strange beast. The semantics of the language are, in my opinion, awesome and awful in different ways. Awesome: prototypes, first-class functions, dynamic function scope (not sure if there's a proper name for this), jQuery. Awful: the this keyword is confusing (but powerful once you learn it), type coercion, the API.
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.
> the document.getElementById sort of operation which looks like it was designed in 10 days (all due respect to Brandon Eich)
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 you're generally right, you must not forget about Harmony Proxies and all that meta-programming fuzz.
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.
Could you explain what you mean by "in-place method mutation"? With an example in javascript maybe? Is it just about adding or replacing a method on a type (or an instance), or do you mean something more complex?
> For all intents and purposes, Javascript's so-called prototypes are shitty single-inheritance classes without the sugar.
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.
> I am referring to the call and apply functions which allow the user to set the scope of the functions during the function call.
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.
38 comments
[ 2.8 ms ] story [ 97.8 ms ] threadThe 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).
[1] https://github.com/dannycoates/node-inspector
I suspect the toolchain will eventually get there, but it is a big step back if one is used to more integrated ecosystems.
With respect to JavaScript, it's like front-end developers are all enlightened today, after living in the dark ages for about 10 years.
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.
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?
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.