A thread came up last week about JavaScript on the Rudolph Hering Society list. I promised to repost my thoughts as a blog post for a larger audience to dissect:
Dave Hoover wrote:
Not everyone hates JavaScript. After digging deeply into (Chicago resident) Sam Stephenson’s wonderful Prototype framework, extending it, and using it extensively, I can honestly say I enjoy working with JavaScript.
I came to a similar point in the development of Selenium. I hated JavaScript enough because of browser compatibility issues to write a testing tool to fix it. But at the same time, I liked JavaScript enough because it let me do spiffy things in the client. Alas, I decided to write a testing tool… Sam took a different path and wrote a code library, instead. But the motivation was probably the same.
To kinda hate something at first, but then grow to love it… I believe it’s called “Stockholm Syndrome“.
I agree when Dave said, “At least for now, I’d rather deal with JavaScript directly than have it generated for me by another language.” But I don’t claim that dealing directly with JavaScript is right or necessary for everyone. For example, Python, Ruby, and Perl are really written in C under the hood. But only a handful of people in the world really need to know C. I’m happy I can go years without having to look at any C code whatsoever. I suspect most of the world feels the same way about JavaScript. Guido and Matz are to C as Sam Stephenson is to JavaScript. They are all-stars because they liked C/JavaScript enough to be productive in it, but also hated it enough to write a more productive higher level tool so the rest of the world wouldn’t have to do the same.
However, when you write to the C platform, everyone can talk to you with ease. For example, there have been lots of ‘mini’ SQL database engines implemented for every language. Gadfly is the one I know about for Python. HSQL for Java. But SQLite is becoming quite popular across all languages because it is “100% Pure C”. So support and docs get better because a larger community of developers can make use of the code. Another example– YAML libraries…. Because _why wrote Syck as a C library instead of Pure Ruby, I get to use his code in Python quite easily. C gets you language binding to all the higher languages quite cheaply.
In a similar fashion, because Sam’s Prototype library is 100% JavaScript, it’s now used by PHP, Ruby, Perl, Python, Java, and .Net shops. And that’s the best empirical argument I can think of that JavaScript is the new C.
It’s interesting that you choose to call it “Stockholm Syndrome“. As that comes into play in hostage situations. So really what you are saying is that JS is holding you hostage against your will. Well. I guess that makes sense.
I personally would love to get RubyScript instead. But since I don’t actually see that happen I will have to make do with JS.
Link | July 21st, 2006 at 3:25 pm
Actually, I’m seriously considering porting Lua to the JavaScript “platform”… I’ll post more on that soon. ;-)
Link | July 21st, 2006 at 3:27 pm
i vote for Lua
Link | July 21st, 2006 at 6:02 pm
I think Javascript is the new C because Javascript is the default language of the new platform everyone is trying to program on top of. It used to be that we programmed on top of operating systems, but now we do so on top of browsers. Speaking in the “native” language of your platform is always good.
Link | July 21st, 2006 at 9:56 pm
A big difference here is that operating systems were developed in “mostly” C, but browsers aren’t built in JavaScript. It’s popularity these days has to do with it’s ubiquity, but that is where the similarity ends.
With C, OS’s would have had to be rewritten in another language to provide the same level of integration with any other language. With JavaScript you just need a new ubiquitious language. That would take time, but is measurable in years, rather than decades. An order of magnitude can make a big difference.
Link | July 22nd, 2006 at 1:16 am
Ryan, I guess I’m just trying to make a different point– that JavaScript (and the web) is the new ubiquitous platform that C used to be (and okay, still is).
Just like writing a C library makes that library more accessible to more programming languages, writing a JavaScript library does the same thing for web frameworks.
Separately, I’m seeing JavaScript becoming the new “compile to” target. Example: Rails’ Ajax helpers and Google’s Ajax toolkit compile to JavaScript, they abstract stuff away so you can stay in the safe confines of Ruby and Java, much the same way Ruby and Java protect folks from the ugliness of C.) Howerver, that server-side Ruby and Java code can’t really be shared between framework, just like it’s hard to share a pure Python library with Ruby. But when good stuff (like Prototype) is written in JavaScript, other web frameworks can barrow the goodies easily. I hope I’m making sense, here. :-)
Link | July 22nd, 2006 at 1:49 am
Yes you are making sense, in fact I wrote about the same “compile to” trend a bit back at http://ryan-technorabble.blogspot.com/2006/07/javascript-vm.html.
My point is there is a point where the analogy ends, and that could make all the difference in the long term longevity of the language.
It’s not easy to replace JavaScript as the ubiquitous language, but it’s not that hard either. If you convinced Microsoft, FireFox and Opera to support a new language, within 3 years you’d have 98-99% coverage. Supporting an extra language is just extra code in this case.
Changing from C at the OS level however is a completely different question that requires not just a new feature from existing products, but entirely separate products, and the infrastructure built on top of them.
I won’t argue with anyone who uses JavaScript today, because clearly it’s the best option available, today. But at least in my opinion, it’s a poor medium, and far better could be designed, and so I’m left wondering when (and somewhat if), someone will step up and provide that alternative.
Link | July 22nd, 2006 at 12:24 pm