Is Modern Frontend Solving Real Problems or Just Creating New Ones? – Insights from the Redis Creator

Emperor's New Clothes: Frontend Developers Fooled by Big Companies

Antirez, the creator of Redis, bluntly attributes the root cause of modern frontend “original sin” to large companies’ internal structures that have hijacked the industry.

“Large frameworks like Angular and React are pushed by big companies. They are products of ‘big‑company design’ and have become the industry norm. It’s as absurd as forcing every website to run on Kubernetes.”

He identifies two extreme demands from big firms:

Complete isolation of front‑end and back‑end because of their organizational split.

Extreme standardisation of applications to simplify hiring and firing.

Both goals run counter to building a good web application.

We have abandoned semantic HTML that works perfectly with browsers.

We now use JavaScript to simulate everything, moving routing, data transformation, and state management to an increasingly bloated client.

We have created a generation of programmers who “know only frameworks, not languages,” mastering React lifecycles without understanding JavaScript fundamentals.

Antirez concludes that front‑end developers suffer the most, constantly learning new ways to implement the same button or pagination, often without truly knowing what programming is.

The Babel Tower Curse: One Button, an Entire Universe

The original post dissects the step‑by‑step “compilation journey” required to write a simple page with modern SPA frameworks:

Your TypeScript code must be transpiled to JavaScript because browsers don’t understand TS.

Your TSX/JSX files must be converted to React.createElement() calls, as browsers don’t recognise JSX.

Hundreds of .js files must be bundled into one or a few files, otherwise a network storm ensues.

During bundling you must perform Tree Shaking to drop unused code.

After bundling you must Minify to shorten variable names and strip whitespace.

Your latest ESNext syntax must be transpiled (e.g., by Babel) to legacy ES5 for older browsers.

Your Post CSS needs processing, adding vendor prefixes like -webkit- and -moz-.

We have gone so far that the source code we write and the code that finally runs in the browser are essentially two different species.

Back to Basics? HTMX and the Backend Renaissance

Amid the collective “siege” on SPA frameworks, the name HTMX is repeatedly mentioned.

HTMX is not a revolutionary new technology; rather, it is a “renaissance.” Its core idea can be summed up in one sentence: “Let’s go back to 1999 and have the backend return HTML directly!”

In the HTMX world there is no front‑end routing, no state management, no virtual DOM. You only need to add a few special attributes to HTML tags:

<!-- Clicking this button makes HTMX request /news -->
<!-- The returned HTML fragment replaces the content of #news-container -->
<button hx-get="/news" hx-target="#news-container"> Load latest news </button>

<div id="news-container"></div>

Understanding this, the complexity of the front‑end disappears. You no longer need a massive front‑end team maintaining a heavyweight Node.js toolchain; a few backend engineers who understand HTML can handle it.

Rational Voices: The Bottom Line Determines the Head

One seasoned full‑stack developer reflects:

“As someone dependent on JS/TS, I have often wondered whether Go or Ruby + HTMX could simplify everything, but I haven’t found a solution that beats the current SPA stack even slightly.”

“Modern web apps are essentially two applications living in different environments (front‑end and back‑end). Accepting this reality yields results that are far more robust in error handling, UX, performance, and maintainability than a server‑rendered stack patched with jQuery/HTMX.”

Another developer warns:

“Do you think HTMX eliminates complexity? It merely shifts complexity from the front‑end to the back‑end, and for apps that need deep interaction or complex state sync (e.g., online docs, drawing tools), HTMX’s simple ‘swap HTML’ approach quickly hits its limits.”

Conclusion: No Silver Bullet, Only Trade‑offs

Beware of big‑company “best practices” : they are often bespoke solutions for internal architectural constraints, not universal silver bullets.

Re‑evaluate the cost of separation : while front‑end/back‑end separation clarifies responsibilities, it also introduces massive communication overhead and complexity. In many scenarios a simple, backend‑driven full‑stack architecture can be more efficient.

Embrace diversity : Whether it’s React’s component model or HTMX’s hypermedia approach, they are just tools. A mature architect should choose the right tool for the right stage and scenario instead of falling into a binary “one is good, the other is evil” mindset.

Modern frontend complexity may be both a historical accident and a necessary response to certain demands. The crucial question is whether we retain the clarity and courage to step back from frameworks and view the whole system objectively.

Resources

https://binaryigor.com/modern-frontend-complexity.html

https://news.ycombinator.com/item?id=47824051

Discussion Prompt

Have you ever been tormented by the modern frontend toolchain (Webpack/Babel/TSX…) and do you applaud HTMX’s “backend renaissance” or see it as a step backward?