"The framework isn't the problem!" is something I've been hearing the apologists for lemon vendors spout for going on a decade now, and I think we need to decapitate this zombie idea once and for all.
-
"The framework isn't the problem!" is something I've been hearing the apologists for lemon vendors spout for going on a decade now, and I think we need to decapitate this zombie idea once and for all.
First, *I know* that 45KB of JS isn't going to break the bank. Duh. That's not the point. The point is that the apologists *don't even have budgets*. Which means that *every* increment above zero is *a priori* too much!
Folks that can't say "when" aren't sophisticated enough to be using JS.
-
Nothing could be further from the truth. The data I embedded at the bottom of last week's blog post was just the smallest taste of this failure-on-a-loop merry-go-round I've been an up-close witness to for most of the past decade:
Platform Strategy and Its Discontents - Infrequently Noted
Alex Russell on browsers, standards, and the process of progress.
Infrequently Noted (infrequently.org)
If Next and Vercel can't (or, to be precise, won't) put the genie back in the bottle, there is no hope for teams with fewer engineers to deploy on the problems NPM culture creates.
-
This is because the toolchains and architectural assumptions of NPM-based frontend culture are *fucked*. Totally and utterly divorced from what delivers acceptable results for most people, most of the time -- both as users, and as businesses.
This deep truth sits underneath everything else: *the way* these frameworks and ecosystems present to the developer assumes they have no self-control and do not know better. All while justifying their wares on the basis that everyone, instead, has mastery.
-
Which leads to the next point: the justification for client-side JS is invariably "interactivity".
But I can count on one hand the number of teams that have done bake-offs to *measure* if one library or approach will improve interactivity for representative users. Even teams that have tons of data about their userbase *do not do this* today! It's a lost art.
And unless an org is practicing the lost art of bake-offs, *it is not sophisticated enough to bet on JS*.
-
So folks are right; the framework *isn't* the problem. It's what choosing *those* tools says about an organisation, and what the indicated lack of performance management maturity portends:
A Management Maturity Model for Performance - Infrequently Noted
Despite advances in browser tooling, automated evaluation, lab tools, guidance, and runtimes, modern teams struggle to deliver even decent performance with today's popular frameworks. This is not a technical problem per se. It's a management issue, and one that teams can conquer with the right frame of mind and support.
Infrequently Noted (infrequently.org)
-
Thomas Michael Semmlerreplied to Alex Russell last edited by
@slightlyoff i think choose lemons with the promise of scaling, in many areas. It’s not true of course, but that is the story that they are telling themselves and other people. Today, I see agencies and in house teams alike talk about next like they talked about with Wordpress. The narrative of a unified stack that will allow them to move faster and save cost in the process is what sells them. Same is true for individuals. Performance is irrelevant as long as the process is cheaper.
-
Alex Russellreplied to Thomas Michael Semmler last edited by
@nachtfunke But it's not cheaper!
