This is as days pass by, by Stuart Langridge

And this is First DHTML Utopia review, written , and concerning My books, JavaScript and the DOM

Bobby van der Sluis is very kind about my book in the first review of DHTML Utopia. Cool. He does bring up a couple of small points, some of which I agree with and some of which I don’t. For example, I don’t think that people should be introduced to the old DOM0 ways of doing things; I’m a firm believer in the idea that people with only DOM0-capable browsers shouldn’t get the benefit of JavaScript enhancements. Since pages must always have a non-JS fallback, I think that if you don’t have a reasonably recent browser then you should have to live with that fallback. While this is a touch unfair on people who are still running Netscape 4 and can’t upgrade, catering for DOM0 browsers makes code much harder to write for not very much benefit. He also takes issue with my use of Sarissa for the XMLHTTPRequest examples, suggesting that “it would have been useful to explain the different flavors of XMLHttpRequest and XMLHTTP first, so you learn how to use it to create simple applications, and discuss the use of a script library later for the more complex examples“. I find using it manually such a pain in the arse (all that “is MSXML2 installed? no? try another Microsoft library“) that in essence you’ll need to write a minimal wrapper library yourself just to successfully create an XMLHTTPRequest object in a cross-browser fashion. If you have to include a library regardless, then you might as well include one that makes it easy to step up to more complex apps later. Whether Sarissa is the best choice for an all-round library is something I leave to posterity to decide.
Thanks, Bobby; you didn’t spare my blushes (“currently the best book on the market for learning how to apply modern JavaScript and DOM“), and if the book impresses most of its readers in the way that it’s impressed you then we really could be on our way to a newer and brighter web. Hooray for that idea, I say.

Comments

Tony B

The more I hear about the more I want it, on my desk, now!...

[ahem]

Ordered it today. Maybe It’ll get here next week.

behnam

how do you do the people who are absant are the idol.i wish spoke together but by peace in the iran

MattC

I’m still waiting for my copy to arrive from Amazon. I must admit, the mention that it contains some details on XMLHTTP stuff does have me moist with anticipation. This has to be one of the coolest things around at the moment, and it’s also great for enhancing usability. Can’t wait for the postman to deliver.

MattC

I’m still waiting for my copy to arrive from Amazon. I must admit, the mention that it contains some details on XMLHTTP stuff does have me moist with anticipation. This has to be one of the coolest things around at the moment, and it’s also great for enhancing usability. Can’t wait for the postman to deliver.

Matti

Well some time has passed now since you wrote your book and unfortunately some of the things you wrote have now become the holy grail of javascript development, as though other ways are now completely wrong because you say so.

Of particular concern is the natural use of events such as onclick and onchange, support for which which are built into all browsers. You give the following example to support your own conclusions of what is the "bad way" to do things (with no explanation as to why it is bad):

I can tell you why it is bad. It should only be a direct function call such as onclick="textToUpper();". It is bad for that reason alone, not because it is inline.

You then follow on to show your own method, of which you admit "this means more code". Yes, to adhere to this method means more code, which naturally impacts maintainability, adds unneeded complexity (lets move on to more complex applications and see what we are really looking at) and basically makes no logical sense. If we are to "separate behavior" as is touted, then we also need to remove hyperlinks as well, since they also are behavior. If we are to follow your methods to their logical conclusion, then truly we must remove hyperlinks also and add javascript listeners for those as well!

There is absolutely nothing wrong whatsoever with calling a function() inline. Sure, to construct functions inline is naturally a poor way to do things, however the simplicity of making function calls inline is the most intelligent way to do things, particularly with complex Ajax applications.

Very few people develop using straight XHTML, CSS and Javascript these days. Most use a language such as PHP to build their applications. Links with inline function calls are easily constructed with PHP (only a single function is needed), thus keeping things maintainable and separate, without the unnecessary use of extra javascript functions and DOM scripting as your methods require.

When we move over to fully Ajaxed applications, your methods require endless writing to the DOM. This not only impacts maintainability, but also performance since it is reliant on the client CPU and RAM. It also gets very ugly and buggy.

The advances with javascript in recent years are a wonderful thing however that inline function calls have become anathema is not a good thing. The best method to do anything is always the simplest and most reliable.

We are not here for "sexy code" alone. For many our livelihoods depend on it. Simplicity and maintainability are essential and your methods depart from this for no well explained reason. Saying "it is bad" just does not cut it.

This website belongs to Stuart Langridge. Contact details are available. Don't eat yellow snow. Valid HTML5, at least in theory, except for the bits that aren't because I'm that futuristic that I'm ahead of the spec, oh yes. HTML5 help from Bruce Lawson, among others. Fonts from the superb FontSquirrel. End.