Is Dreamweaver being beaten by Drupal?

By Kurt Cagle
March 7, 2009 | Comments: 23

In 1997, I was at the Macromedia User's Conference to give a talk on creating "intelligent" agents within Macromedia Director. At this particular conference, Macromedia announced a new product called Dreamweaver, an HTML editing application that exercised a profound effect upon the web development community.

Intended to compete primarily with Microsoft FrontPage (and secondarily with Allaire's HomeSite, which Macromedia ended up acquiring a few years later), Dreamweaver very rapidly became the product to beat in this category. If a medium to large company had a web-presence, there was a high likelihood that Dreamweaver could be found in the web production department. Indeed, it can be argued that while Flash may have been the primary reason that Adobe ended up purchasing Macromedia in 2006, Dreamweaver sweetened the deal considerably.

Yet there are a number of indications that Dreamweaver may be losing ground to an unlikely competitor: Drupal. Established in 2000 as an open source platform for building community-oriented sites, Drupal might seem an odd choice to be keeping Adobe managers awake at night, particularly since Drupal tends to be seen as a content management system rather than a website editor, though it is in fact really neither.

Web designer Tom Arah recently wrote in his blog that Dreamweaver is Dying, not through any intrinsic fault of the application itself, which is (as I would agree) superb. Rather, what has changed is the nature of the web itself - that ultimately it is as more about the ease of content creation and management within a given framework than it is about the sophistication of the editing tools.

While I agree with his conclusion - that Dreamweaver's days are numbered - there is in fact more to the story than just that content management is becoming the preferred mechanism. It actually has far more to do with the very nature of community generated software itself, and specifically a class of very successful open source software that share a number of common characteristics.

At the 2008 OSCON, Roy Fielding gave an interesting talk about open community projects, those projects which have managed to successfully harness a collaboration between a development core and a community of module developers that add to the richness of the core, and pointed out that these tend to spawn remarkably stable, long term projects. The examples that he gave included Linux, Apache and Firefox, but I'd be inclined to include Drupal in this category as well.

The best way to think about Drupal is to envision it as a small core of highly integrated modules along with a very clearly articulated mechanism for extensibility and integration. This core is written by developers. Around this core are a cloud of thousands (about 12,000 at last count) modules that are developed by the community, usually to solve specific needs or itches. Because the core architecture is so well articulated (and undergoes a thorough vetting between version changes) the community modules are usually able to work well with one another. It's not perfect - in the 5.0 branch, for instance, there's about three alternative architectural approaches that you can take and these introduce some minor incompatibilities - but for the most part the system works well.

A typical Drupal sys-admin would then load in the modules that he or she needs to facilitate a given type of project, sets up the corresponding configurations in an admin screen, then lets it run. The sys-admin does not need to know anything about programming PHP; indeed, I've been working with Drupal for about the last four years, and I think I've only really begun delving into PHP in the last six months, and that only because I wanted to write my own modules for a few functions that I couldn't get pre-written.

Overall, its a pretty powerful approach. I can set up views that generate serial collections of given document types using a standard forms page which essentially generates the SQL queries that run the views in the background; these in turn can be used to populate tables, lists, more sophisticated HTML constructs, RSS feeds, Atom feeds and so forth. Again I can think of only two instances where I specifically rewrote these queries manually, and again this was for something that was highly unorthodox ... and significantly, within a few months in at least one case, someone had written a module to do this.

You can get a Drupal site up and running within minutes for something as simple as a blogging page, and a fairly sophisticated site upon within a few days if you know what you're doing. Because of Drupal's structure (and its fairly innovative approach to looking at different types of documents as "nodes" of different "content type") you can also create remarkably sophisticated page layouts that hold a lot of related content (for instance, you could readily create a Drupal instance that would include content types representing galleries of images that share a common keyword, events listings with date selectors and related output display, purchasing orders, news articles, library cards, or just about any other kind of document.

I find that the XML community has actually tended to gravitate towards it, because its one of the few PHP/mySQL applications that so readily encompasses RESTful services programming. It has some downsides - performance can be an issue, especially for complex views or similar complexity, and even with a lot of different theme creators Drupal sites tend to develop a certain sameness, largely because of the data-feed oriented nature of the application (which imposes certain layout implications). However, because there is a more effective templating mechanism and the node architecture working in the background, comparing Drupal and Dreamweaver is an oranges vs. apples comparison.

In a back-channel discussion among the O'Reilly editors, O'Reilly Co-founder and Make Division General Manager Dale Dougherty brought up the question about whether applications such as Drupal shifts the balance of focus to developers rather than users. While this is true for a number of members of these new classes, Drupal in particular actually serves to more effectively empower users at various levels of access than either web editors such as Dreamweaver or more focused web blogging CMS's such as Movable Type.

One reason for this is that while only one specific account can add new modules to a given site (effectively the sysadmin for that site), each module typically offers a variety of specific operations which can be assigned to one or more access classes (each of which are, with the exception of two base classes, created by the sysadmin). This means that a sysadmin can give to a group moderator the ability to create new content types, and the moderator can in turn give to logged in users the ability to create individual documents based upon these content types, with taxonomy, input and presentation filtering, property storage and related metadata also assignable at various levels.

For instance, a group manager for a newspaper using Drupal as its community engine could create a general news article content type, a sports article (or even an individual baseball or basketball article) content type, a finance article content type and so forth. A baseball article would include taxonomy links to Major League Baseball teams, might include an optional set of fields for loading in box scores and featured player statistics, and so forth.

The group manager would also set up different filter types - a rich text WYSIWIG editor, a bare HTML editor, a specialized BBCode editor, a line break text editor, that a writer could yse - and might even have the option of using special macros in the input types for linking to specific player bios, promotional events, layout options and so on. These too can be modified, and multiple filters can be applied (such as the WYSWIG editor with macro enlargement), and the moderator can even assign which groups could access which kinds of filters.

More significantly, none of this requires formal "programming". Instead you'd take advantage of taxonomy module administrator screens to create the team "names" (which also serves to link additional related content), you'd use the Content Construction Kit (CCK) module screens to add new fields, and you'd use Views to retrieve a list of previous articles about the team. The moderator would never write a line of code to do any of this.

The sports writer, in turn, would see specific content types for Baseball stories, Basketball stories, Football stories and so forth, as well as a more generalized Sports story. These content types would be "templates" - when he created a new article of a given type, he'd see a drop down list where he could select the two competing teams, could select that this story was a game review rather than general news, and then would write the story, using one of the input filters that the group manager had assigned for his group.

The writer could save successive revisions until he was ready, then he (or perhaps someone else with different permissions) could set the article's workflow state to "published" to make it visible - not only as a story that people could read in full but as a teaser in a list of related topics, a title in a list of related content, an entry in an RSS or atom feed, an entry under Baseball or either team's taxonomy pages, an email newsletter item, a Twitter announcement and so on - each of which are modules that can be added without a line of code ever being formally written by anyone at the newspaper.

Not only is such a combination devastating to static content editors such as Dreamweaver, but this same modularity means that new features can be added in as soon as someone realizes that there's a need for them. The Twitter module, for instance, emerged within two weeks of Twitter publishing their APIs. with stable (approved) versions coming out about two months after that.

One additional nail in Dreamweaver's coffin - AJAX toolkits have been heavily integrated into Drupal (primarily jQuery, though it is possible to use other toolkits). This means that it is possible to create both WYSIWIG and specialized editors (including customized buttons and related functionality) that give you most of the capability that Dreamweaver itself offers, at least on the editor side, and the complete shift in how documents are stored and managed makes much of Dreamweaver's additional functionality obsolete.

Drupal isn't perfect. It does take some time to become proficient with the Drupal content model (even after four years of working with it, I'm still having "a ha!" moments), the presentation and style layers are not as sophisticated as they could be, performance can be a problem on occasion, and there are times where I wish I didn't have to deal with PHP as a foundational layer, as PHP itself has problems.

My own take is that Drupal is ultimately a transitional application, as a significant amount of Drupal's capabilities can also be seen (in a somewhat more refined fashion) within XML pipeline systems using RESTful interfaces and XQUery. Yet its a transitional application with some serious legs as well ... the Drupal developer community is growing rapidly, though this is still smaller than the number of "super-users" that see Drupal as a site building or management tool.

My recommendation to Adobe - study Drupal very closely, not just as a product but as the harbinger of a wave of products that are developed via crowdsourcing and community involvement. There's room for a proprietary version of the same type of system, a toolkit for building complex community sites, but it requires getting beyond Dreamweaver and building a community editor for the twenty-first century.

Kurt Cagle is an online editor for O'Reilly Media. Please feel free to subscribe to his news feed or follow him on Twitter.

You might also be interested in:


Is Dreamweaver being beaten by Drupal? The short answer is no, and Dreamweaver isn't beating Drupal either. The real question is whether static, hand-built Web pages are retreating in the face of more powerful, content management systems that offer the power to quickly adapt to the evolving landscape of Web technologies, and especially the technologies that leverage the powers of the "Social Web". Maybe, but this argument ignores many of Dreamweaver's fundamental strengths, treating the program as nothing more than a glorified HTML editor that you launch when you want to add or modify content on a site. This article ignores any of the upfront work involved in Web design: creating an original visual design, the act of crafting concise HTML and the process of developing rich, client-side user interfaces. Dreamweaver is, most importantly, an IDE designed from the ground up for writing HTML, CSS and JavaScript (and, yes, even writing server-side code.) You're assuming that all of this hard work is somehow already done when you plop Drupal onto your server. Sure, Drupal lets you slap on a ready-made Theme to "customize" the look of your site, or you can simply accept the stock look of a Drupal Web site (but, please don't!). However, if you want to develop a unique visual brand, you still need to create your own HTML and CSS--a task that Drupal cannot help with, but which Dreamweaver is exceptionally well suited for. Dreamweaver's CSS tools are second to none and not only provide many shortcuts for crafting CSS code, but also provide diagnostic tools that help you understand and debug the often complex interactions of CSS. Dreamweaver provides the kinds of tools that greatly simplify creating a professional and original other words Dreamweaver helps you produce the code you'd need to plug-into a system like Drupal to create a unique visual presence.

But is there still room for Dreamweaver as a Web site editor? Probably. While Web applications look Drupal, Joomla, and even Wordpress can greatly simplify getting content online, server side solutions always add a level of technical overhead that can be difficult for many--not difficult for you or probably most of the people visiting this site who are probably accustomed to customizing their Web servers, managing databases, and programming server-side code; but difficult for small businesses that use Dreamweaver to manage an online presence, or Web designers whose technical expertise is limited to the client-side. For many small businesses simple Web sites are enough--especially if their online marketing plan includes optimizing their HTML for search engines and leveraging the power of social networking sites to drive traffic. For small sites, Dreamweaver provides a perfectly useful, straightforward Web page editor.

respectfully Kurt ... I know that over the years, focus has diluted/widened a bit (which I personally think has been to its detriment); but I honestly can't see the 'xml' angle in this article (hehe, perhaps that's why dreamweaver is going away).


Um ... it was late when I tagged this?

-- Kurt

I am the developer who created the Drupal extensions for Dreamweaver (available for download at and I have to say that anyone who thinks Dreamweaver is dying is just being naive or needs to take their blinders off.

Dreamweaver is a tool, and yes, Drupal can be considered a tool but is really more of a system than a production tool. You can't compare the two on the same plane, but instead need to view them as parts of a whole. That whole is and always will be workflow.

Why would I create extensions for designers/developers to use Dreamweaver? Because workers need to design (XHTML/CSS/JS/PHP) and develop (PHP/JS) on top of Drupal. There's that word again, "workflow." Let's face the apparent facts: Drupal is not an IDE nor a design environment. Drupal is a framework and a content management system. Is Photoshop dying because people can alter photos through photo sharing sites? Nope. Is Flash dead because Flex is in? No, in fact remarks like these are made by trendy blogging "me too" fanboys who never seem to do any homework, or add a touch of true journalism... that would take too long and doesn't fit in a Twitter post.

Web sites are planned, designed, developed, and deployed - Drupal does none of these on its own. Contribute, the little brother product of Dreamweaver, can be used to manage/post content to any Drupal site or CMS system that supports XML-RPC; you can use MS Word if you really wanted to. While I don't use Contribute, I use both Drupal and Dreamweaver daily. I use Dreamweaver for my Drupal.

While I manage user groups for both Adobe and Drupal, I love both products and neither will be replacing the other because they are not the same. The real discussion should be "Static versus Dynamic..." and I'm sorry, this is an old hat with a new face, because in the Adobe world we have been talking about static versus dynamic for over eight years - when PHP and database (dynamic) features were added to Dreamweaver in the MX/Ultradev days a long-long-long time ago.

I don't agree with your statement that Adobe should jump into the CMS market with a new product because that would just cause additional market fragmentation and confusion for web producers; which was the case initially for Adobe Spry (JavaScript library). Adobe even uses Drupal for the Showcase, and the Dreamweaver team knows they're on the right track supporting all designers and developers who need to develop and customize any chosen system/platform and be able to tweak every pixel that system outputs.

No respecting designer/developer would use any system out of the box - that's not our style.

Cheers! Great response! Mr.Chris Charlton.
You got it, the best, that's the reality and I definitely agree with you as a web designer and developer. I know that's the work flow and I don't know if Mr.Tom Arah is really a developer or just a blogger who want's to generate a traffic to his blog.

This particular post has received a lot of back-channel attention as well as the comments here, and I find that walking into this fray something that should be done only with those well prepared to defend the position.

However, I think the question still remains. Dreamweaver is a best of breed tool for the development of static and minimally data-bound sites. These have predominated on the web for the last fifteen years, and there is no doubt still a large market for them.

Yet I would argue that the Drupal model - in which navigation is heavily bound to taxonomies, where content is delivered via pipelines from minimally constructed documents, and where style and presentation takes place in a more layered and recursive manner - is where web development is trending.

I'm not sure that Drupal itself completely embodies these concepts, though it seems furthest along that track. Designing for this approach is more difficult, both because you have to effectively anticipate what users will do with their own pieces of content and you need to work within a web environment where you don't necessarily control all of the pieces of the organization, either in terms of layout or in terms of CSS organization.

As one colleague of mine put it, Drupal is not really a CMS. It's a CMS generator. Most people do not use Drupal out of the box unless they are absolute beginners with the tool - they add modules of functionality, they change themes, they add in their own sub-themes in terms of panel layouts, they create their own views that can produce very sophisticated collection results.

I'd contend that this is the future of web development, because web development is increasingly being driven by data streams rather than static content, is increasingly being driven by user generated content outside of the scope of either developer or designer, and is increasingly being driven by a need to make information more semantically viable, which implies larger scale taxonomies that in turn have their own impact upon both presentation and navigation.

I don't think this eliminates the need for tools such as Dreamweaver. It does, however, require some significant changes in the way that people think about website design. If anything, it places a higher premium on good design, but this premium comes because designers will have to become more effective as web developers, will have to have a deeper understanding of CSS because the CSS affects output that the designer has no control over, and will often need to have a strong hand at laying out the underlying thematic infrastructure (and knowing what is involved in making that infrastructure work). In other words, applications such as Drupal force designers will become more engineer-like.

This raises one other issue, however. Metagenerators, such as Drupal, provide standardization by fiat - if there's a large enough market penetration, then Drupal can effectively set the stage for standards. For a company such as Adobe, standards are critical, because they provide boundaries and constraints that their developers can use to establish functionality.

Without those standards, there's not enough of a foundation to build consistent tools - there's too much variability in the space to keep from building a universal Swiss Army Knife. Such tools are too complicated to build cost effectively, are too complex to layer with a good UI, and usually expose far more functionality than anyone, designer or developer, can use (and that actually gets in the way of good design).

Chris, I suspect that the approach you're taking is a good start, and I am rather eager to see how well your tools work in that regard. I don't think there's all that much difference in our beliefs here, save that I'd contend that without such cross-community tools, the market that Dreamweaver currently services is at a minimum leveling out.

This is a fascinating discussion. So the question is, where is Adobe going with Dreamweaver for the next upgrade beyond CS4? I am a graphic designer who recently bought a theme package. I liked the themes and wanted to customize one of them but I found the service lacking in this department because it was a two man operation. I got so frustrated that I ended up buying Adobe’s Master Collection to learn Dreamweaver 4! These days, you definitely have to be an “everything” rather than just a graphic or web designer. It’s difficult for those who weren’t trained in the technical field as developers to understand the lingo when something goes wrong so service and a good forum are really important which can fill those holes.

The great part about CMS is that it has helped in solving the cross platform issues of yesterday.

Chris, I suspect that the approach you're taking is a good start, and I am rather eager to see how well your tools work in that regard. Örgü I don't think there's all that much difference in our beliefs here, save that I'd contend that without such cross-community tools, the market that Dreamweaver currently services is at a minimum leveling out.

Kurt (Or Chris, or anyone who knows more than I, meaning everybody)-
Very interesting discussion, but I have crashed your party as a guy just learning DWCS3. So my question makes me the guy who just came into the black-tie party with only a fig leaf. Lots of stares and who is that guy? Fine. My plan is to learn DWCS3 well enough to put a custom designed site together--with some dynamic pages--- and then use some sort of CMS, like Joomla, or maybe Drupal to do the day-to-day management of the content.
Now this is possible, I think, but is it advisable?
Or is my fig leaf slipping?

The last time I worked with dreamweaver was 6 years ago, before I switched to phpnuke. After phpnuke I went from typo3 to drupal. But still, I am not very content with drupal. The cms just needs too many queries and is not very easy to learn for beginners. The release cycle of drupal is not easy to predict. Right now they are half year off their schedule.

Thank you for this article, it is very interesting for me and my colleagues, we think back to visit and include some of your content in our page

Themegenie – the Advanced Dreamweaver extension for Drupal theming - Now Available For
Dowload from here

Themegenie – the Advanced Dreamweaver extension for Drupal theming

Theming Drupal is no more a Herculean Task or tiresome job. Thmegenie makes Drupal themeing a breeze.

Features at a glance

• Create base theme files in a single click, fast.
• Comes with Drupal template intelligence, hence high level of accuracy
• Completely Programmer free. Do it as you design html pages in Dreamweaver.
• Creating Regions is pretty simple.
• Transform your dreams to themes without confusions, PSD to Themes possible.
• With Themeenie you can create themes for your personal sites, blogs,
• e-commerces, wikis, forums and many more. It's your choice!.
• Real-time drupal view - View your theme using Dreamweavers’ design view just like you see it on a drupal site.
• Create page modules and regions in a click.
• Browser specific css.
• override template files.
• Theming blocks, nodes and comments has unlimited possibilities with a few default styles you can choose from. Rounded, zebra, collapse and so on.
• Nine styles of menus with unlimited CSS possibilities including Suck/Super fishes.
• Theme Search, Forum, Poll.
• The maintenance page.
• And much more
Coming features
- opt fixed, elastic, fluid regions
- Integrate color module
- Create theme settings
- Tabbed Region
- Collapsible Regions
- Css Switch
- Import Wordpress Themes
- Import Joomla templates
- theme Subthemes

Great article, if you include all of the comments. Drupal may not be killing Dreamweaver per se, but the model that Dreamweaver represents is defintely giving way to the model that Drupal represents. The old 'Static vs Dynamic' as one commenter put it. Dreamweaver can of course still play in the Dynamic world if it can play with CMS template design methods.

The emphasis is on content, usually dynamic content. Keeping sites updated, accurate, fresh, and user-friendly are important and doing it easily and quickly is even more important. Layout/Style is still important, of course, but work around to fit the above premise. The same thing's been happening in the mapping world. people want maps that are nice looking ('good enough') but they really need the most recent data. With good design, data (whether for map or web page) can be displayed in multiple ways through multiple interfaces.

Dreamweaver can design the layout and style of any Drupal (or any other) CMS site. But converting that design to a working Drupal theme is not very easy. Contracting out just for the conversion is common. Often times knowledge of how Drupal works is almost required when designing a Drupal site. More then ever before, emphasis is put on site architecture, navigation, content tagging, dynamic content, etc... As another poster put it, you need to be everything nowadays when designing or developing sites. In larger organizations, you can easily see duplication of efforts (or turf wars) among several groups. It's an issue I think still needs to be worked out.

Much of the article talks about the modular and open community design of Drupal. This is of Drupal's greatest strengths. I'm not sure how Dreamweaver can utilize this since people can already write extensions. Dreamweaver users can still work together even if not developing the core project.

- John

i learned the most useful things about dreamweaver,thanks.

Cheers! Great response! Mr.Chris Charlton.
You got it, the best, that's the reality and I definitely agree with you as a web designer and developer. I know that's the work flow and I don't know if Mr.Tom Arah is really a developer or just a blogger who want's to generate a traffic to his blog.

Thanks all.

I think CMS software like Drupal and Wordpress will eliminate the need for things like Microsoft Frontpage / Adobe Dreamweaver, as these open source CMS programs are amazingly simple and effective. I know a lot of big gaming sites that use them.

web dizayn: Great post, helped me a lot, thanks for sharing.


Great article, if you include all of the comments. Drupal may not be killing Dreamweaver per se, but the model that Dreamweaver represents is defintely giving way to the model that Drupal represents. The old 'Static vs Dynamic' as one commenter put it. Dreamweaver can of course still play in the Dynamic world if it can play youtubewith CMS template design methods.

My plan is to learn DWCS3 well enough to put a custom designed site together--with some dynamic pages--- and then use some sort of CMS, sohbet odalarılike Joomla, or maybe Drupal to do the day-to-day management of the content.

i learned the most useful things about dreamweaver,thanks

Adobe has realized these criticisms more than any one else.
Dreamweaver CS4 came up with features like Real-time view which is real time saver for Drupal theme developers.
DW CS5 provided more control over Drupal theme development. Code hints and Firebug like css editing features are good reasons for Drupal developers to fall in love with Dreamweaver.
In last two years some free and commercialDrupal-Dreamweaver extensions have been released. Another reason to love Drupal and Dreamweaver

Both are strong technologies they never die. Their relavance willl go up every day.

News Topics

Recommended for You

Got a Question?