The only frontend stack we should talk about
This headline could have been another alternative title of our “Back To The Future” talk at the c’t webdev conference in November 2025. In our talk, Andreas and I shared our story from a recent project at Boehringer Ingelheim where we radically simplified our frontend stack of a web app over a span of few weeks.
Photo: Henning Koch on LinkedIn — creator of Unpoly
One key message of our talk was: Less is more. Webstandards matter. Simplicity rules.
In our project, we questioned core assumptions: Can we guarantee JS execution? Network failures, corporate proxies, ad blockers etc. — all can break JS. Could we eliminate the JS dependency for form rendering and reduce complexity with server-rendered HTML?
These thinking led to a significant simplification of our tech stack some weeks later: Server-rendered HTML, CSS and sprinkles of HTMx for some “app-feeling” interactivity … or in short: Hypermedia
In my opinion, we engineers very often neglect real-world constraints — accessibility, slow connections, older devices — just to name a few.
Consider these persistent failures:
- 95% of the biggest one million websites are broken in terms of accessibility
- We routinely ship invalid, semantically incorrect HTML
- We assume everyone has JavaScript enabled, breaking content and functionality for those who don’t
We’ve been optimizing the wrong layer. While we debate React vs Vue vs Svelte, we’re shipping broken HTML to users. What if these aren’t framework problems, but fundamental misunderstandings about what we’re actually building? The framework choice doesn’t fix that. Forget the tooling debates — focus on what actually ships to users.
So … The only frontend stack we should talk about is:
- HTML for semantics and accessibility
- CSS for layout and visual aesthetics, and
- JavaScript, progressively enhanced, for interactivity when it cannot be achieved natively
That’s it!
That’s what browsers know at its core, and they know it quite well today.
Any framework, library, or build tool name can be left out of that list — it’s irrelevant which tool creates the HTML, CSS, and JS output. The output needs to work for the user. You can break HTML, CSS, and JS with any framework if you don’t understand what’s happening in the browser, e.g. not knowing how to use a button properly. Frameworks abstract away fundamentals — but you must understand what’s happening beneath.
Users expect fast, accessible, and reliable experiences.
They don’t care about the technology — they only care, in a negative way, if the technology setup breaks their experience along the way.
Starting doing this:
- Put users first. Think from their perspective, not your developer preferences (and knowledge around a specific framework). Adapt to what users need and want. If you don’t know, ask them. For example, in our project, user testing sessions revealed some issues we as a team didn’t anticipate.
- Validate constantly. Check your HTML, CSS, and JS output for semantics, accessibility, performance, and reliability. The web is full of tools and resources.
- Explore the platform. Challenge yourself to discover what the modern web can do natively. Pure HTML, CSS, and a bit of vanilla JS might work even better.
If you want to dive deeper, here are some of the inspirations for our talk
Let me end this article with the opening quote of our talk:
Photo: Manuel Feller