Dislaimer: Mark absolutely loves Macromedia. If Macromdedia were a woman Mark would have pictures of Macromedia on his closet door (although his wife would think it strange). Mark would be flipping burgers without Macromedia. Mark doesn't want anyone at Macromedia to read this blog and think he's a petulant child stamping his foot or holding his breath. Mark just wants to indicate some of the things about Dreamweaver that make it his third choice as an editor. Now that that is out of the way, Mark will stop speaking in the third person...
Most web developers have an opinion about Dreamweaver. Let me say at the outset that I believe DW to be the best tool to date for designing web sites. DW allows you to have a unified approach to navigation, layout, styles, images and synchronization. With DW you can treat a collection of "pages" as if it were single thing - a web site. That's handy during the design phase. I have often used DW to work with layouts and create templates from a mockup. It makes things like adjusting widths and investigating advanced CSS attributes friendly and accessible.
Having said that, I'd have to say that DW is a very poor tool for working with code. For the following reasons...
The building paradigm in DW is the "web site". By this Dreamweaver means a collection of related pages or content linked together. It is possible to work with just "files" in DW, but DW has all sorts of ways of encouraging you to add a site. In fact, DW works best if you define a local cache and a live site. It expects that you will work locally with pages and files, and when you are ready, you will upload all your changed files to the live server. This methodology works well for pools of "pages", but it is completely useless for "web applications."
In our world we build applications. An application is a collection of "files" - sort of - but that's not really how we think of an application. To us an application consists of "display" stuff (layout, css, and output), event stuff (interacting with user behavior, handling variables and deciding what to do next) and data stuff (updating database tables, checking permissions, running routines, validation and the like).
For example, we don't really think of the add user page when building a security interface. We think of the user application. One of the events of the user application is called add user. The add user event consist of a form for user input, validation and error trapping, inserting a user into the database (a "sub-event" that follows validation) and event feedback. All of that might exist on a "page" but it is far more likely to be a combination of includes and CFC calls. In addition, the same user application probably supports the edit user event and the delete user event. They all use some of the same files (perhaps the form and the event handler), but they use different files as well.
To really take advantage of Dreamweaver would require us to rethink our approach. I will be the first to admit that this may not be a bad idea in some cases. It is also true that we can make Dreamweaver work like we want it to work, with some effort at configuration. But Dreamweaver will never really allow us to work with an "application" using an "event-object" approach. At some point, when design and layout are largely complete, we are going to end up using Dreamweaver like a file editor rather than an IDE. And that brings us to my second problem with DW.
File management in Dreamweaver is a real challenge for a couple of reasons. The first reason is the single drill down view. A "site" (or a drive location) is open in the upper drop down window. To find a file to work with you have to "drill down" into the file system. Files and folders are intermingled in the same view. Naturally the file tree on some sites can be many levels deep. Dreamweaver doesn't report the path back to you - even on an open file. It's not even in the properties list. So I find myself scrolling back up to the top of the file list to get the location of the file I'm looking at. And in case you are wondering it is quite common for me to have multiple files from multiple sites open. I'm not sure that's even that's even possible in Dreamweaver. What is needed is a folder view and a file list (a la homesite) to make it easier to browse files in folders and still keep track of the folder you are in.
Along those same lines, when you do a search in Dreamweaver, the search pane doesn't report the path either. So you can have 4 or 5 files named the same thing but from different locations listed in the results pane. That's not terribly useful to say the least.
As anyone who has achieved a high level of competency at touch typing (60 words a minute or higher) can tell you, a mouse slows you down. It's important to be able to maintain a constant contact with the keyboard. It may seem hard to believe, but if you know the effect that you want, it is faster to type in hand-coded html than it is to work with mouse driven styles and properties. Of course the mouse is useful for the creative process. It's great for experimentation and trying new approaches to design. It's just not so good for coding. You have to "move a bunch of stuff" out of the way to get the code window. There's no split code view. There are many things in Dreamweaver that you simply can't access without a mouse. It constantly drives you to "panes" which are maybe docked and maybe undocked, but in almost every case they have to be resized to make any use of them.
Take the hideous help panel for example. It's tiny with tiny fonts. When you choose a topic a scroll bar often appears, but when you use the mouse wheel it actually switches topics instead of scrolling the text (genius!). The help system really suffers with DWMX. There's nothing wrong with the actual help - just with the container. These folks need to take a look SQL books online for the best example of help I've seen. A close second is Homesite's fully editable and configurable help section. I can easily add new help or edit existing help with my own examples. I'm sure there's a way to do this in Dreamweaver as well, but I might have to set up a new "site" to do it.
It takes 90 megs of RAM to open Dreamweaver - and that number goes up as you open sites and files. Dreamweaver does things "behind the scenes" to cache pages. At least we assume that is what it might be doing (in keeping with it's idea of a "site") - it may be playing online poker with a table in Malaysia. It takes too long to load. It is feature rich to the point of suicide and it's difficult to get rid of them. An "editor" needs to be lightweight and responsive. I want features that are "filecentric" not "websitecentric".
Let's be up front. As a Coldfusion programmer, only about 20 to 30 percent of my "code" is html or visual - sometimes less. Nobody hires me or my company because we are artsy and design oriented. They come to us to write code that does heavy lifting. We use contractors for most of our true design work. What I need is an editor for files with good help features like context sensitivity, tip windows and sample snippets. I don't need wizards and widgets for the most part.
As an authoring tool Dreamweaver is a program that allows designers to extend themselves. It allows them to see and manipulate their creation in an intuitive fashion. But as an editor Dreamweaver is clunky, slow, frustrating and burdensome. It dictates to me - and it won't get out of the way and allow me to do what I want to do. It requires me to change my approach to fit it's assumptions about how I should be programming. It's like a 14 year old drama queen pouting and shouting, "over here! look at me! hey! you aren't using me right!"
When I get my copy of Studio 8 I will be anxious to give Dreamweaver another shot. CF Ecplipse and Homesite (My 2 current choices for editors) have their own set of pitfalls and I'll be anxious to see if DW 8 has come closer to what I need. I'm not holding my breath, but I have a commitment to try it for a couple of days and see if I can shoe horn it into my development life. I'll keep you updated.