You Probably Don't Want to Just Use HTML

The website justfuckingusehtml.com is written as a critique of web developers who blindly worship web frameworks (specifically frontend frameworks like Next.js). The site lists many valid points about simply using HTML and gives a strong impression that you should probably just use HTML for your next website. However, as the saying goes, the devil is in the details. This post aims to help balance the perspective that the website presents based on my learning and work experience as a web developer.

Yes, HTML (& CSS) Rocks

HTML is a simple markup language and the foundation of websites. Let’s take a look at some big advantages of HTML as stated on justfuckingusehtml.com:

• HTML loads quickly and is inherently fast and accessible.
• HTML is more stable and less prone to breaking than JavaScript.
• HTML is simple, while web frameworks are often bloated and overly complex.
  • For example, server-rendering frameworks like Next.js can introduce hydration errors.
• HTML requires no dedicated support team.
• HTML needs no complex deployment setup.
• HTML can look good with minimal effort, without needing a framework.
• HTML includes useful features like <dialog> and advanced form controls.

As a learner, these advantages were crucial for me. Back in 2020, I took Web Design for Everybody: Basics of Web Development & Coding Specialization on Coursera. As part of the specialization, I completed a project using only HTML and CSS to create a responsive website. After the course, I spent several months working on projects that were CSS-only or CSS-focused, with minimal JavaScript. I only began learning React after I thought I had gained a solid understanding of the basics.

“Let’s Match Poker Cards” is one of the projects that I worked on when I was learning web development in January 2021. The project is written in plain HTML, CSS and JavaScript.

So, during my first few months of learning web development, the advantages of HTML shined. Even as a beginner, I was able to create simple websites, forms, utilities, and even basic games using plain HTML, CSS, and occasionally a bit of JavaScript. So yeah, I would happily echo what justfuckingusehtml.com said, HTML rocks!

As great as HTML is, the truth is that I don’t want to write plain HTML for most of my projects. Let me explain.

You Probably Don’t Want to Just Use HTML

If we take what is written on justfuckingusehtml.com at face value, we might think that everyone should just use HTML for their next website project. While plain HTML works well for simple websites, its lack of abstraction makes it difficult to scale when building dynamic and reusable user interfaces. By dynamic, I mean a UI that can change, adopt, or respond to various factors during runtime. These factors include url parameters (e.g. locale), API responses, user input, etc. By reusable, I mean a unit of UI composed of multiple HTML tags, with styles and logic as well, that can be reused in multiple areas or pages.

The reality is that most modern web projects have, or expect to have, quite a few dynamic or reusable features that require some kind of abstraction to scale. Sure, you can use plain JavaScript alongside HTML to handle dynamic content and interactions. However, as your project grows and you add more features, you are left to organize your plain HTML and JavaScript files on your own. For example, let’s say that on most pages of a website, you want to reuse a layout that includes a header and footer. With plain HTML, you can certainly copy and paste the same code into all the page HTML files. This may work fine for a handful of pages. However, when you add more pages, you would probably want to extract the reused code somewhere. Another problem emerges if the layout contains logic like displaying a different header for logged in users. With the plain HTML approach, you would add JavaScript code directly via script tags. With JavaScript modules, a modern browser feature, you could modulize your logic based on their responsibilities. However, even with this approach, you are left with a lot of architecture decisions to make, which is tedious and easy to get wrong for complex logic.

Let’s illustrate the “just HTML” approach with a simple code example for creating the layout. For starters, let’s say you have a homepage, and this is the HTML file for the page:

<!DOCTYPE html>
<html>
  <head>
    <!-- rest of the head -->
    <link rel="stylesheet" href="layout/styles.css" />
  </head>
  <body>
    <header class="header">
      <!-- implementation of the header -->
    </header>
    <!-- rest of the page content -->
    <footer class="footer">
      <!-- implementation of the footer -->
    </footer>
    <script type="module" src="layout/index.js"></script>
    <!-- other scripts -->
  </body>
</html>

Looks pretty good! Besides HTML code for the header and footer, we have an external CSS stylesheet and some JavaScript file(s) in the layout folder. It seems what justfuckingusehtml.com states is true after all, that just using HTML is a simple and foolproof to develop a website.

However, the devil is in the details. As the website grows, consider the following features you might want to add:

• There are more pages that reuse the same layout as the homepage. However, some pages have a slightly different version of the layout.
• Your website needs to support multiple languages.
• The header has shortcuts to form modals like a login form that appear on the page.

Arguably, you can still implement any of these features using just HTML, CSS, and JavaScript. However, the benefits of the “just HTML” approach vanish quickly as soon as your website requires dynamic and reusable UI.

The lack of abstraction means you have to create your own in order to manage complexity and avoid repetition. Alternatively, you might choose to ignore the complexity and repetition, but this will make the project increasingly hard to read and make changes to, which brings us back to the issue of scalability.

Why You Should Probably Use a Web Framework

According to the article “Web Frameworks: All You Should Know About” by BrowserStack, a web framework is a collection of pre-built tools and libraries that streamlines and organizes the development and maintenance of web applications, making the process more efficient and manageable. The bold part shows why you should probably use a web framework as opposed to just HTML. However, as with everything in life, there are both pros and cons to using a web framework. Some of the cons could lead to the frustrations as vented on justfuckingusehtml.com. The thing is, web frameworks are not going to make building dynamic and reusable UI effortless. Rather, they are intended to make the process more manageable.

Let’s revisit the layout example and see how a web framework can help develop some new features. First, regarding reusability, modern web frameworks and libraries support component-driven UI, which means you can group reusable markup, styles, and logic into units, called components, that can be used throughout your application. Angular, React and Vue are three of the most prominent frontend frameworks/libraries that embrace this approach. Take React as an example, header and footer can be their own components that can be reused on different pages like this:

// Header.jsx
// styles from a separate CSS module file
import styles from "./Header.module.css";

export function Header() {
  // logic for header
  return (
    <header class={styles.header}>{/** implementation of the header */}</header>
  );
}

// Footer.jsx
// styles from a separate CSS module file
import styles from "./Footer.module.css";
export function Footer() {
  // logic for footer
  return (
    <footer class={styles.footer}>{/** implementation of the footer */}</footer>
  );
}

// Page files: Homepage.jsx, Contact.jsx, etc.
import { Header } from "@/components/Header";
import { Footer } from "@/components/Footer";
export default function Page() {
  // logic for the page
  return (
    <>
      <Header />
      {/** implementation of the header */}
      <Footer />
    </>
  );
}

The point is, a component-driven web framework can make it much easier to create and use reusable UI components, which becomes increasingly important as your website grows more feature-rich.

Depending on the framework you use, it may offer many built-in capabilities that ease the development of widely-needed features like internationalization (i18n) for multiple locales, complex form validation, etc. Even with minimalist web frameworks, you can often pull in external libraries to add these features as needed. However, if you are working with just HTML, implementing such features becomes much more involved, as HTML alone does not provide mechanisms for internationalization, complex validation, or similar advanced functionality. You would need to build much of the required logic and infrastructure yourself.

Complexity of Web Frameworks

One of the main critiques of web frameworks stated in justfuckingusehtml.com is the complexity that they introduce. For example, in server-side rendering frameworks which employ the hydration technique to make a server-rendered page interactive on the client, hydration errors can occur for various reasons, e.g. a structural mismatch between server and client. At the end of the day, web frameworks introduce new rules, which can be broken and lead to errors.

The extra complexity also means a steeper learning curve compared to just using HTML. So, all things considered, do the benefits of web frameworks outweigh the complexity they bring?

In my view, the answer is often yes. While HTML alone can be simpler, lighter, and faster for a basic, static one-page site, the complexity quickly increases once you introduce dynamic or reusable UI elements or add more pages. On the other hand, although a web framework may initially seem overwhelming or bloated compared to plain HTML, its complexity becomes justified as your project grows to include multiple pages and dynamic, reusable components.

Web Frameworks Can Be Fast

There is a myth that due to the complexity of web frameworks, any website built with them must be slower than pure HTML.

In reality, the performance of a website depends on many factors beyond just the choice of using a framework or not. While it is true that frameworks often introduce overhead, such as additional JavaScript, CSS, or server-side processing, well-designed frameworks are often highly optimized and can deliver excellent performance when used correctly. In fact, some frameworks are engineered to be faster than basic implementations, thanks to features like efficient rendering, smart caching, and optimized resource management.

Take Astro as an example which this blog site is built with. Astro is specifically designed to deliver high-performance, content-focused websites. Unlike many traditional frameworks that ship large JavaScript bundles to the browser, Astro takes a “zero JavaScript by default” approach. This means that unless you explicitly add interactive components, Astro will only send static HTML and CSS to the client, resulting in load times comparable to pure HTML sites.

AI Doesn’t Make “Just HTML” Scalable

There’s also an interesting argument: if AI can generate code, why bother using a web framework when AI could simply write the HTML for you, allowing you to enjoy all the benefits without the extra complexity?

There’s no denying that AI eases the burden of writing repetitive code, which absolutely makes writing HTML easier and less time-consuming. However, while AI tools can automate and streamline the creation of HTML, CSS, and JS code, they don’t eliminate the underlying challenges of building and maintaining complex, dynamic, and scalable web applications. Web frameworks provide structure, enforce best practices, and offer built-in solutions for common problems. Even with AI assistance, frameworks help manage complexity as your project grows, ensuring maintainability and consistency that raw HTML alone can’t provide.

Conclusion

I like HTML and I think it is great, but saying you should only use HTML because web frameworks are bad is misleading. Yes, web frameworks are inherently more complex than HTML. However, this complexity is intentional. It is designed to help developers avoid even greater complexity that would arise from having to create their own solutions to common problems that frameworks have already solved.

The “just HTML” approach can be fantastic for a simple website though. For a moderate amount of dynamic UI logic, things can become more manageable with the help of libraries like htmx (for server interactions) and Alpine.js (for client-side interactivity). On the other hand, a framework helps if your website has dynamic and reusable UI. When in doubt, ask yourself if you plan to add plenty of UI logic to your website. If yes, you should probably go with a framework. If not, instead of just using HTML as justfuckingusehtml.com suggests, try both and see which one you prefer.