links

[scottobear]

Is DHTML dead?

Well, that really doesn't surprise me, but it is disappointing. I thought it'd outlive java.

Here's an interesting breakdown of 2001 via google...

and last but not least - Design Your Own O'Reilly Book Cover!

Comments

[lroberson.livejournal.com]

I doubt it, but .NET surely will be overtaking DHTML in all but hobbists' hearts. I think .NET will be a little too much for people who enjoy coding webpages for the helluvit or for whatever reason. The fact that it's only supported through IIS right now is another reason why I think most home users won't get accustomed to it. I'm struggling right now to get my old Win2K Pro machine networked with this one so that I can begin learning .NET (specifically ASP.NET).

It does look super cool. One of my webpages makes good use of DHTML and there's no way really (with Tripod, my freebie host) that I could switch over to .NET with that. And the editorialist is right; Flash is definitely easier for the masses than DHTML.

[sweetalyssm.livejournal.com]

hmmmmmmmmm

[scottobear.livejournal.com]

as someone deep in the industry, what do you think?

Re:

[scottobear.livejournal.com]

Thanks... most of my personal writing has been going to the pad lately. :)

[charles.livejournal.com]

DHTML was always doomed.

The problem was that DHTML was an umbrella term for the interaction of three completely separate things. Javascript (ECMAScript), DOM and CSS. Each of these three things were being developed independantly, and at the time DHTML started being coined as an umbrella term for the three things, none of them had been standardized, and the major browser vendors were working in opposite directions. Finding the exact cross-section of those three technologies that would work on more than one version of one browser on one platform was totally evil.

Javascript was OK - most peoples JS implementations look the same.

DOM was a nightmare - Netscape 4 has document.layers.elementId, Internet Explorer has document.all.elementId, while the W3C DOM standard (used in Netscape 6) only supports document.getElementById("elementId"). That fact alone makes cross-browser DOM manipulation a total pain of browser sniffing and alternate scripts.

CSS was similarly a problem. Browser vendors were in such a hurry to implement CSS that they only counted the number of tags they supported - they never tried to make sure that the tags they didn't support were handled cleanly. So while the markup of my journal homepage (done entirely with CSS, no tables were harmed in the making of that page) looks great in Mozilla, mostly good in IE5 or later for Windows, but in IE5.5 for the Mac, the right-hand sidebar sits on top of the text of the page, and it looks absolutely abysmal in Netscape 4.

As soon as you start manipulating CSS, you run into the problem that not only will different browsers behave completely differently, but different versions of the same browser (even down to different point-releases) will do completely unpredictable things to the same markup, unpredictable things that include having bits of borders vanish at random, having your relatively positioned divs overlap each other for no reason, and so on.

So yeah, DHTML isn't so much dead, as it was never really alive. Maybe in two more generations of browser, when they all support W3C standard DOM, and they've finally all managed to get full implementations of CSS2, there might be a resurgance.