Testing 10 JavaScript Frameworks on Their HTML Defaults
Published on FebĀ 12, 2025, filed under development, javascript, frameworks, html, conformance (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
Framework | HTML Errors/āWarnings Source | HTML Errors/āWarnings Hydrated | Comments |
---|---|---|---|
React with Next.js | 0/0 | 0/0 | Unnecessary trailing slashes on void elements |
Vue.js with Vite | 0/0 | 0/6 | Unnecessary use of type attributes |
Angular | 0/0 | 59/0 | Invalid use of bogus _ngcontent-* attributes |
Svelte | 0/0 | 0/5 | Unnecessary trailing slashes on void elements (demo source), unnecessary use of type attributes (demo hydrated) |
Ember.js | 0/1 | 0/2 | Unnecessary trailing slash on void element (source), unnecessary use of type attributes (hydrated) |
Astro | 1/1 | 1/1 | Nesting and heading issues |
Meteor with React | 0/58 | 0/58 | Unnecessary use of type attributes |
Qwik | 24/21 | 22/21 | Bogus attributes |
Remix with Vite | 2+/0 | 0/1 | āFatal Error: Cannot recover after last error. Any further errors will be ignored.ā; then, unnecessary use of type attributes |
Stimulus | 1/1 | 1/0 | Missing title |
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:
Some users may not replace but build on the HTML used by frameworks. Any accessibility, performance, and conformance issues are then inherited and spread.
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:
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.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.
About Me
Iām Jens (long: Jens Oliver Meiert), and Iām a web developer, manager, and author. Iāve been working as a technical lead and engineering manager for companies youāve never heard of and companies you use every day, Iām an occasional contributor to web standards (like HTML, CSS, WCAG), and I write and review books for OāReilly and Frontend Dogma.
I love trying things, not only in web development and engineering management, but also in other areas like philosophy. Here on meiert.com I share some of my experiences and views. (I value you being critical, interpreting charitably, and giving feedback.)