JavaScript and "serious" programmers

For at least a year I've been worried about the total lack of relation between JavaScript and "serious" programmers. Unfortunately it seems as if JavaScript is still beneath their notice. That starts to annoy me.

The advent of Ajax makes a solution to this problem mandatory. Who will create the Ajax applications? Those who don't know how to write an application, or those who don't know the language the application will be written in?

Who will create the AJAX apps?

For the past few months I've been thinking about the gory production details of the Ajax hype. We'll get a brave new wave of web applications that leverage the power of XMLHTTP. However, before these applications appear online, somebody must create them. Who?

Basically there are two options: Ajax applications are created by client side programmers (XHTML, CSS, JavaScript, accessibility, usability), or by server side programmers (Java, PHP, .NET, Perl, databases, SQL). Neither option suits me.

Client side programmers: no

Now that I'm getting more and more requests to create complex scripts that run into the thousands of lines, I'm increasingly starting to notice that I don't know much about application design. Obviously, I'm going to have to learn the basics of designing applications, or run the risk that my complicated scripts fall apart at the slightest pressure.

In July I was requested to review a book about Ajax. Although I couldn't make as much time as the book required (publishers should start paying serious money if they want serious reviews!), I was immediately captured by the few chapters I read about application design. It was, quite literally, a new world. I had already laboriously discovered some of the design principles the book described without outside help, but others were totally new and exciting. I want to know more about this topic.

Can anyone recommend a good, language-neutral book about application design principles?

More in general, I think that client side programmers can use a bit of education in application design and software development. Typically, our scripts are rather small, both in extent of user interaction and in number of lines, and they don't constitute a serious design challenge.

For this reason, I doubt whether client side programmers are most suited to create Ajax applications. They just don't have enough experience in application design and serious programming.

Server side programmers: no

On the other hand, I feel that server side programmers are unsuited to create Ajax applications, too. Sometimes I get the feeling that they don't want to learn JavaScript, with the possible exception of the ones that visit this and other standards aware sites.

Besides, the unthinking nonsense reflex that "this applications is so advanced that it's never going to be accessible anyway" starts to work on my nerves.

In my opinion, server side programmers should learn modern web development techniques and theory if they want to write Ajax applications. But they don't. (OK, OK, I'm exaggerating. No doubt there will be server side programmers that want to learn. The majority doesn't, though).

A beautiful example of server side disdain for JavaScript is given by the practical chapters of the same book I referred to earlier. Although, as I said, I loved the theoretical chapters about application design, I was shocked and awed by the raw disinterest displayed in the other chapters. Apparently the writer had taken a few days to read up on JavaScript, and then just started to write stuff.

Apart from detail errors like using the item() method that is unnecessary in JavaScript, the writer entertained curious notions about CSS (font sizes in points?), DOM trees (the <body> as the root element?), and the W3C DOM specification in general (the getElementByTag() method?). Unfortunately for his readers, he was a new amateur who didn't have the faintest idea what he was doing.

The worst is: I don't think this is an isolated incident. I'm afraid it's an accurate indication of the way some (many?) "serious" programmers think about JavaScript. It's just that simple client stuff, right? It doesn't even need any objects, right?

Even if I'm exaggerating, I still feel that the average server side programmer needs to know something about modern web development theories, especially those related to accessibility, and has to take the time to actually learn JavaScript. Without these crucial knowledge components he's not suited to create Ajax applications.

JavaScript libraries - substitutes for knowledge?

In response to my previous entries about the New Amateurs, more than a few people said that one of the big problems with JavaScript development right now is the lack of good libraries. I've got mixed feelings about these remarks.

As some of you will know, I dislike JavaScript libraries. Despite this, I'm willing to take a second look at them if "new amateur" programmers who'd really like to do JavaScript right maintain that good libraries are a necessary tool for their trade. I'm willing to extend my hand across the gap between client and server side.

Nonetheless, before doing so I'd like to ask two questions and make one remark. The first question is:

Suppose you're my boss and order me to write a Java application for you, despite my abysmal ignorance of all things Java. I buy a technical reference book, ask around for the best libraries in town, and with these aids start to create my application. Would you, being my boss, consider this a healthy situation in which I'm guaranteed to deliver a quality product to our clients?

Personally, I'd say No.

I feel that libraries are sometimes regarded as substitutes for knowledge. Without knowing a programming language you can't use it. Libraries are just tools, not magic wands. Besides, the true geek reflex would be: "Are there no good libraries? I'll write my own, even if I have to learn JavaScript ten times over!".

The second question is:

Would hiring or becoming a JavaScript professional solve the problem? It's odd, really, that a software house that uses a certain language refuses to employ experts for that language.

Finally, the remark.

The study of browser incompatibilities is a necessary part of learning JavaScript. You must at least once experience the frustrations of trying to manage a herd of obnoxious browsers by hand.

You don't have to know all incompatibilities by heart, that's what sites like this one are for. However, no compatibility table or library will ever teach you the same lessons as actually managing live browsers. Once you can identify and avoid common causes of their little head- and heartaches, you can revert to libraries, especially since you yourself can now check and maintain them.

Knowledge sharing

As we've seen, client side programmers know little about application design, and server side programmers know little about modern web development theories. But both sides know a lot about the topics the other side needs to learn.

Serious knowledge sharing between client side and server side programmers would seem to be the obvious solution. Unfortunately, in order to have serious knowledge sharing, we must have mutual respect, first. After all, if you don't respect someone you won't take his knowledge and opinions seriously.

And it's here that we encounter the problem. I cannot avoid the impression that many "serious" programmers look down on JavaScript, and don't want to learn it because it's too simple. Instead, they tell an intern to go download a library.

This arrogant and condescending way of thinking annoys the hell out of me. Worse, it's unprofessional. This blatant piece of New Amateurism stands in the way of the true two-way knowledge sharing client side and server side programming so badly need.

No doubt there are companies that understand the ins and outs of both modern web development and application design, and give them equal weight. You may even work for one, lucky you. Nonetheless, the overall pattern seems to tend towards arrogance rather than cooperation. That has to change.

(And no, I'm not going to give the name of the book I reviewed. After my review the publisher seems to have decided the practical chapters needed to be reworked. I haven't yet seen the final version, so I can't really judge it. It might be much better than the draft I read.)

Comments are closed.