Fog Creek Software
Discussion Board

Dynamic HTML?  Who needs it?

I'm a little surprised by Joel's recommendation of a book on DHTML.  If plain, ol' regular HTML was good enough for our forefathers,  then it should be good enough for us.

Seriously, though, most pages with DHTML effects are just irritating.

J. D. Trollinger
Wednesday, October 9, 2002

Sure. Our forefathers were also happy with green screens.
Pure HTML applications are basically just green screens for the 90's. Request/response....slooooow.

The best web apps are the ones that judiciously use DHTML to increase the responsiveness of the applications.

John Harvard
Wednesday, October 9, 2002

oh, stop already. that's not even an amusing troll.

Joel Spolsky
Wednesday, October 9, 2002

Well, and they suck big time... lots of development time actually. Really, let's have ASP.NET components take over the world with ActiveX versions and let's get back to solid GUI programming.

Wednesday, October 9, 2002

The majority of Dynamic HTML pages don't suck and aren't annoying. Tasteful deployment of DHTML technology yields a site where the affects of the scripting underly the page and are not visible unless you are looking for them. Take for instance browser and frame detection. This is DHTML technology that nobody complains about or even notices that has a serious impact on the way some people perceive the net. Just because a few amateur pages misuse the technology in gaudy and ineffective ways does not mean the technology as a whole is useless.

Judgements for or against a technology need to be made on a technical and unbiased basis. Your opinions on this matter do not seem to be taking in the larger scope of things, wherein the positive benefits of DHTML become readily apparent.

Dustin Alexander
Wednesday, October 9, 2002

As a side note, Phil, one of my senior programmers [from way back in the functional days] suggested just that: the elimination of HTML as a display language and its replacement with something more along the lines of a graphical user interface.  I would have laughed at him if he weren't dead serious.

Dustin Alexander
Wednesday, October 9, 2002

What is DHTML?

Wednesday, October 9, 2002


What is DHTML?


Matthew Wills
Wednesday, October 9, 2002

I say that because I use it all day long for making fancy GUI behaviors that the business wants (and we can understand their claims) and really, if Microsoft has it like that in ASP.NET components, DHTML should be hidden from view.

It sucks. Dot. I use it, yes. But given the choice, give me a strongly typed language that can be compiled, put in libraries etc (not SRC="xx.js" junk). I won't even argue. Compare web and Windows dev (or Java Swing) for that purpose and DHTML is like stone age...

Ever heard of Netscape ? Making neat pages compatible with NS will swallow an inordinate amount of time.

Hey, the defintive reference is as thick as the whole SWING book from Oreilly and you really can do much more with SWING.

Bah, ASP.NET is the way. (I can tell because I use servlets, velocity, JSPs whatever in a "educated" way).

Check out this

And see for yourself. Okay this is more of a Java/ASP.NET thing but it is for web applications and both frameworks solve the same core problems, which are managing complexity properly for a large app.
DHTML is in the way of that. I saw a big library of javascript code doing lots of fancy things but it was basically "mimic a Clipper screen [get when etc]".

Ever had to maintain a DHTML application coupled with server side code and produced by a stream of developers ? I have and I can tell you that DHTML is bad bad bad !

Thursday, October 10, 2002

This very case :

is quite educating: they sell you a DHTML *menu* for $29 !!!!

A menu ! The item you would take as GRANTED on any platform.

Check that code, it's a testimonial to the complexity of DHTML when applied to cross browser situations.

They have to do that for menus and you would want a rich gui with DHTML ????

Look at the version stream:

New to HM Central:

June 26, 2002 - Version 4.3 released. MS-Windows-menu behavior introduced.

April 02, 2002 - Version 4.2.3 released. Support for Konqueror browser for Linux introduced.

March 07, 2002 - Version 4.2.2 released. Additional options for menu scrolling. Mousewheel support for IE6Win. Minor fixes.

February 19, 2002 - Version 4.2.1 released. Scrolling for tall menus introduced for IE4 Windows and IE5 Macintosh. Minor fixes.

February 04, 2002 - Version 4.2 released. Scrolling for tall menus for all supported browsers/platforms except IE4 Windows and IE5 Macintosh.

November 15, 2001 - Version 4.1.3 released. Resolves additional IE6 issues introduced with IE6's standards-compliance mode.

October 30, 2001 - Version 4.1.2 released. Resolves IE6 issues introduced with IE6's standards-compliance mode.

October 19, 2001 - Menu Sites section updated (100 new sites added)

October 02, 2001 - Version 4.1.1 released. Resolves IE5+ memory allocation issue. Much faster IEMac rendering.

September 18, 2001 - Menu Sites section updated (306 new sites added)

August 21, 2001 - Version 4.1 released. Includes support for variable-width menus.

August 10, 2001 - Version 4.0.14 released. Includes support for Netscape 6.1 and Mozilla 0.9.3.

August 06, 2001 - New "Known Issues" section added

July 24, 2001 - Menu Sites section added (over 300 sites listed)

July 12, 2001 - Version 4.0.13 released.

And you would say you can master that ???

Come on ! Your senior programmer was right and still *is*.

Thursday, October 10, 2002

Yet another Paul Graham quote that seems to hit the mark:

One thing that might deter you from writing Web-based applications is the lameness of Web pages as a UI. That is a problem, I admit. There were a few things we would have really liked to add to HTML and HTTP. What matters, though, is that Web pages are just good enough.

There is a parallel here with the first microcomputers. The processors in those machines weren't actually intended to be the CPUs of computers. They were designed to be used in things like traffic lights. But guys like Ed Roberts, who designed the Altair, realized that they were just good enough. You could combine one of these chips with some memory (256 bytes in the first Altair), and front panel switches, and you'd have a working computer. Being able to have your own computer was so exciting that there were plenty of people who wanted to buy them, however limited.

Web pages weren't designed to be a UI for applications, but they're just good enough. And for a significant number of users, software that you can use from any browser will be enough of a win in itself to outweigh any awkwardness in the UI. Maybe you can't write the best-looking spreadsheet using HTML, but you can write a spreadsheet that several people can use simultaneously from different locations without special client software, or that can incorporate live data feeds, or that can page you when certain conditions are triggered. More importantly, you can write new kinds of applications that don't even have names yet. VisiCalc was not merely a microcomputer version of a mainframe application, after all-- it was a new type of application.

Of course, server-based applications don't have to be Web-based. You could have some other kind of client. But I'm pretty sure that's a bad idea. It would be very convenient if you could assume that everyone would install your client-- so convenient that you could easily convince yourself that they all would-- but if they don't, you're hosed. Because Web-based software assumes nothing about the client, it will work anywhere the Web works. That's a big advantage already, and the advantage will grow as new Web devices proliferate. Users will like you because your software just works, and your life will be easier because you won't have to tweak it for every new client. I would not even use Javascript, if I were you. Viaweb didn't. [16]

Matthew Lock
Thursday, October 10, 2002

The web is the most successful GUI ever developed. Something over 98% of users can do whatever they need with it, without having received any prior training.

Why? Because the technology has been so limited that programmers haven't been able to mess it up!

Incidentally the DHTML menu mentioned above costs $29 for a FIVE PAGE web site! Only a programmer could think of developing a menu to navigate five pages!

Stephen Jones
Thursday, October 10, 2002

Look at yahoo mail for example. Low on DHTML, very fast (altough now ridden by advertising), not too much graphics.
The way I like it.

Friday, October 11, 2002

I have to agree.  I've been programming for a living since 1981, and the longer I'm at it the better I like a "less is more" approach to UI design.  It may be that I'm turning into a curmudgeon, or it could just be that I've seen GUI used as an excuse by time-pressed managers or clueless marketroids to not do full task analysis... ("Hey!  We don't *need* to think about how these screens should flow and how that flow matches the user's mental model of the task environment!  We'll just put icons in front of it, throw some menus and windows up, and we're done!")

The Macintosh started it, but the difficulty of programming the GUI meant that by the time you were good at it you had developed at least a little discpline.  Visual Basic, as the first GUI-generation tool aimed at the unlearned masses, really started the ball rolling downhill.  By making GUI design something that even an idiot marketerr could do, it devalued the skills needed to do a really *good* application by making it hard to tell, at first glance, a crappy program from a good one.

Chris Woodard
Saturday, October 12, 2002

This area of technology is in such a state of chaos right now, yet it still works for some bizarre reason.

I prefer to use flash if I want clientside functionality.

Eric DeBois
Monday, October 14, 2002

I don't use Flash for the same reason I won't use ActiveX: security holes.

I'm a minimalist when it comes to site design.  I prefer to spend much of my development time building a task model for the things a user will do in the site and work from that, rather than picking up a SuperWhizzyFlashBangGizmo and trying to figure out some way to use it.  That means that my working sites (as opposed to marketware or brochure sites) don't have

*  dancing-baloney animated GIFs like a spinning sword or a lava lamp
*  gratuitious image rollovers
*  Flash content of any kind
*  Java applets of any kind
*  giant background images
*  goofy graphic text buttons (for someone that _really_ wants antialiased fonts because they 'look cool')
*  garish color combinations
*  untested navigation metaphors that make my site visitors work harder than they need to to find their way around
*  TMI (too much information)

or any of the other "web designer" kitsch that amateurs pick up out of "How-To" books without knowing when not to use them.

Chris Woodard
Tuesday, October 15, 2002


You you mind pointing us to a set of "working metaphors" ?

I know about things like this :

but maybe are there others...

Wednesday, October 16, 2002


I wasn't talking about something that academic.  I was talking about the basic ideas that people navigating in web sites understand almost unconsciously by dint of practice, such as "clickable text is blue and underlined", and which people violate by adding GIF or JPG 'text' links in fancy fonts with none of the standard decoration.

And I guess that instead of saying 'metaphor' I should have said 'affordance', because that's what people depend on to move around in any application.

Chris Woodard
Wednesday, October 16, 2002

You are a fan of this one then:

Or :

Wednesday, October 16, 2002

The best test has always been trying to explain the UI to my mother or grandparents...

Wednesday, October 16, 2002

*  Recent Topics

*  Fog Creek Home