The Great JavaScript Framework Lie: Why You Probably Don't Need React
Vladimir Elchinov
01 August, 2025 21:57
You've been sold a lie. A big, complicated, expensive lie wrapped in JSX syntax and delivered through a firehose of npm packages. The lie goes like this: "You need a JavaScript framework to build modern web applications." More specifically: "You need React."
Bullshit.
The Emperor's New Framework
Let me tell you a story. In 2013, Facebook released React to solve their specific problems with building a complex social media platform. Fair enough. But then something strange happened. The entire web development industry collectively decided that every website—from simple blogs to small business pages—needed the same solution that Facebook used for their billion-user platform.
It's like seeing someone use a crane to move their couch and thinking, "Damn, I need a crane for my studio apartment!"
Here's what React evangelists will tell you that you need:
"Virtual DOM for Performance"
Reality check: The browser's native DOM is already optimized by teams of brilliant engineers at Google, Mozilla, and Apple. It's fast. Really fast. Most "performance problems" you'll encounter are from downloading 500KB of JavaScript framework, not from DOM manipulation.
"Component Reusability"
You know what else has components? Server-side templates. Partials. ViewComponents in Rails. Include files. We've been building reusable components since the 1990s. We just didn't need a 200MB node_modules folder to do it.
"State Management"
Oh, the infamous state management problem. You know what manages state really well? The fucking server. Sessions. Databases. Cookies. These technologies have been battle-tested for decades. But no, let's reinvent the wheel with Redux, MobX, Zustand, and whatever the flavor of the month is.
"Better Developer Experience"
Is it though? Is troubleshooting a white screen because one of your 1,847 dependencies broke really a better experience? Is explaining to your client why their simple form takes 3 seconds to become interactive a better experience? Is spending half your day configuring Webpack a better experience?
The Real Cost of the Lie
Let's talk numbers:
Average React app bundle size: 200-500KB (just for the framework)
Average Rails HTML response: 10-50KB (complete, interactive page)
Time to interactivity for React SPA: 3-8 seconds on average mobile connection
Time to interactivity for server-rendered HTML: Immediate
"We need a React developer" has become the new "we need a rockstar ninja." Companies are paying $150k+ for developers to build what could be accomplished with basic HTML and CSS. They're not paying for skills; they're paying for framework knowledge that will be obsolete in 2 years.
The Maintenance Disaster
Your React app from 2019 is now "legacy code." The patterns have changed. The best practices have shifted. Half your dependencies are deprecated. That Rails app from 2010? Still running strong with minor updates.
The Learning Curve Cliff
New developer on your team? Better budget 3 months for them to understand your:
Build system
State management pattern
Component architecture
Testing framework
CSS-in-JS solution
Routing library
Form library
Animation library
[Insert 20 more libraries here]
With Rails? "Here's MVC. Here's our conventions. Start contributing today."
Let's be honest. There ARE legitimate use cases for React:
You're building Facebook - Complex, real-time, highly interactive social media platforms
You're building Figma - Browser-based applications that rival desktop software
You're building a game - Highly interactive, graphics-intensive applications
Notice what's NOT on this list?
Your blog
Your e-commerce site
Your SaaS dashboard
Your corporate website
Your landing page
99% of what we build on the web
The Alternative: Embrace Simplicity
Here's the secret the JavaScript Industrial Complex doesn't want you to know: HTML, CSS, and a sprinkle of JavaScript are enough for almost everything.
With Rails and Hotwire, you get:
Real-time updates: WebSockets built-in with ActionCable
SPA-like interactions: Without the SPA complexity
Progressive enhancement: Works without JavaScript
SEO-friendly: By default, not as an afterthought
Accessibility: Because you're using real HTML
Performance: Sub-100ms response times
Developer happiness: Because you're not fighting your tools
A Real-World Example
Let me show you the difference. Here's a todo list in React:
// 200+ lines of code across 5 files
// TodoApp.jsx, TodoList.jsx, TodoItem.jsx,
// useTodos.js, TodoContext.js
// Plus: package.json with 50+ dependencies
// Plus: webpack.config.js
// Plus: .babelrc
// Plus: setupTests.js
// Time to first paint: 3+ seconds
lang-jsx
Here's the same thing with Rails and Hotwire:
<!-- app/views/todos/index.html.erb -->
<%= turbo_frame_tag "todos" do %>
<% @todos.each do |todo| %>
<div><%= todo.title %></div>
<% end %>
<% end %>
<!-- That's it. One file. Instant load. -->
lang-erb
The Truth They Don't Want You to Hear
The vast majority of web applications don't need a JavaScript framework. They need:
Good information architecture
Fast server response times
Progressive enhancement
Semantic HTML
Thoughtful CSS
That's it. That's the list.
Breaking Free from the Lie
If you're trapped in React hell, there's hope. You can:
Stop the madness: No new React projects for things that don't need it
Migrate gradually: Rails with Hotwire can replace React components one at a time
Educate your team: Show them there's a better way
Vote with your feet: Join companies that value simplicity over complexity
The Future is Server-Side
The pendulum is swinging back. After a decade of JavaScript madness, developers are rediscovering the joy of server-side rendering. The major frameworks are all adding SSR support, basically admitting that serving HTML from the server was right all along.
But why use a complex JavaScript framework to do server-side rendering when you can use a framework designed for it from the start?
Conclusion: Choose Simplicity
The next time someone tells you that you need React for your project, ask them why. Really push them on it. Nine times out of ten, you'll find that they can't give you a real reason beyond "that's what everyone uses" or "that's what I know."
Don't fall for the lie. Your users don't care about your framework. They care about fast, accessible, working websites. And despite what the JavaScript Industrial Complex tells you, you don't need React for that.
You just need to remember what the web was built for: delivering hypertext. It's right there in the name. HyperText Markup Language.
Maybe it's time we started using it again.
---
Ready to build something simple? Check out Rails Blueprint - the anti-React starter kit for developers who want to ship, not configure.
