The Last Quiet Thing | Terry Godier
Most of your screen time isn’t leisure. It isn’t addiction. It isn’t even a choice.
It’s maintenance.
Link tags: main
108
Smaller and dumber - daverupert.com
The principle of least power expressed nicely:
Smaller, dumber things have more applications, go more places, and require less maintenance.
JS-heavy approaches are not compatible with long-term performance goals
Frameworks like React are often perceived as accelerators, or even as the only sensible way to do web development. There’s this notion that a more “modern” stack (read: JS-heavy, where the JS ends up running on the user’s browser) allows you to be more agile, release more often with fewer bugs, make code more maintainable, and ultimately launch better sites. In short, the claim is that this approach will offer huge improvements to developer experience, and that these DevEx benefits will trickle down to the user.
But over the years, this narrative has proven to be unrealistic, at best. In reality, for any decently sized JS-heavy project, you should expect that what you build will be slower than advertised, it will keep getting slower over time while it sees ongoing work, and it will take more effort to develop and especially to maintain than what you were led to believe, with as many bugs as any other approach.
Where it comes to performance, the important thing to note is that a JS-heavy approach (and particularly one based on React & friends) will most likely not be a good starting point; in fact, it will probably prove to be a performance minefield that you will need to keep revisiting, risking a detonation with every new commit.
The Main Thread Is Not Yours — Den Odell
Every millisecond you spend executing JavaScript is a millisecond the browser can’t spend responding to a click, updating a scroll position, or acknowledging that the user did just try to type something. When your code runs long, you’re not causing “jank” in some abstract technical sense; you’re ignoring someone who’s trying to talk to you.
This is a great way to think about client-side JavaScript!
Also:
Before your application code runs a single line, your framework has already spent some of the user’s main thread budget on initialization, hydration, and virtual DOM reconciliation.
How to Make Websites That Will Require Lots of Your Time and Energy - Jim Nielsen’s Blog
- Install Stuff Indiscriminately From npm
- Pick a Framework Before You Know You Need One
- Always, Always Require a Compilation Step
The Recurring Cycle of ‘Developer Replacement’ Hype
Here’s what the “AI will replace developers” crowd fundamentally misunderstands: code is not an asset—it’s a liability. Every line must be maintained, debugged, secured, and eventually replaced. The real asset is the business capability that code enables.
If AI makes writing code faster and cheaper, it’s really making it easier to create liability. When you can generate liability at unprecedented speed, the ability to manage and minimize that liability strategically becomes exponentially more valuable.
This is particularly true because AI excels at local optimization but fails at global design. It can optimize individual functions but can’t determine whether a service should exist in the first place, or how it should interact with the broader system. When implementation speed increases dramatically, architectural mistakes get baked in before you realize they’re mistakes.
Build It Yourself | Armin Ronacher’s Thoughts and Writings
We’re at a point in the most ecosystems where pulling in libraries is not just the default action, it’s seen positively: “Look how modular and composable my code is!” Actually, it might just be a symptom of never wanting to type out more than a few lines.
It always amazes me when people don’t view dependencies as liabilities. To me it feels like the coding equivalent of going to a loan shark. You are asking for technical debt.
There are entire companies who are making a living of supplying you with the tools needed to deal with your dependency mess. In the name of security, we’re pushed to having dependencies and keeping them up to date, despite most of those dependencies being the primary source of security problems.
But there is a simpler path. You write code yourself. Sure, it’s more work up front, but once it’s written, it’s done.
Public Domain Image Archive
Explore our hand-picked collection of 10,046 out-of-copyright works, free for all to browse, download, and reuse. This is a living database with new images added every week.
Openly Licensed Images, Audio and More | Openverse
A library of CC-licensed photos.
Next time you’re tempted to use a generative “AI” tool to make an image for a slide deck, use this instead.
Lessons learned in 35 years of making software – Jim Grey
Number one:
Do things in the most straightforward way possible. It’s easy to fall into the trap of clever solutions, or clever applications of technology, or overbuilding something because you’re anticipating the future. Don’t do it. You will hate yourself for it later when you have to maintain it.
The invisible seafaring industry that keeps the internet afloat
A fascinating in-depth look at the maintenance of undersea cables:
The industry responsible for this crucial work traces its origins back far beyond the internet, past even the telephone, to the early days of telegraphy. It’s invisible, underappreciated, analog.
It’s a truism that people don’t think about infrastructure until it breaks, but they tend not to think about the fixing of it, either.
A Global Documentation Platform - Piccalilli
I was chatting to Andy last week and he started ranting about the future of online documentation for web developers. “Write a blog post!” I said. So he did.
I think he’s right. We need a Wikimedia model for web docs. I’m not sure if MDN fits the bill anymore now that they’re deliberately spewing hallucinations back at web developers.
The Origin of Online Handles - Jim Nielsen’s Blog
My secret is safe.
w/e 2023-11-05 (Phil Gyford’s website)
On the one hand I still really enjoy writing code and making something work and look good (ish) and put it online where anyone in the world can see it. It’s still like magic. And is still some kind of personal affirmation, a way of saying “here I am!”, of enjoying that it’s noticed by someone, somewhere.
True.
On the other hand, the maintenance. It’s not like this is new to me, keeping things going for years, decades. And I try to make things as easy as possible – keep things up to date, make things in similar ways, stick to reliable and boring technologies, don’t start too many things, etc. But, especially when several things aren’t quite working right, it’s such a weight.
Also true.
The Cost of Convenience - DEV Community
The pros and cons of dependencies in your toolchain.
Remote Synthesis | The Price Developers Pay for Loving Their Tools Too Much
- Don’t wrap too much of your identity in a tool.
- Every tool will eventually fade.
- Flexibility is a valuable skill
- Changing tools does not mean starting over.
I agree with pretty much every word of this article.
Redefining Developer Experience — Begin Blog
Perhaps most problematic of all is the effect that contemporary developer experience has on educational programs (be they traditional classes, bootcamps, workshops, or anything in between). Such a rapidly expanding and ever changing technological ecosystem necessarily means that curricula struggle to keep up, and that the fundamentals of web development (e.g. HTML, CSS, HTTP, browser APIs…) are often glossed over in favor of getting students into the technologies more likely to land them jobs (like React and its many pals). This leads to an outpouring of early career developers who may speak confidently about things like React hooks or Redux state reducers, but who also lack any concept about the nature of HTML semantics or the most basic accessibility considerations. To be clear, I’m not throwing shade at those developers — they have been failed by an industry obsessed with the new and shiny at the expense of foundational practices and end user experiences.
And so, I ask: what exactly are we buying when we are sold ‘developer experience’ today? Who is benefiting from it? And if it is indeed something many of us aren’t too excited about (to put it kindly), how can we change it for the better?
I agree with pretty much every word of this article.
The Great Gaslighting of the JavaScript Era | The Spicy Web
We were told writing apps with an HTML-first, SSR-first, progressively enhanced mindset, using our preferred language/tech stack of choice, was outdated and bad for users.
That was a lie.
We were told writing apps completely using frontend-y JavaScript would make our lives easier.
That also was a lie.
I agree with pretty much every word of this article.
What framework should I use? | Go Make Things
If you’re top priority is paid employment, right now, React is a great choice for that.
True. But…
If your priority is long-term resilience and maintainability, vanilla JS (probably with a light build process on top of it) is the ideal choice.
It will never become obsolete, or suffer from a breaking version change. It’s fast and performant, results in less code sent over the wire, and generally has a smaller footprint of things to break.