Although I got my first dialup Internet account in 1995, I didn’t get into writing HTML for another three years. At that time, a budding webmaster would have their pick of authoring tools. For me, it was between Claris Home Page and Adobe’s newly-acquired GoLive (formerly Cyberstudio. Ahh, the 1990s.).

In those days, many people looked at the World Wide Web as a medium similar to the interactive CD-ROMs of the time; they were supposed to be media-rich experiences. Here’s a shot of Apple’s home page in the mid-90s:

If you wanted to create a media-rich CD-ROM, you used a tool like Macromedia’s Director, which let you place multimedia assets on a “stage” and animate them using a timeline. In the background, a proprietary compiled language parsed your WYSIWYG actions into a self-contained application that could run on any computer. And thus, a legion of crappy “edutainment” CD-ROMs and training materials was born.

Those web authoring tools were thought to fill the same need, but published to the Web. And web authors, like me, thought we were doing the same thing: using an application to do something incredibly complicated like laying out visual content in the confines of a web browser. I shudder to share this, but here’s a screenshot of my first-ever web page:

Yikes.

Over the years, I grew to rely upon what eventually became Adobe Dreamweaver to do my professional work. I used it when I was at Compaq to manage my portion of Compaq.ca. I used it at HP after the big buyout happened as well. And when I went freelance, well, you can guess what tools I took with me.

At the time, I loved Dreamweaver. It wasn’t a perfect tool, but I had used it long enough that I became familiar with its idiosyncrasies, and I was very efficient with it. But as time moved on, I started to realize something: I was missing out on a couple of very significant changes in the web authoring landscape. And it was Dreamweaver that was holding me back.

Layout of web elements had moved from using HTML tables to CSS

I still see people complain today about how it’s easier to layout HTML content using tables rather than CSS. All I can say is that those people have not built sufficiently complex pages. In my latter days with Dreamweaver, I was putting tables inside of tables inside of tables inside of tables inside of tables inside of tables.

Inside. Of. Tables.

Dreamweaver made this possible, because it had a visual layout tool that showed your table hierarchy, giving you the power to position elements with almost pixel-perfect precision. But when Dreamweaver cacked out (and it did!), you had to start reading its generated HTML to figure out what nested table cell was improperly placed. And that, friends, is an hours-wasting nightmare.

I was a late adopter of CSS layout, primarily because Microsoft was slow to adopt the tech in Internet Explorer, and because Dreamweaver made it easy to stay with tables. (If you want to learn CSS inside and out, this is the book to do it with, though I cover it in my own book as well.

Dynamic applications (such as with Perl or PHP, paired with a database) were becoming more important

I started tinkering with PHP in 2001, but didn’t start using it professionally for a few more years. Once again, it was Dreamweaver holding me back. With its focus on visual, static web sites, it was harder to integrate server-side functionality. Later versions of Dreamweaver included support for server side scripting languages, but like all of Adobe’s attempts to modernize the application, it arrived as an ill-conceived hack that I wasn’t able to rely upon.

In Dreamweaver, a segment of PHP code in an HTML file appeared as an icon in your layout. You could click on the icon to see the code. Over time, more and more of my page wasn’t visible in the visual code editor; instead, it was a patchwork of PHP icons representing the dynamically-generated news items, the login area, the CMS….

Leaving it behind

The combination of these two factors led me to a conclusion that most web developers (the term “web author” has apparently vanished) enjoy today: plain text editors are the way to go. While Dreamweaver has a fine text editor, it felt kludgy to open this giant application just for that feature. it wasn’t long before I had adopted TextMate; the rest is history.

At around the same time, web developers were rebelling against the whole notion of generated HTML, such as what Dreamweaver produced. Instead, our hand-written code was smaller, more elegant, easier to read. And with CSS acting as the presentation layer, it is very easy to manage the files. Throw in dynamic content like PHP, and you had one mode — plain text — that allowed you to manage all the elements of your web application. And still later, we threw in non-obtrusive Javascript, which is another way to simplify coding your applications (and which was also poorly-implemented in Dreamweaver).

I was shocked to see that Dreamweaver still exists, and is a shipping part of Adobe’s latest Creative Suite version 6. Judging from Macworld’s review, not much has changed since the early 2000s, leading me to suspect that Dreamweaver remains a valuable tool for designers who don’t want to learn HTML. Which is farcical, of course, because Dreamweaver forced me to learn HTML. Or at least, its terrifying div- and span-laden rendition thereof.

If you’re still one of those people, do yourself a favour and jump on board with one of the many great text editors available on the Mac: Coda 2 from Panic, the aforementioned TextMate (but note that its future remains uncertain, though I use it every day), the brilliant BBEdit, from Bare Bones Software, MacRabbit’s Espresso, and up-and-comer Sublime Text (though it loses points for being, and looking, cross-platform).

At the end of the day, the technologies that drive the Web are fast-changing. Use a text editor, and you’re not chained to an application that relies on an extinct view of development.

That is why Dreamweaver is dead.