Digital Web Magazine

The web professional's online magazine of choice.

Keep JavaScript Simple : Comments

By Peter-Paul Koch

July 25, 2003



May 31, 2004 9:34 PM

Nice article. But it brings me to the conclusion that you’ve never seriously javascripted !
Is any of your script (that displays more than ‘hello world’) able to run properly on over 10 browsers (counting their different versions as well) ?
And why don’t I meet the word ‘compatibility’ in your article ? Weird !
You’ve ignored the MAIN reason for writing libraries for jscript – its damned incompatibility even from this page to the next (I’ve had such experience).
No wonder you blame the libraries so easily.
But tell me – if you need to make a jscript for a menu on a scalable/dynamic site aren’t you making a mini library ? Or you are blunting the code in the buttons themselves.
For those that need a serious app (like a game for example) with good cross-crompatibility a good jscript lib IS THE ONLY SOLUTION !!!
How can you blame the libmaking ?!!!!!!
At that mainly because jscript is such a lame concept (bacause of it’s lack of standart) it’s absolutely necessary for good libs to exist.
Thank you


May 31, 2004 9:37 PM

And this slogan ‘Keep JavaScript Simple’ – you can return with it when the browsers begin to support something better than JScript.
Until then the developers will have to write 2 lines of code so that the 3-td and 4-th are cross-compatible and the fault won’t be theirs.
Until then only a separate lib would be able to simplifies what the commersial giants have complicated.


July 3, 2004 12:31 PM

For those that need a serious app (like a game for example) with good cross-crompatibility a good jscript lib IS THE ONLY SOLUTION !!!

Ah, no! I think you’ll find that kitchen forks are also useless at digging the garden. One of the points that this article makes is Why, oh why would you choose to write any serious app (like a game for example) in javascript?.

PPK has been javascripting for a long time, and is a respected authority on browser incompatibility. His argument is that the libraries merely obfuscate rather than solve the problem.

Michael Kurze

January 26, 2005 10:27 AM

I played with DynAPI two years ago and I also used it for a commercial project once. We had to mimic the functionality of some stocks-calculator Java-Applet with realtime bar-charts (sporting tooltips of course), sliders that influenced each other, and so on.
We also had to cater to Netscape 4, MSIE and the Gecko Engine. If it had not been for Netscape 4, I would have achieved the same functionality in a shorter time and with far, far less code. But I had no expirience in the Netscape event-handling, thus DynAPI came as a real salvation.

Influenced by this experience, I tended to write rather large collections of interdependent, “reusable” code but did not reuse them as much as I thought I would. It is no problem to reuse lines of code, or, from my humble point of view, even objects/prototypes. But one has to keep the focus. Everytime I write some code that I might reuse, I tend to think “Oh, this method could be really nice here, I’ll probably need that sooner or later.” Of course I won’t (mostly). This is the real problem when creating libraries, keeping focused.

Today I have a collection of orthogonal .js files that are mostly short but keep me from writing some nasty or boring code over and over again (to parse/format German numbers in forms for example, to create sliders if necessary and so on, dynamically duplicate fieldsets…).
These are tuned to play nicely with the application logic on the server, enabling us to reuse code there as well.

I think that PPK is totally right about JavaScript usage for local page-behaviors or some website navigation-extras.
But sometimes you have to work on several large Web-Applications that deal with the same stuff in different ways and a central “library” (where you can take one or the other book from, just not whole shelves) is really neat.

Tim Down

March 31, 2005 4:54 PM

This article made me quite angry as I read it but it did serve perhaps its primary purpose: I stopped to think about why I consider JavaScript libraries not to be quite the evil Peter-Paul Koch makes them out to be.

I have done a lot of JavaScript development over the last 6 years and have been through all the predictable stages of writing over-complicated code. I have written a couple of games and a WYSIWYG editor in JavaScript and agree that the games would be better done in Flash, but I really don’t feel inclined to spend $800 on a licence for the devloper kit for personal use and consider my use of JavaScript instead valid on those grounds. A WYSIWYG HTML editor, however, is a proper application for which JavaScript is an entirely appropriate technology, and as such requires carefully structured code, necessarily including some objects that Mr Koch may consider “vague”.

JavaScript is rightly heavily used in web applications, and with the current obsession with “Ajax” (eeuughhh) its role will become even more important, so it makes perfect sense to take some care about how you design and code it, including the use of structures like objects. I am all in favour of simplicity but when writing significant amounts of code simplicity means structuring your code logically and I think the article undervalues JavaScript by failing to mention its use in large web applications.

Philip Wills

April 15, 2005 6:15 AM

While I’ve every respect for Peter, Quirksmode is an invaluable resource, I think he’s missed the point that sometimes we develop with js for internal tools, accessed over a fat LAN, where 10k, or 100k make little difference.

I’m not necesarily convinced by large external APIs, but certainly using js’s OO capability’s can help produce more maintainable code.

Michiel van der Blonk

June 2, 2005 8:39 AM

In most cases you are absolutely right. But the Object nature of JavaScript can still be used in an elegant, short script, that does not have to add more than maybe 1K in order to become readable, understandable code, as opposed to the many many copy-paste 1 liners spanning 3K.

The large version of is about 60K, and that’s too much, the lite version is 11K, and does some astonishing things with it. You can then strip it down even more to about 2-3K and it offers (a lot of) browser compatibility.

(ehm I still use CSS for :hover though)

Chris Waldron

June 14, 2005 6:23 PM

I don’t know if anyone has looked at the procedural client-side code generated in many ASP.NET controls such as the tab control. Is it extremely obtuse and difficult to debug as one would expect from procedural programming.

Sometime pages has some real intricate conditions between controls such as disabling or validation a particular control base upon other controls values or states.

Thus it is not only games that can have some complex interactions or interrelations but input items on forms as well. Validators tend to encourage often poorly written quick-and-dirty procedural adjuncts shrewn with a lot of conditionals or tiny disjunctive functions.

I think the author’s bias is based on the perception that writing procedural adjuncts are “simple” but this “simplicity” can easily become unmaintainable.

Writing JavaScript as object can provide better documentation and maintains the paradigm used in the overall project (you wouldn’t think of writing your server side code procedurally) to your customer whereby you can provide richness and robustness at the client.

Sorry, comments are closed.

Media Temple

via Ad Packs