@nachtfunke But it's not cheaper!
Posts
-
"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.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)
-
"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.
-
"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.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*.
-
"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.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.
-
"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.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, by @muan , should be on every wall in every tech office@muan And, as a reminder, you can buy the shirt as a fundraiser for our friends at @owa here:
Anti Javascript Javascript Club | Bonfire
Show the world how much you love Javascript by writing as little of it as possible.. All t-shirt sale proceeds will be donated to the Open Web Advocacy. Open Web Advocacy...
Bonfire (www.bonfire.com)
-
This, by @muan , should be on every wall in every tech officeThis, by @muan , should be on every wall in every tech office:
JavaScript dos and donts @ Mu-An Chiou安
Do use JavaScript when the core functionality of your feature cannot function with only HTML. when the core functionality of your feature can benefit from some JavaScript. Start with only HTML, then progressively enhance it, so it can ...
JavaScript dos and donts @ Mu-An Chiou (muan.co)
-
I, for one, appreciate the bright-eyed optimism of these folks scheduling meetings tomorrow afternoon and from 8am on weds. -
I, for one, appreciate the bright-eyed optimism of these folks scheduling meetings tomorrow afternoon and from 8am on weds.I, for one, appreciate the bright-eyed optimism of these folks scheduling meetings tomorrow afternoon and from 8am on weds.
-
A brief work interlude: we're hiring a lead Web Platform PM!A brief work interlude: we're hiring a lead Web Platform PM! A chance to work closely with Edge's platform (and Chromium) team in a strategic role, working closely with me and other PM leads:
-
*All* of this is JS-optional, progressively enhanced HTML.*All* of this is JS-optional, progressively enhanced HTML. All of it.
Joe Lanman (@[email protected])
so with the GOV.UK platform you can now: - send emails, texts and letters - take payment, including direct debits - make accessible interactive prototypes - use a common design library and frontend code and - make accessible forms with no code necessary https://platforms.service.gov.uk
Hachyderm.io (hachyderm.io)
-
@slightlyoff what's your current low-end "this is the Android phone the world are actually using, so you should test with it" recommendation? -
This post by @pluralistic shakes loose a thought I was talking over with a friend the other day: modern webdevs have made themselves marks for SaaS-adjacent, infantalising abstractions in large part because they assume themselves immune to marketing.This post by @pluralistic shakes loose a thought I was talking over with a friend the other day: modern webdevs have made themselves marks for SaaS-adjacent, infantalising abstractions in large part because they assume themselves immune to marketing.
-
don't worry it'll soon be monday@GossiTheDog Kevin.
-
I just realized that nothing irks me more (UX-wise) than lag when typing text.@stoyan Classic of the genre (by @notwaldorf
-
> libio is the glibc component which implements the foundations of FILE * streams support (printf and scanf are part of the stdio-common subdirectory.)@whitequark Nearly spat out my coffee reading that.
-
Reactors debating performance have the energy of boomer "car guys" that want to tell a working mechanic, in 2024, about how much better carburetors were.@escarpment @nickchomey Here's some context:
The Market for Lemons - Infrequently Noted
New web services are being built to a self-defeatingly low UX and performance standard, and existing experiences are now pervasively re-developed on unspeakably slow, JS-taxed stacks. At a business level, this is a disaster, raising the question: why are new teams buying into stacks that have failed so often before?
Infrequently Noted (infrequently.org)
Platform Strategy and Its Discontents - Infrequently Noted
Alex Russell on browsers, standards, and the process of progress.
Infrequently Noted (infrequently.org)
-
Web technologies that should exist@Olliew Yes
-
Reactors debating performance have the energy of boomer "car guys" that want to tell a working mechanic, in 2024, about how much better carburetors were.Reactors debating performance have the energy of boomer "car guys" that want to tell a working mechanic, in 2024, about how much better carburetors were.
