Testing 10 JavaScript Frameworks on Their HTML Defaults

Published on Feb 12, 2025, filed under development (feed). (Share this on Mastodon or Bluesky?)

I don’t know how it is for you, but, traditionally a front-of-the-frontend developer, I’ve always been skeptical about JavaScript frameworks. I’ve been attributing a good part of the HTML crisis—that most sites ship invalid and fantasy HTML—to them.

That’s something I wanted to probe. I took 10 popular JavaScript frameworks, spun up their demo or started or base projects (using all defaults), and validated the HTML source (both raw and hydrated).

Modern JavaScript Frameworks and Their HTML

Why Out-of-the-Box HTML Matters

Before I give my view on these results, let’s be clear: This is pretty rough. It looks at the out-of-the-box experience with these frameworks, one that cannot represent how the teams behind the frameworks use and advocate for HTML in other places, or how the frameworks end up being used. It’s also no analysis of each prevalent HTML writing style and its adequacy.

But, this still gives us a taste. That taste is important for two reasons:

1. Some users may not replace but build on the HTML used by frameworks. Any accessibility, performance, and conformance issues are then inherited and spread.

2. The HTML used by frameworks sends a signal in terms of the importance of HTML: It can send a useful signal, making HTML a first-class language important to master, or it can send a poor signal, as if HTML quality wouldn’t matter.

Both is relevant because frameworks are multipliers—the more popular a framework, the greater the effect. ^*

Observations and Conclusion

There are two things I think we can note:

1. Frameworks, like websites, come with pretty embarrassing HTML errors (and warnings). Use trailing slashes for void elements? I know some don’t mind these, but that’s XHTML–HTML. type attributes on scripts and style sheets? That’s 90s/2000s coding. Custom namespaces? That, too, is reminiscent of times past.

2. But, it’s not that bad! The good thing about those embarrassing HTML errors is that they’re pretty easy to fix. ^† Like a professional frontend developer would (I keep rubbing people’s noses in this because HTML conformance is good for our field), framework teams could validate the output of their HTML and fix the problems. And, there are frameworks that come with valid output. This is basic, yes, but basic is where it starts.

Personally, am I less skeptical about JavaScript frameworks now? Yes!—I actually even got a bit curious about some, like Svelte and Astro. And maybe my view changes further, with more projects that necessitate them—and JavaScript frameworks ensuring their HTML output does at least meet the most basic of professional standards. Peace ✌️

^* If you ask me, this needs a lot more attention, to the point where our frameworks, site generators, and content management systems are opinionated but flawless in terms of their out-of-the-box quality. What impact has WordPress had, to use a different example, on the average HTML quality on the Web? With their popularity, they could literally lift all boats.

^† Frankly, this point also makes the whole topic of HTML conformance incredibly frustrating. Most issues are super-easy to fix. And yet—grant me to exaggerate to make the point—our field, where people earn three or four times as much as a police officer, fire fighter, or nurse, can’t be bothered to close a tag or rename an attribute. When we act like this, we are not being professionals, and we do a disservice to our field—because we don’t take our own work serious enough to do it right. It’s imperative that frontend developers ship valid code.