Why I Miss FrontPage, and Why Today’s Web Is Better Anyway
I miss a particular kind of simplicity, and anyone who built websites in the late 1990s and early 2000s will know the one I mean. You opened Microsoft FrontPage, typed into a page that looked like the finished product, dragged a table border until the layout felt right, and clicked Publish. There was no build step, no package manager, no framework to choose, and no dependency to update. The distance between an idea and a page on the internet was measured in minutes. Today that distance is often measured in tooling decisions. As someone who now builds software for a living, I want to examine that trade honestly: what the What-You-See-Is-What-You-Get (WYSIWYG) era offered, what it quietly cost, and why modern development, for all of its complexity, is the better foundation on which to build.
The appeal of the visual editor
The central promise of a WYSIWYG editor was that the author never needed to understand the medium. A person who could use a word processor could produce a website. That was a genuine democratization. Small businesses, hobbyists, schools, clubs and individual enthusiasts published pages that would otherwise have required hiring a programmer. The feedback loop was immediate: change a font, see the font change. Because the editor and the output were visually identical, the mental model was easy to hold in a single head.
The tooling was also self-contained. FrontPage bundled page editing, site management, link checking, themes, and publishing into one application. A site was a folder, and the folder was the whole truth. There was little to configure and very little that could break between your machine and the server, because the server did little more than hand files to browsers. For a single author maintaining a modest site, this was a remarkably low-friction way to work. The cognitive load was small, and for many people that mattered more than any technical virtue.
What the simplicity concealed
The difficulty with the visual-editor model is that the simplicity lived in the interface, not in the result. Beneath the friendly surface, the editor was generating markup on the author’s behalf, and that markup was frequently poor. Layout was commonly achieved with nested tables and spacer images, a technique that abused structural elements for presentation. Formatting was scattered through the page as repeated inline attributes rather than defined once. The same page, opened in a different browser, could look noticeably different, because the editor reflected one rendering engine’s interpretation of the document and the web contained several.
Accessibility and portability suffered as a consequence. A screen reader navigating a page built from layout tables encounters structure that carries no meaning. A phone, a device that did not yet exist as a mainstream browsing platform, could not reflow a design whose proportions were frozen in fixed pixel widths. Search engines had to infer meaning from markup that expressed none. Editing was also quietly lock-in: the tidy visual workflow depended on the vendor’s own extensions and conventions, and leaving the tool often meant inheriting a tangle of markup that no human had chosen to write. The editor was easy to start and difficult to leave.
There was also a ceiling. The WYSIWYG model is excellent for documents and weak for applications. The moment a site needed to respond to a user, to remember who they were, to fetch live data, or to adapt to a screen size, the visual metaphor ran out. Authors who had learned the tool, but not the medium, found themselves unable to move beyond it. The abstraction that had welcomed them in now stood between them and what they wanted to build.
How websites are designed today
Contemporary practice separates concerns that the old tools fused together. Content, structure, presentation and behavior each have a home. Semantic HTML describes what the content is, a heading, a list, a navigation region, an article. Cascading Style Sheets describe how it should look, in one place, applied consistently. JavaScript, used deliberately, describes how it behaves. Layout systems such as Flexbox and Grid replaced the table hack with tools designed for the job, and responsive design lets a single document adapt to a watch face, a phone, a laptop and a wall-sized display.
Around that core sits a mature ecosystem. Version control records every change and allows any mistake to be undone. Automated builds validate, optimize and deploy the site. Component libraries and design systems let a team express a button once and reuse it everywhere. Browser developer tools expose the live structure of any page and make debugging an inspectable activity rather than a guessing game. Standards bodies and vendors now converge on common behavior to a degree that would have astonished a developer in 1999, so a page written to the standard behaves, in broad terms, the same way everywhere.
The genuine costs of modern practice
It would be dishonest to present this as pure progress, because the nostalgia has a rational core. Modern web development imposes real overhead. A newcomer must learn HTML, CSS and JavaScript, then a framework, then a build tool, then a package manager, then a deployment pipeline, before producing anything that resembles a finished page. The dependency graph of a typical project is vast, and each dependency is a potential source of breakage, security vulnerability or abandonment. Tooling churns quickly enough that knowledge acquired a few years ago may already be partly obsolete.
The result can be over-engineering. Sites that are essentially a few pages of text sometimes ship with application frameworks and large bundles of script, loading slower than the plain documents they replaced. The feedback loop that made visual editors delightful, change something and see it instantly, has had to be rebuilt with hot reloading and live previews, and it is not always as dependable. Complexity also concentrates expertise. Where a hobbyist could once build and own an entire site, the same hobbyist may now feel that the craft belongs to specialists, which is a real loss to the open, amateur spirit that made the early web vibrant.
Weighing the two approaches
Set side by side, the two eras optimize for different things. The visual-editor era optimized for the speed of the first page and the lowest possible barrier to entry. Modern development optimizes for the long life of the site: its maintainability, accessibility, performance across devices, security, and ability to grow. The first favors the author at the moment of creation. The second favors everyone else, the readers, the future maintainers, the people using assistive technology, and the author six years later who must change something and cannot remember why it was built that way.
That distinction explains why the nostalgia is both sincere and misleading. I remember the ease of the first afternoon, not the cost of the fifth year. A FrontPage site that was never touched again may still load today, but a site that needed to adapt to touch screens, to privacy regulation, to new accessibility expectations, or to a redesign was often cheaper to rebuild from nothing than to repair. Durability has a price, and modern tooling is largely the payment of that price up front, in return for a site that can evolve without being thrown away.
It is also worth noticing that the simplicity has not vanished; it has moved. Today’s content management systems, block editors and site builders deliver much of the visual immediacy that FrontPage once offered, but they generate structured, semantic output rather than tangled tables, and they sit on top of the standards-based foundation described above. The best of the old promise survived. What changed is that the abstraction now rests on a sound base instead of concealing an unsound one.
A practical middle path
The most useful lesson is not to choose a side but to match the tool to the problem. A personal page, a small club site or a simple brochure does not require an application framework, and choosing one is an avoidable cost. Starting with plain semantic HTML and a modest stylesheet captures most of the old simplicity while retaining the modern benefits of accessibility and responsiveness. Conversely, a product with accounts, live data and many contributors earns its tooling, and attempting to build it with a page editor would simply relocate the complexity into failure.
Teams can also protect the beginner experience deliberately. Offering a visual editing layer on top of a clean underlying structure lets non-specialists contribute without damaging the foundation. Keeping dependencies few, preferring established standards over novelty, and measuring the cost of every addition against the value it delivers are habits that keep modern projects closer to the lightness people remember. Simplicity is not a historical accident that modern developers lost; it is a discipline that must be chosen again with each project.
Conclusion
Missing FrontPage is reasonable. It offered a humane way into a new medium, and it let ordinary people become publishers at a time when that was extraordinary. But the ease it provided was purchased with markup that did not age well, designs that did not travel between devices, and a ceiling that capped what its authors could build. Modern development is harder to enter and heavier to carry, yet it produces sites that are more accessible, more portable, more secure and far more capable. The honest summary is that the old world made the first page easy and the tenth page painful, while the new world makes the first page harder and the thousandth page possible. Where we can combine the two, a welcoming editing experience over a rigorous foundation, we get the best of both, and that is the direction the craft is, thankfully, already moving.
~Jen
