The Real Reason Modern Web Development Feels Hard
You're Solving Facebook's Problems, Not Yours
Full disclosure: This post was written by a human (me), polished by an AI (it fixed my grammar and made me sound smarter), then reviewed by me again (to make sure the AI didn't make me sound too smart). Any remaining errors are 100% organic, artisanal, human-made mistakes.
If modern web development feels harder than it should be, you're not wrong. DHH explained why: the dominant tools were built by companies with very different problems than yours. You're using solutions designed for Facebook's organizational complexity, not your product's needs.
The Facebook Factor
Facebook has thousands of engineers. A single feature might involve:
- • Frontend engineers (multiple specializations)
- • Backend engineers (multiple teams)
- • iOS engineers
- • Android engineers
- • Product managers
- • Designers
- • Data scientists
- • Infrastructure engineers
- • QA engineers
- • Release engineers
When 15 specialists touch a single feature, you need tools to coordinate them. React's component model helps isolated teams work independently. GraphQL lets frontend and backend evolve separately. These aren't inherent goods—they're solutions to Facebook's organizational problems.
You're Not Facebook
"Most teams aren't Facebook. They don't have 15 specialists. They have 3 generalists. They're importing solutions for problems they don't have—and creating problems they didn't have."
— DHH on framework choices
Consider the typical startup or small company:
- • 3-10 developers
- • Everyone can (and should) understand the whole system
- • Coordination is face-to-face or Slack, not process
- • Speed matters more than scalability
- • Technical debt is manageable because you know where it is
For this team, React + Redux + GraphQL + TypeScript is overhead. The tools solve coordination problems you don't have while creating complexity problems you didn't have.
The Escape Path
1. Question Every Tool
Before adopting a tool, ask: "What problem does this solve, and do I have that problem?" If the answer is "everyone uses it" or "we might need it someday," that's not good enough.
2. Start Simple, Add Complexity When Needed
Begin with the simplest possible stack. Server-rendered HTML with progressive enhancement. Add client-side complexity only when you hit specific, documented limitations.
3. Consider the Alternatives
Rails + Hotwire, Laravel + Livewire, Phoenix LiveView, htmx—these tools optimize for small teams building products, not large organizations managing complexity.
4. Optimize for Your Context
What's your team size? Your timeline? Your domain? Choose tools that fit your actual context, not the context of a FAANG company whose blog post impressed you.
Permission to Do Less
Here's what DHH's perspective gives you: permission. Permission to not use React. Permission to skip TypeScript. Permission to render HTML on the server like it's 2010.
The industry's default stack is not your default stack. You can choose based on your needs, not the needs of companies with radically different problems.
Web development felt easy in the early days because it was. HTML, CSS, a bit of JavaScript, a server-side language. The complexity came later, imported from organizations that needed it. You might not.
Your Problems, Your Tools
Modern web development feels hard because you're carrying tools designed for someone else's problems. Facebook's organizational challenges became your technical complexity. Google's scale requirements became your architecture.
The solution isn't learning more tools. It's using fewer.
Strip away what you don't need. Return to fundamentals. Build for your users, your team, your scale. Web development can be simple again—if you have the courage to ignore what everyone else is doing.
Related Articles
JavaScript's Dark Ages: How We Lost Our Way (2010-2020)
The era of constant framework churn, build tool complexity, and 'npm install' becoming a full-time job. How React, Webpack, and tooling fatigue burned out a generation of developers—and how we're finally escaping.
The Complexity Industrial Complex: Who Profits From Overengineering?
Why consultants and tool vendors love complicated architectures. The career incentives that promote unnecessary complexity, how to resist the pressure to overcomplicate, and simplicity as a competitive advantage.
The Pieter Levels Model: One Developer, Simple Tools, Millions in Revenue
PHP, jQuery, SQLite powering million-dollar businesses. Why 'boring' technology wins, and what solo developer success stories teach us about the myth that you need modern frameworks to build real products.