It wasn’t the idea that failed: it was the execution

Since writing my new talk, An Introduction to the World Wide Web for Very Senior Programmers, in which I transport the audience back to the year 1995, I’ve become somewhat of a proud and nerdy Internet historian. So much happened on the web in 1995. HTML 2.0 was released in September and saw the introduction of the HTML <img> tag, transitioning the online experience from something that resembled reading books and formal documents, to flicking through colorful magazines or photo albums. JavaScript was released in December 1995, which moved the web from a read-only medium to an interactive experience. Multimedia tools like Macromedia Shockwave Player and FutureWave FutureSplash Animator were created in 1995 out of a desire to bring exciting and interactive CD-ROM-like experiences to the browser.

While the end-user experience was evolving, new tools to support web developers who were building websites were also being invented. The World Wide Web Consortium (W3C) was formed in 1995. And, whilst the first version of CSS was not released until 1996, the 1994 proposal for Cascading HTML Style Sheets was being developed by the W3C. This would give web developers full control over the design of their websites, instead of allowing end-users to enhance the visuals of their internet-surfing experience using proprietary browser configurations. And, whilst the web was becoming more visual, so were the tools used to build websites.

It all started with Visual Basic

In 1991, Visual Basic was launched for Windows software application development. Visual Basic was a graphical user interface (GUI) that provided a visual abstraction layer on top of C/C++ and the Win32 API. Ryan Lucas describes this historical release in detail in The history and legacy of Visual Basic, and pays particular attention to how it saved the careers of “millions of mainframe COBOL programmers who were looking with terror at the microcomputer invasion,” as recalled by the creator of Visual Basic, Alan Cooper.

Whilst application developers were embracing a more visual way of working in the early 90s, developers on the web were still confined to the command line, Notepad, and MS-DOS Editor on Windows. That is, until FrontPage 1.0 was released in November 1995.

FrontPage was developed by Vermeer Technologies, and was categorised as a “World Wide Web publishing and site management tool”. Like Visual Basic, FrontPage was a WYSIWYG (what you see is what you get) visual interface, and this tool built HTML. It also provided a personal web server, which allowed you to preview your website on your local machine as you built it. It also included templates, automated scripts, and more. FrontPage was acquired by Microsoft just two months later in January 1996, and was rebranded to Microsoft FrontPage in June 1996 to coincide with the release of version 1.1.

Around the same time, a company called iBand worked on a similar visual tool to FrontPage called Backstage Designer. And, as is seemingly standard practice in this industry, iBand was acquired by Macromedia in 1996, and soon rebranded the Backstage Designer product as Macromedia Backstage Desktop Studio, which in 1998 became a web development GUI you may be more familiar with: DreamWeaver.

Development tools for building games were also evolving in the same way at the same time. Unreal Engine 1, a GUI built in Visual Basic, was also released in 1995.

And what’s very interesting to note at this point, is that while game development has largely adopted visual development tools across the industry, web development seemingly abandoned the visual tools of the mid-late 90s. Thirty years later, most of us are still building websites and web applications using text editors. Why is that?

Why didn’t we adopt visual website tools in the 90s?

The bottom line is that visual website tools in the 90s (and beyond) produced terrible HTML markup, and therefore, pretty terrible websites. I remember fondly using the Apple website builder iWeb in the early 2000s. In fact, it wasn’t very long ago that a website I built for a client in 2008 using iWeb was still up and running. The text-based CMS I built for them, which displayed a text file in an iframe that they uploaded via FTP, really stood the test of time. But now I have professional knowledge and experience of building things for the web, I know that the HTML markup that iWeb produced was absolute filthy garbage. And if the HTML markup is garbage, then your site is not accessible to those who use assistive technology, such as screen readers.

In 1986, IBM announced the first screen reader, but it wasn’t until the mid 90s that screen readers started to become a little more accessible themselves, when JAWS was released for Windows 1.0 in 1995. The first web accessibility guidelines, later branded as the Web Content Accessibility Guidelines or WCAG, were published in January 1995. Yet, despite this, tools that were created to build websites were not ever seemingly built with these official standards in mind. This goes for tools built in 1995, and astonishingly, 2025.

This week on May 7th 2025 Figma announced Figma Sites, a tool to publish your designs built in Figma directly to the web. But this new product has not been well received. Adrian Roselli warns us: Do not publish your designs on the web with Figma Sites.

It’s no surprise we weren’t getting it right in 1995, if we still can’t get it right 30 years later with all of this knowledge, experience, and empathy under our belts. And I’m not even going to mention at this point how AI can’t get this right, either. Of course it can’t; it doesn’t possess the capacity for empathy.

Developers want control

Developers want complete control over their HTML, CSS and JavaScript: and rightly so. If visual web development tools can’t generate clean and semantic HTML, organized and debuggable CSS, or performant JavaScript, it really is a no-brainer to continue to build websites and web applications using text-based web frameworks, or rolling your own.

It is no secret that I am writing all of these things on the Nordcraft blog, and that Nordcraft is an open-source Web Development Engine which combines a web framework with a suite of advanced visual tools that let designers and developers collaborate to build high performance web applications, and that I work at Nordcraft. And you might think that Nordcraft is just another visual website builder that produces the same old garbage that all the other visual tools do. But speaking as someone who has been building websites and writing code for over 20 years, and as someone who likes complete control over said websites and code, I can say for a fact that Nordcraft is very, very, different.

Nordcraft actually gives you control

In Nordcraft, your HTML markup is yours to control. Using the Nordcraft editor, you build your HTML structure in the same way you build HTML with text, using semantic element tags of your choosing, with full access to adding attributes and other web platform-based functionality. Nordcraft does not prescribe how to build your HTML markup: you do. The only difference (and advantage) is that you are building your HTML on a WYSIWYG canvas, where designers can collaborate with you and add design flair as part of the process, not as some preliminary task that sees designs in Figma thrown over the fence in a developer’s general direction (which is, all too often, the case). CSS and JavaScript work in the same way: you have complete control over what you ship to the browser, without any unexpected nonsense.

It’s 2025, and we can do better than what has come before us, and what is, unfortunately, currently unfolding in this visual web development landscape. By giving you, as developers and designers, full control over the end result you envision, I am confident that Nordcraft won’t suffer the same fate of the early visual tools of the 90s, or Figma Sites in 2025.

Your fate is in your own hands, as well as the fate of your websites.