3 Web Development Bad Ideas — From my perspective — I told you so…

So, back in the day during the jQuery era, I started my web development journey. It was all about being efficient — you know, writing less and getting more done. Tools, libraries, and frameworks were like the superheroes making developers super productive.

But, things have changed since then. The community’s mindset has shifted big time. We’ve had a bunch of debates, online and offline, about ideas that didn’t exactly simplify stuff. Instead, they added a bunch of unnecessary complexity, making the whole development process way trickier.

So, here’s me, taking a moment in this post to spill my thoughts. I want to vent about all the frustrations I’ve accumulated from trying to warn against certain practices. Turns out, a lot of those things I was against are now outdated or considered harmful. Unfortunately, people didn't listened to my warnings, and now other developers have to deal with the fallout of those not-so-great choices.

A big important disclaimer

I don’t flat-out label any idea as totally bad. It’s more like I think they’re not so hot when you chuck them into a situation where they just don’t fit or end up causing more headaches than actually being helpful.

And for those ahead of the curve who might dig an idea I’ve given the side-eye, let me drop a cool quote. So, there’s this Q&A with Douglas Crockford where someone was pushing back on his thoughts about type systems. Douglas fires back with this gem:

…anytime you see a programmer who’s trying to cling to something that is, using a nice word, “suboptimal,” you know, like if you can find one case that pays off, then that justifies everything. Well, the world’s bigger and more complicated than that. (Douglas Crockford)

https://www.youtube.com/watch?v=GiTiR_Cx_P8&t=544s

1. React — Classes, lifecycles and Parent / Child relationship

Maybe you’re knee-deep in modern React Apps now, but back when it blew up and was the talk of the town, everyone was head over heels for it, and I was sitting there wondering, why?

I got completely sold on Douglas Crockford’s wisdom when he schooled us on using the Best Parts of Javascript. One big lesson I learned from him ages ago was to ditch classes in favor of the functional style — no more scope issues. That mindset seriously changed how I rolled with JavaScript, and it’s probably the best advice I’ve ever gotten in this language.

But here’s the kicker, not for the React Community. Back in the day, my pitch to every developer was, “Let’s not use React for our projects.” None of them seemed to really need that kind of abstraction. Plus, dealing with scope again and those lifecycles like componentDidMount, shouldComponentUpdate, componentWillUpdate, componentDidUpdate, etc.

Back in the day, there was this other buzz going around about composition over inheritance. It wasn’t a groundbreaking idea, but folks in the mainstream were finally getting that inheritance can bring some serious coupling trouble to the table.

So, for that same reason, I found myself wondering again:

Why to use that parent and child relationship for every data on our application? We are making our system weak, every time I remove an intermediate component from the system, the entire system totally fails…

For me, that kind of relationship sorta falls into the same pitfalls as inheritance does to the system. Well, fast forward a few years, and the community calls it out as an anti-pattern, giving it the name: Prop drilling.

So, it wasn’t that React itself was a bad idea, but back then, it wasn’t quite mature enough to elegantly handle the problems we used to face. It was actually making things harder.

But hey, they had a change of heart. Now it’s more functional, no-nonsense lifecycles, and you’ve got slicker ways to pass data between components in the component tree.

Yet, there are still devs out there dealing with the fallout of those old choices — trying to keep dependencies updated, maintaining, and sometimes even thinking about rebuilding the whole system from scratch.

It’s wild, you know? There are tons of legacy apps written in React. Ironically, most of them would probably be less complicated if they were built with WordPress and vanilla JavaScript.

2. Redux & Redux Saga

No doubt, Dan Abramov’s a super sharp dude, and he’s left a big mark on modern front-end thinking. Redux itself was a cool take on a useful pattern (Observer), creating this abstraction to centralize changes and let components react to them.

But here’s the rub — the idea was brilliant, but the implementation? Man, it got overwhelmingly complex.

Easy to say now, right? You might be thinking that. But truth be told, I was trying to wave the flag about that unnecessary complexity back in the day. I even dropped a post on a forum, proposing a different strategy: https://medium.com/@eduardo-ottaviani/inverted-redux-9ac6881d4ebf.

As if all that complexity wasn’t enough, someone rolls in with the Redux Saga idea…

I kicked things off in this post saying there’s no absolute bad idea, but maybe Redux Saga is the exception to that rule. I got stuck working on this straightforward app, just a step-form thing — next > next > done.

Had some API requests in there, and for some reason, someone thought it was a genius move to use Redux Saga, maybe for the learning curve, who knows? All I do know is that nobody on the team could wrap their heads around what the heck was going on in that app.

Funny thing is, I got a shot to do the same app but with vanilla JavaScript. It took a whopping 33 lines of code to get that step-by-step navigation working.

So now what? Well, it looks like Redux is getting the cold shoulder from everyone… right?

What about Redux Saga today?

The community has finally stated that Redux is too complex… 🫠

3. GraphQL

So, Facebook cracked the code on dealing with their data struggles across different projects and smoothing out those performance headaches, especially on mobile apps that throw out a bunch of requests.
Good for them.

The bad part is when every single dev out there thinks it’s the golden ticket for any project, like it’s the next-level evolution of REST API.

Now, you got this new spec in town. Every back-end language has to roll out its own GraphQL implementation. It’s this new DSL language you’ve got to wrap your head around. And with it come all these new headaches — how to transform, filter, and mess with data using this language, not to mention the performance and security headaches.

You start spotting GraphQL in places where it’s like, “Why though?” Take Gatsby, this meta-framework for pumping out static sites with React. They decide to go with GraphQL as the default language for making requests and querying images. Why?

Fortunetely, other meta-frameworks ( Next, Astro… ) alternatives didn't go to the same direction.

Conclusion

If you let the Big Techs call all the shots on how you tackle your problems, you’re gonna lose the knack for critical thinking. And you know what that means — bad choices that mess with both new devs and end users, hitting performance, bugs, etc.

Those examples I threw out there are all real-life messes, and honestly, they’re so complicated, there’s no clear explanation for how they got that way.

Here’s my two cents: get to know and play around with different tools. There’s a lot of options out there for building sites — Parcel, Webpack, different Template Systems, Meta-frameworks, Vite, Static Sites Generators, you name it.

Keep an open mind about tools. Some of the cool ones might not be the hype queens, but that doesn’t make them old or bad. Actually, they might be more mature and stable.

Web development’s got a lot of marketing hoopla, and some of those Big Tech ideas not really worth the trouble. Take a page from their book, get inspired, and maybe cook up something simpler and more fitting for your issues. Who knows, someone might’ve already done it — give it a whirl. If it makes life easier, then boom, decision’s all yours.