Oldtimey

So many good points here. The gist? React is not a framework. Next.js barely is. Rails, Laravel, and other far more mature frameworks provide you with the majority of what you need to build an application, leading to you writing less code.

But come on: we’re living in the 2020s and if you’re not at like 95% “framework does it for you” for things that aren’t business logic, then you’ve lashed yourself to a very bad mast ‒ you’re stuck building rote infrastructure instead of working on your app, likely creating a bunch of nasty attack surfaces along the way.

What to expect from your framework

I’m a roll-my-own kinda guy. In the itch the get this blog back in working order I considered both flat-file HTML and building a custom blogging app in PHP. Yeah, I’m a glutton at times. My point is I landed on Astro because I didn’t need a CMS and flat-file is just better for a site like this. Even though I have spent much of my career fighting the urge to reinvent wheels, I have largely used frameworks like CodeIgniter, Laravel, and Rails to get the job done better. Why? They handle the stuff that 1) I don’t want to handle and 2) I don’t know to handle.

React, well:

I would argue that React in itself gets you basically nowhere. It’s a templating language with benefits.

The hard part of an application— and I’ve built React applications for the better part of the last decade— is not the UI layer. HTML and CSS. It ain’t hard. No, the hard part is the business logic. The amount of reinventing routing in every app, reinventing connecting to APIs, the list goes on.

React itself is a templating language. It’s a good one. Half of what drew me to Astro— what powers this new blog— is the JSX syntax and components. But as Johan says, nearly every major framework has this now. Laravel, CraftCMS, Rails. This is standard. Plus they do everything else.

Once you start hitting the cursed parts of your application, the places full of dragons and cobwebs and sweary code comments, React won’t be there to hold your hand. It’ll shrug and say “add a Provider or something, idk.”

So why do we not just use these tried and true frameworks? They feel dated. Maybe many companies switched to mostly JavaScript engineers that don’t know anything other. Instead of hiring folks that can solve problems no matter the solution, they hired specialists. Same reason I warned years ago against hiring folks that listed jQuery on their résumé instead of JavaScript.

It might feel retro or oldtimey and maybe not as fun while you’re building, but your application will be better for it.

Hey! Did you enjoy what you just read? Like buttons and shares may stoke the ego, but coffee fuels the body. No subscription, just $3.

Buy Me a Coffee!

Other posts you may enjoy!