As the title suggest, this books teaches modern DOM scripting techniques.

What is DOM scripting?

DOM scripting is using JavaScript, CSS and the DOM to manipulate what is displayed in a web page. The ‘DOM’ is the acronym for:

Document Object Model

This essentially is just a ‘map’ of a web page’s structure – roughly speaking.

You can do all kinds of cool things with the DOM (with the help of JavaScript,) … for example:

• Create dynamic menu’s.
• Show/hide parts of the page based on a mouse click or any other user action.
• Connect to the server in the background and load new content into the page without having to refresh the page – commonly called AJAX these days.
• Add new HTML or CSS to the page, on-the-fly.

What you need to know to read this book:

You need to be comfortable with HTML and CSS but you probably can get by without any programming experience. I say ‘probably’ because there are some points at the beginning where the basics MAY be a little unclear for some.

Should you get this book?

The book is very good and worth getting. The author has a clear and concise way of presenting the subject and I really enjoyed the read … not boring at all.

Unlike many JavaScript books out there, ‘Dom Scripting’ does a great job in presenting modern methods that include:

• Keeping behaviour separate from structure – Java nerds would call these ‘listeners’.
• How to use JavaScript in such a way that it degrades gracefully and is accessible.

Final comments:

While learning the concepts of DOM scripting, you will gain a much greater understanding of the ‘framework’ of a web page … you will begin to understand things about HTML/XHTML and CSS that you could not otherwise.

So even you are not too keen on actually doing any DOM scripting, I still highly recommend this book for these reasons.

-

Stefan Mischook

NOTE: This article is theoretical – CSS tables are not supported by the browsers yet, and cannot be used. I wrote this article to make a few points and to expose people to lessons learned in software development: that grids are an excellent way to layout user interfaces.

Stefan

-

Grid layout patterns are commonly used in creating software interfaces – in web design we call them ‘tables’.

But today HTML table based layout is generally frowned upon because:

1. HTML tables render/display content in a fixed format/style that might not display properly in certain types of browsers.
2. Tables semantic meaning is thought to represent tabular data – like a spread sheet. Thus using them for page level layout is just wrong … gosh darn it!

There are other reasons why some web designers will say HTML tables suck:

• HTML tables cause code to be bloated and thus pages will take longer to download.
• HTML tables will make your website less search engine friendly.
• HTML tables will make your websites less accessible.

The last 3 points are myths and should be ignored – I covered that in other articles.

That being said, the first point about tables imposing a fixed format/style (where formatting and structure are intertwined – that’s bad,) is very real and very important. It is so important in fact, that I will do what I can to avoid table based layout despite the extra work and problems this can cause.

It’s a terrible shame

Using a grid/table to create UI’s is intuitive, too bad that table based layouts are so controversial … but there maybe is a light at the end of the web UI tunnel: CSS table layouts.

What the heck are CSS tables?

From the W3C:

‘The CSS table model is based on the HTML 4.0 table model, in which the structure of a table closely parallels the visual layout of the table.’

Now in English:

CSS tables are just a set of CSS attributes that you can apply to (probably) div tags to create a ‘table’. Check out this code snippet and things should clear up:

This is an official W3C specification, I’m not inventing anything here!

So why invent CSS tables when we have HTML tables?

The answer is simple young grasshoppers: to gain the advantage of table based layout while avoiding the problems (mentioned above) with HTML tables:

1. HTML tables format content in a fixed structure that might not render properly in certain browsers.
2. Tables semantic meaning is thought to represent tabular data – like a spread sheet. Thus using them for page level layout is just wrong.

CSS tables can’t be used in any browser today, so why mention them?

I have two reasons why I wrote this article:

1. To educate people of this long term possibility and maybe to start stirring things up – it would nice to have this web design tool.
2. To make a point about grid based layouts: they have merit and should be considered.

Stefan Mischook

For the last 6 years I’ve had total control over my deployment environment (running my own servers,) and never had a problem with Java.

Recently I moved to commercial 3rd party hosting, where I had a private JVM but no control over my server set up. To make a long story short, I have now been dealing with Java deployment hell … Java is not playing nice.

My experience

After 6 years of enjoying the comforts of having my own server, for whatever reasons, I moved to 3rd party hosting. What took me by surprise was how hard it was to find a suitable Java hosting company. I went through 4 before I found a company that actually was able to do the job properly.

-

One of the big selling points of Java has been the write once and run everywhere theory – sounds great and apparently people have had a lot of success with this … but my experience has been something else.

A couple of tips:

• If you can, deploy on your own servers: Java is much easier to handle when you control the box.
• Never go with Java hosting that shares the JVM.

Without a private JVM, you cannot restart the server (Tomcat, Resin etc) and so updating classes and property files are a pain. And since you are sharing the JVM, anybody’s code might take your app down.

Anecdote: With the first host, when I uploaded my simple POJO based application (that had been working on my servers for a couple years with no problems) I took down the whole bloody server! Strange that this still happened despite the fact I had had the same configuration?

Anyway, they gave my ass the boot and I had to move on to my next victim!

Conclusion:

Java is brittle in a shared environment, hard to configure and problematic – it sucks. I think this is a symptom of the Java community’s need to over-engineer everything and shows how Java is no longer suitable for small and medium size application development.

The alternative:

Right now I would go with PHP because it is easy, fast and everywhere. It’s not the perfect language but it makes building web applications really easy compared to Java.

For the last several years, when asked about what programming language that I thought people should jump into, I would automatically make Java my first choice – things are changing now.

There is growing appreciation for flexible dynamic scripting languages (like PHP, Python) over strongly-typed compiled languages like Java.

Why?

I see two big reasons why people are looking to the scripting languages as a viable alternative to Java:

1. Speed of development.
2. Ease of use.

There is no argument (among sane people,) that you can build applications in a scripting language in a fraction of the time that it takes to build the same application in Java.

The Java zealots would argue:

1. Scripting code will not be maintainable.
2. Scripting code will run too slow

About code maintainability:

The reality is that code maintainability has as much to-do with the programmer as it does with the language – you can write crappy Java that is not easy to maintain or extend … I’ve seen it more than once – maybe even 3 times!

The same thing can be said of scripting languages …

Another interesting point, is that you can usually write an application with far less code than you would in Java – many times we are talking 1/4 to 1/5 the code! A thousand lines of code is much easier to maintain than 5000!

About speed of code execution:

Again, many times that comes down to the programmers skill. Having said that, the evidence shows that for many applications, the scripting languages out there run more than fast enough.

Anecdote: PHP seems to be fast enough for Yahoo.

The old argument that Java people used when defending Java’s speed (relative to C++ ) can be applied to scripting languages: computers are really fast these days … as such the difference in execution speed (most of the time) is negligible.

Java’s ever increasing complexity- benefits the few at the expense of the many:

It seems to me that the Java community has made the platform more and more complex (in favor of huge projects,) at the expense of productivity of small to medium sized projects. The problem is, that the vast majority of the projects out there are small and medium sized.

Conclusion

I’ve written most of my software in Java over the last several years, I like Java. But these days I don’t look to Java anymore because it just takes too much time to get anything done. Even small Java applications have a lot of overhead in just setting up – xml descriptors, frameworks etc. I’m not even going to get into the verbosity of the code itself …

These days I look to PHP to write my web apps – it’s just too easy and fast to ignore. PHP has got some baggage from its’ roots of being a ‘web designers language’ but it is fast, has support from big players like IBM and most important , it’s everywhere!

What about Ruby?

Looks very cool, but it is a marginal language – nobody uses it these days. Last I checked, in comes in as the 28th most used language – below COBOL, Python, VB … you get the idea.

The Web Standards movement has created a ‘culture of hacks’ to compensate for browser incompatibilities (OK, mostly IE) and this is a bad idea.

Before anyone attempts to tell me that the Web Standards community does not promote the use of hacks, please refer to just about every book written on Web Standards based web design.

Why were hacks promoted?

In a nutshell: those who promoted them are inexperienced … in other words: green. It is simply bad practice to rely on broken aspects of a technology in an attempt to make things work – any programmer worth his salt knows this. And that is exactly what many/most hacks rely on – broken aspects of Internet Explorer.

-
Anecdote: I’ve often had to ’slap-down’ young-pup programmers (just a few years out of school,) when they’ve tried to introduce into the code base, what would be the equivalent of CSS hacks.
-

CSS hacks are a recipe for disaster that I’ve been predicting for a while, a disaster that seems to be happening: it looks as though IE7 will be breaking CSS hacks and thus, the Web Standards myth of forward compatibility.

I’ve used a hack: I’m a god-curse hypocrite:

Yes, I’m guilty of ‘following the pack’ and I’ve used a single CSS hack (child of div hack) but I used it in a minimal way – should the hack fail (and it will in IE7,) my layouts will still work though the pixels will shift a little.

The real problem occurs when you start using many hacks or if your hacks should fail, your website’s usability will be severely compromised.

If you have to use hacks, use them very delicately.

The hack-free cross browser compatible solution:

When you’re critical of something, you should try to present alternatives … and my alternative to using brittle CSS hacks:

Use a IE conditional comments, Microsoft intelligent solution to cross browser coding.

I know, I know … Microsoft coming up with an intelligent solution!?

Stefan Mischook (a.k.a: The Web Design Heretic )