I had an enlightening discussion with one my coworkers today about JavaScript. He's been a good resource when I want practical knowledge about how JavaScript programmers work. All of my knowledge of the language has come from the specification and is from a compiler writer's perspective, which makes it easy to miss concepts that are obvious to anyone who actually works in the language.
I've been having an incredibly hard time wrapping my mind around why anyone would want to use JavaScript. To me, it's truly a horrible language that was obviously thrown together with very little refinement. It's not that I don't know how to get work done in it. It's that I don't know why I'd want to do work in it in the first place.
During our discussion, I came to a realization. There are short-term programming languages, and long-term programming languages. In some languages, you write code intending it to be used for decades. In other languages, you write code without that intention. A convenient split for these time frames is web programming versus desktop or server programming. When you write a desktop or server application, it is expected to live for a long time. You expect to refactor the code, evolve the functionality, etc. You don't expect to have to rewrite it for a while. However, when you write a web application, it's implicitly understood that it only needs to work for a short while.
If you don't believe me, check out the totally off-the-cuff timeline I came up with. 15 years ago, we were all writing static HTML web pages. 12 years ago we started adding dynamic information via Perl. 10 years ago we began using applets written in Java. 7 years ago we started to switch our Perl code over to PHP and JavaScript. 5 years ago we started to ditch the PHP code for Ruby and Python. 2 years ago we started building up AJAX frameworks. By and large, every few years "the next big thing" comes along in the web space and we rewrite our code.
That's not to say that mistakes aren't made on both sides. We've all seen web applications that seem to live forever and evolve like desktop applications. Similarly, what desktop programmer hasn't produced terrible code which barely lasted a few months before being rewritten entirely? But the generalization holds true -- web applications are typically more short-lived than desktop applications.
This is why I have a hard time wrapping my mind around why people use JavaScript. The language doesn't support access control, or type safety and I find that to be a flaw. However, I'm looking at it from a long-term perspective as a desktop programmer which is incorrect. I should be looking at the fact that it's blindingly easy to just blast some code onto the page and hack it together to work. That's the "web way!" That's also why I would make a terrible web programmer.
I share your feelings about JavaScript.
It seems that I just cannot get the philosophy behind it. Though it seems that some degree of encapsulation can be achieved, the syntax makes this kind of stuff just horribly unreadable (commas in all kinds of strange places) and it always feels hacky. I think I've been spoiled by the reasonably clean RB-syntax, and even Java which I quite like (or nowadays also Groovy which I like even better) or PHP are less scary to me than JavaScript.
Concerning your remarks about the timeframes: I prefer clean, readable code in all cases - whether the application lives only for a few weeks or for decades. And a programming language's syntax and its access control facilities etc. for sure contribute to readability.
I think a lot of people agree, even those people (especially?) who live or die with their web apps. That's why Google made GWT - they needed to make powerful, maintenable web apps. No way they would do that in JavaScript, so they use Java that gets compiled down to JavaScript, HTML and CSS.
I think it comes down to, as a web programmer 8 years ago, 5 years ago, 1 year ago, what else do you use? What else can you use to mimic or use client side functionality that users want to see in the web app you create. They want 9 textboxes they enter to sum up without having to post back. That is why AJAX is just on top of javascript, what else is there?
@Steve -- that's my point; in the web space, there's very little else aside from JavaScript. I think this mentality of fire-and-forget languages for the web is going to come back to bite people in the ass. More and more we see people trying to bring the desktop to the web (like AJAX and Adobe Air). This means we're finally starting to see more reusable frameworks for the web space. Unfortunately, they're all made with unmaintainable languages like JavaScript and therein lies the problem. There are cleaner scripting languages out there, but they've not gotten as much traction as tripe like JS and perl.
I think you're misreading the indicators here. I don't think these are long-term or short-term languages, rather I think it's a matter of project scope. Mostly, JavaScript is used to supplement HTML, so most of your web site is HTML, and bits and pieces that can't be done in that get done in JS. Also, JS is a prototype-based language, so it follows a completely different workflow.
Things like access control generally only become really important in big projects.
Also, your timeline compares Apples and Oranges: Perl and other server-side scripting is still being used today. This is simply a case of the clients becoming more sophisticated, so as that power became available client-side (heck, my current phone beats the pants of the copy of Netscape 2 I had on my first Mac), it was used more, but *in addition to* the server-side stuff.
And of course, those people who were doing things that should have been client-side to begin with moved their server-side stuff away (you get much cheaper hosting if you only need to serve simple files server-side, SSIs and scripting and CGIs cost extra, after all). It was more a refinement of technology.
What you're seeing is more a symptom: All those small code bits not only ended up on the client, by their nature of being small, they're also good candidates for rewrites, because they're usually small and self-contained. A JavaScript can generally not do much outside of its page, so they're fairly limited. And in addition, a lot of the JavaScript you see is actually computer-generated on the server side. So, the server generally handles the complexity, and the code that is output can *easily* be spaghetti code, because it's small and all you have to do to fix it replace a few lines of server-side code that generate this thing.
Sorry, don't agree with your observations at all :-)