Hacker News Reader

Comment by bofadeez | Hacker News Reader

Modern web development has become a wasteland of over-engineered solutions, and the real issue isn't client-side vs. server-side rendering; it's the industry's obsession with frameworks. Frameworks are not just tools; they're ideologies that developers subscribe to, often blindly. This has led to a monoculture where questioning popular frameworks like React is heretical. Ironically, this 'framework-first' mentality stifles the very innovation it claims to promote. The future of web development should focus on lean, framework-agnostic solutions, even if it means revisiting 'outdated' technologies. The most secure and maintainable code isn't necessarily wrapped in the latest framework; it's code that is simple, well-documented, and, above all, understandable without needing a 'decoder ring' of npm packages.

View on HN

Even every significant website built 15 years ago not in JavaScript involved a framework. In Java, you got Spring. In Python, you got Django. In Ruby, you got RoR. In PHP, you got Symfony. etc.

Blaming frameworks seems misguided.

Yes, they have been relatively stable for the last 20 years, and focus on delivering what the browser does best, HTML and CSS.

While this is your opinion, a majority of the frontend development experience has borne these solutions out of real problems, not in spite of them. Every take like this reeks of never having built large and interactive frontend projects that involve more than 1 developer.

Sure you can get by on htmx/html/css/tailwind/whatever simplistic thing you can conjure up but those things don't SCALE, which is what these frameworks are built to do.

I find it funny, even creative, that you managed to slip in something against tailwind in your comment.

I've got plenty of stories about tailwind not scaling if you have the time ;)

The argument that 'simplistic' technologies don't scale is dismissive of the robust, enterprise-level applications that have been successfully built without heavy frontend frameworks. It's not the tool that scales; it's the architecture and the development practices.

> enterprise-level applications that have been successfully built

Who? When? Where? I refuse to believe this assertion. Are we talking past or present? The whole reason why these frontend focused frameworks exist is because either the existing solutions (pure html, even with preprocessors like handlebars, pure vanilla JS, lower level libs like jQuery) did not scale to meet demand or existing frameworks (JSP, PHP, etc) became a mess at scale.

Everyone loves to throw out these imaginary success stories of corps rolling just with html/css but I've never seen it actually proven true with evidence.

Your skepticism about the viability of enterprise-level applications built without heavy frontend frameworks reveals a narrow understanding of software history and architecture. Let's not forget that companies like Amazon, Google, and eBay built scalable, complex systems long before React or Angular were even conceived. Amazon's initial architecture was famously built on Perl, and Google's original frontend was simple HTML and JavaScript. eBay was initially built using Java Servlets and JSP, and it scaled to handle millions of transactions. These are not 'imaginary success stories'; they are well-documented cases that prove scalability is not solely the domain of modern frontend frameworks.

Your assertion that older frameworks 'became a mess at scale' is a sweeping generalization. Any technology can become a mess if not properly managed; that's not a failing of the technology but of the architecture and development practices. PHP, for instance, powers Wikipedia, one of the top-ten most visited websites in the world, and it handles this scale quite well.

The emergence of frontend frameworks was not solely because 'existing solutions did not scale'; it was also driven by the industry's evolving needs for richer user experiences and faster development cycles. These frameworks solve specific problems but come with their own trade-offs, including complexity and steep learning curves. To dismiss alternative approaches as unscalable without evidence is not just intellectually lazy; it's a disservice to the field of software engineering, which thrives on diverse solutions to complex problems.

Strongly agree. A great example of this hyperengineering is React Router. What should be boring utility code wants to be the opinionated lead singer of your app and introduce breaking changes every few years while the rest of the web has been treating routing like a solved problem for decades.

Full on the spot.

Using traditional Java and .NET stacks for the last 20 years.

Naturally in the context of being yet another cog on the enterprise machine, doesn't always go that way, however when given the option, Java and .NET Web stacks as always.

> This has led to a monoculture where questioning popular frameworks like React is heretical.

If that was the case we wouldn’t have the other problem we have on the front end. A million and 1 different web frameworks.

It's an easy problem space, so in order to 'flex' you're forced to constantly over-engineer and complexify imo.

I think the reality of web development is that outside a few minority of “apps”: figma, google maps, etc. is that basic html, js and css is more than enough. Maybe some jquery, or something like rails or php to update values server side before it’s sent out. Most websites are just text, with some pictures and some forms. Most frameworks are total overkill.

Reply on news.ycombinator.com