a jaundiced eye: Top Ten Reasons Why FrontPage is Evil

a jaundiced eye: intra dig
for tuesday, april 1, 1997.

Top Ten Reasons Why FrontPage is Evil

One of the lists I'm on, hosted by Lynda Weinman (of Designing|Deconstructing|Coloring Web Graphics fame), has had a lively discussion lately concerning the question of whether FrontPage is Evil.

Okay, so maybe it's just been me, posting incessantly to dispel the belief that FrontPage is a site management tool of any worth. But nonetheless, the discussion has, in fact, raged. And out of those posts I've compiled a list of ten reasons why FrontPage is truly Evil and an impure temptation to budding web designers everywhere.

One

FrontPage uses "index.html" or "index.htm" as its default filename, despite the fact that Internet Information Server uses "default.htm". Nothing like a little confusion to add to the fire.

Two

FrontPage relies heavily on the use of proprietary WebBots to provide otherwise open functionality such as searching text indices. These WebBots are easily the most inefficient server-side implementation I've ever seen - for every WebBot, the server must reload and parse the HTML through a DLL interface - placing undue stress on a poorly implemented server.

Three

It is impossible to provide a centrally managed top level introduction and organizational layer to any site developed in FrontPage without confounding the "one author, one web" rule of secure authoring. Either the entire thing is a web, with all authors allowed to write to the web, or the authors cannot link into the top level web without experiencing what they see as broken, unverifiable links.

Four

By extension, it is impossible to use Virtual Directories to easily redefine the logical structure of a site when needs and requirements change - FP creates new webs in the root of the server, without allowing for the definition of VDs for the sake of future revisions.

Five

Ever try to copy an entire web from one location to another, say from a "test" location to a "production" location? Don't bother.

Six

When using FP Extensions on a UNIX web server, the webmaster is required to make the configuration files (such as "srm.conf" on Apache or NCSA httpd) world-writable. Nah, no security risks there.

Seven

FrontPage doesn't easily integrate with any source control mechanisms - unlike other products, developed by people with experience in the document management industry, such as HAHTSite, there is no integration, even with Microsoft's own Visual SourceSafe.

Eight

In a related note, FrontPage doesn't allow for multiple publishing targets - or provide any means for testing a page before it is published. More correctly, I should say that any page opened from FrontPage Explorer is automagically saved to the server whenever the author wants to save his or her changes. Rather than allowing for human error, and providing a way to preview the page before the Office-user's impulse to Save and Save Often takes over, FP assumes that because it is so easy to publish, you may as well go ahead and publish.

Nine

No security for individual, arbitrary directories. The programmers and technical writers who documented the program suggest that any pages which should not be globally acessible be put into a directory conveniently provided for the purpose of hiding them: "_vti_private". Oh, yeah, nice. Web servers have been providing this functionality for years, but the FP programmers and designers decided it wasn't worth the trouble of explaining how to do it.

Ten

FrontPage Editor is a decent approximation of a WYSIWYG HTML editor. This alone would be cause for celebration, but because it is bundled with so many half-assed site management kludges, it essentially cripples the maintenance and management of any site it produces.

Hopefully, I'm wrong about how evil FrontPage is. We'll see.

Steven Champeon

r e c i p r o c a t e

Permanently archived at: http://www.jaundicedeye.com/browse/intra_dig/040197/