Hard problems in the browser

Fun, exasperating/-ed post from Dave Rupert today about the various hats worn by web developers on the frontend, from design to effective caching, from tracking to accessibility. He's right that frontend roles encompass too much responsibility.

Dave's ending question is a good one: "What's one change we could make to eliminate 80% of the work?" In response, Swyx pointed out that a lot of modern cloud infrastructure—think Vercel, think Netlify, think Supabase—is trying to provide solutions for that 80%.

I suspect, however, that many of the difficult things that Dave mentions in his post occupy the remaining 20%. It's true that Vercel (among others) is building an SDK for the web, and they do provide solutions for e.g. querying the data layer, for caching, or for analytics. They're doing a very, very good job.

But a lot of the "soft" skills associated with building in the browser—things like writing effective CSS, producing accessible markup, or building design systems—aren't, and arguably can't be, produced as an easily consumable libraries. Dave's right that it's "hard to be an expert at the front-end."

All of that being said, cloud infrastructure providers have made it very easy to get 80% of the way there, and for a lot of use cases, 80% is good enough. I wonder if the frontend has a lower average level of experience, since those providers solve a lot of tough problems—problems that, on the backend, I expect you'd need a degree in comp sci to solve. I wish the Stack Overflow Developer Survey let you view experience by role.

The web is a harsh manager, Dave Rupert

More React drama on Twitter this week: a couple of skirmishes around Lighthouse scores, the cost of a page refresh, apps vs. documents, how long should a page be alive. The usual tension between data-driven vs. if-the-stakeholder-is-happy decision-making. A weird amount of handwaving over Jira.

It reminds me of this post from Baldur Bjarnason—specifically, point #82:

...web dev is a pop culture with no regard for history, dooming each successive generation to repeat the blunders of the old, in a cycle of garbage software, wrapped in ever-escalating useless animations, transitions, and framework rewrites.

He's right. Although there's a small class of discerning developers producing wildly successful open-source software (and thus powering a significant proportion of the Internet), and although there's another class of developers building interfaces for the handful of web applications that get truly massive traction (think Jira, think Spotify)—the vast majority of developers at the grind on the frontend are mercy to the developer ergonomics thought-piece of the day. There are business decisions being made all over the world on the basis of which hot take got the most likes on Twitter.

(A sidenote on the cycle: just imagine the hours poured into Next.js over the years. Next.js is the gold standard for React in 2022, but in practice it effectively accomplishes the same thing as PHP + Turbolinks. Most of the value proposition of Next.js is actually Vercel's serverless platform.)

Wes Bos & Scott Tolinski have a relevant perspective on all of this, whenever a question about which technologies to adopt comes up in one of their listener-question "Potluck" episodes of Syntax: if something is going to stick around long-term, you don't need to be an early adopter. The best React developers aren't necessarily the ones writing React.createClass(). Bos & Tolinski have to stick to the cutting edge because they sell courses—but the rest of us can hang around while frameworks go round the Tech Tool Carousel before committing.