That one framework use-case

A tweet from Next.js author Guillermo Rauch sparked uproar on social media, filling my Mastodon timeline quickly with subtweets subtoots. Often with a bitter and cynic tone, people criticize just about anything remotely related to frameworks.

Between the sarcastic and toxic comments, there’s valid critique — critique people have repeated for the last 5+ years. Andy Bell’s Speed for who? is a great post summarizing some of the criticism. I wholeheartedly agree with all of it… when developing certain types of websites.

Although the vast majority of the web is public and should work well on a low-end device on a bad and expensive connection at the most remote place imaginable, it doesn’t mean all websites need to follow that principle.

Frameworks can be good

There’s a very small subset of websites where data-driven reactivity is desired for usability and UX, where outsourcing that complexity to a tool can save a lot of time, where users are always on a stable connection and on a high-end device, and thus care more about new and improved features than a (for them) negligible performance increase. For example, I mainly work on highly interactive B2B products for employees that have a similar or better device and connection than I have. That’s the only use-case.

Although frameworks and Single-Page Applications are synonyms historically, that’s no longer the case. Many frameworks offer server-side rendering and partial hydration, which is an absolute minimum for me. Browsers still load a ton of JavaScript, but at least the content is already there when (and if) that happens.

Like all other tech, it’ll progressively get better. But unlike most tech, frameworks haven’t had decades to mature. Perhaps things aren’t progressing as fast as we’d like, but I’m sure we’ll arrive at a point where they’re mature enough that wide adoption starts to make sense.

Again, for the vast majority of projects, I too aim for a lightweight static or server-side rendered stack for the exact reasons Andy Bell mentions in his post.

Blaming the hammer for hitting a screw

Despite all the things that are wrong with frameworks, I don’t think they are inherently bad. Using a tool for the wrong job, is.

Instead of taking it out on anyone who dare say “framework”, I want educators, mentors, and communicators to do better. As a community, we have failed to teach developers to prioritize users, to inform them that technology impacts user experience, and that we need to be thoughtful about when to use what.

Denormalize toxicity

A significant influx of web developers have no idea when to use frameworks. They’re only taught the benefits and how to use them, and enter the industry relatively JavaScript-savvy.

Now imagine they turn to social media to follow prominent developers. Some of them share intriguing thoughts. Others have interesting discussions with peers. And then there’s a prominent figure that groups the JavaScript community with fascists. Or that CSS framework author that aggressively defends it when someone shares legitimate criticism. Welcome to the web development community, where our dogmas render us incapable to partake in civilized discourse!

It’s ironic how one of our main principles is to build inclusive websites, while actively making the community obnoxious and unwelcoming. Let’s practice what we preach and get back to having constructive conversations again.