In the last few months there have been two events that, together, have convinced me the time has come to wean myself off the Web development tool I've been using for two decades, Microsoft Expression Web (nee FrontPage).

The first was in June when Microsoft removed the free downloads for the two remaining Expression family products, Web and Design, from its Web site. Those using Expression Web (EW) were not affected by this because, like me, they kept a copy of the download in a safe place. Those wishing to get a copy of those downloads can find them online with a little patience. This removal was not devastating per se, but now I realize it was an omen.

The second was a couple of days ago when I relocated a client to my favorite hosting company, InfoQuest. I got a surprise when I discovered that InfoQuest has tightened security again and now requires a form of secure FTP that EW cannot handle. This is good; I heartily agree with the decision. But it does make it impossible to use EW's publishing system, which means I would have to use an external program like FileZilla for that task.

I have been using EW with an external editor (Rapid PHP) and found that level of inconvenience tolerable due to the big improvements in PHP editing, a topic I've written about here before. The additional inconvenience of using a third tool to handle bigger publishing chores is enough to push me over the edge.

Update, 05 Oct 2020 - A couple of weeks ago Microsoft closed the Expression Web forum in MSDN. For now the content remains online but I suspect that Microsoft may remove it someday.

The time has come for me to abandon EW.

Fortunately, over the past five or so years I've been quietly preparing myself to wiggle free of my key EW lock-in, Dynamic Web Templates (DWTs). I will convert my own sites so they no longer depend on this useful feature and then, at my leisure, convert client sites as needed. The sites built with DWTs will run indefinitely because DWTs don't affect the published HTML. If your Web site was built with EW, there is no need for concern; it will continue to run fine, forever.

That's the burying part of this ceremony. Now it's time to heap praise upon and otherwise memorialize the features that make EW distinctive in the hopes that other toolmakers will take notice.

Multiple Instances

A tremendous strength of EW is the ability to run more than once instance of itself. This simply means that more than one project can be open at the same time, completely independently. In my style of work this has always been extraordinarily useful.

This used to be a de facto behavior of most Windows applications. I recall writing Windows apps where multiple instances could not be allowed (for technical or security reasons); in those cases I needed to write code such that a new instance of the app checked to make sure it was the only instance and shut down if it wasn't. In other words, the default behavior was to allow multiple instances.

I am frustrated because the other tools I'm using or evaluating can not run multiple instances or allow multiple projects to be independently loaded. Such tools include Rapid PHP and PhpStorm (hereinafter "the new tools"). The new tools seem to be catering to developers who will spend days or weeks focused on one thing, while I'm bouncing around from client to client while doing new builds simultaneously. Visual Studio Code (VSC) does allow multiple instances.

Projects as Web Sites

The new tools are very focused on projects that are apps or modules. Their project management is structured around that concept. Web sites as projects are poor cousins.

EW and FrontPage (FP) before it are entirely focused on Web sites.

This is a very nuanced distinction, hard to explain. A developer experienced with EW who expands to use other tools will see it immediately and I believe this is why so many EW users are distressed that EW's time is coming to an end.

Publishing

The notion of a Web site as a project is most forcefully illustrated by how publishing works in EW. Simply put: it's better than the other solutions I use. That's why the InfoQuest situation described above, which I believe will become more common with more and more hosts, is such a defining moment.

The Expression Web publishing dialog allows multiple publishing destinations.

The key ingredient in EW publishing is that the Web site is a single entity that can have multiple publishing destinations. This is apparent in the screen clip to the right, in which two separate hosts are configured.

This proves most useful to me when I am transitioning a site from one host to another. It allows me to access both hosts as needed. As a simple example, I will make a "secret" change to the site at the old host as a marker that is only visible if the page is served from that host. When the client can no longer see the marker, they know the page is coming from the new host. I have more complex reasons for desiring this feature, of course.

EW publishing supports a variety of publishing types, shown in the screen clip below. Some of these are defunct (e.g., FP Server Extensions) and some don't work properly (e.g., FTPS, SFTP). WebDav is still available but I think rarely used by most developers. That leaves FTP and the underrated "File System" option.

EW supports a variety of connection types, including the local file system.

File System allows the site to be "published" to a local file system destination. I believe the original intention of File System was to allow an Intranet (internal Web site) to be published to an in-house server. But File System works on, well, the file system, so it can be used to make a backup copy of a Web site anywhere that is locally accessible, such as a USB thumb drive.

In all honesty, I rarely use file system publishing because it's a relatively simple matter to copy a project folder from one place to another on the local system. However, using EW publishing allows a given backup location to be updated with just the changed files, which could be much faster.

The rest of the praise for the publishing system goes to its completeness. Any folder, file, or combination of files and folders can be published simply and clearly, using UI methods familiar to anyone who has used Windows's file manager, Explorer. None of the new tools are as competent.

Dynamic Web Templates

Yes, I know I said this was a key lock-in for me and in previous articles here I've discussed problems associated with the templates that can make life difficult. But the truth is that the dynamic Web template, despite not actually being dynamic, is a very useful feature. That is especially so for someone who wants to publish a Web site manually, with no server-side programming involved.

Manual publishing is rare in my practice but is still out there. The DWT, combined with the fact that the design view in EW is mostly WYSIWYG, makes it a compelling tool for someone who is not a Web technologies expert. This should come as little surprise because that is exactly the market originally targeted by FrontPage. What I think the developers of Web tools miss is how many self-publishers are out there. I think they think WordPress has taken over that segment; while a valid argument, I still think WYSIWYG, which FP was particularly good at, is desirable.

Dreamweaver is the only other product that does these things, to the best of my knowledge.

Design View (WYSIWYG)

Publishing a static site using a WYSIWYG editor is the main reason why FrontPage was conceived in the first place. I've mentioned before that I don't do a lot of this kind of work any longer but having WYSIWYG around can be very handy. It's like using a word processor to write things instead of having to write the underlying HTML code.

For example, my content management system, SiteCommander, has a Help feature with many pages of content. The content is very static. More important, if I maintained the help system in a database I would have to do a database update to get new information on a client site. That is more difficult and time-consuming than simply copying the suite of updated help files from my master site to a client site on the next time I happen to work on it. I have also found that it is faster to write the pages using EW's design view even though EW's WYSIWYG capability isn't so WYS any longer.

A subtle gotcha with the database approach is that images and other external assets have to be uploaded anyway. With my EW approach, everything related to help is in one folder on the site and can be uploaded quickly.

I value Design View so much that I will keep EW around just to handle the help system. 

Search & Replace

This one may sound really stupid. After all, search is pretty much standard in everything, isn't it?

Not quite. While the search feature in EW has a couple of rough spots, overall it is, again, better and more easily used than the same features in the new tools. Rapid PHP improved this in the 2020 edition but still does not match the fit and finish of the EW capability.

Obit

Here I am, two decades later and almost a decade after EW was discontinued, still using it. I've had some developer friends sniff at my choice, getting all snooty and everything. I've been able to defend my choice very well over the years, withstand the slings and arrows, and my results speak for themselves. Now I know the time has come to say goodbye.

Expression Web has served me well. Rest in peace.