“We’ve stripped React out of our highest-traffic user flows and replaced it with vanilla JavaScript using small, focused libraries for specific needs,” said the CTO of a streaming service. “Our page load times dropped by 60% and our conversion rates improved by 14%.”
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.
How the spirit of Brexit scuppered the dream of a Victorian chunnel.
In 1851, a telegraph wire linked London and Paris directly. Might it be possible for a railway to follow? Many engineers believed it was: they proposed a tunnel, joining the roads and railways of Britain to those of mainland Europe.
I’d like to suggest that everybody in web dev point their dysfunctional novelty seeking (of which I suffer as well) in the direction of HTML and CSS. See how much can be done without JavaScript. It’s a lot! Then look at writing more lightweight JavaScript that’s layered on top of the HTML as enhancements. Because it’s an enhancement and not required for functionality, you can cut the line higher and use newer tech without worry.
See how refreshing that feels.
A terrific interview with Deb Chachra. Her new book, How Infrastructure Works sounds excellent!
A plea to let users do web things on websites. In other words, stop over-complicating everything with buckets of JavaScript.
Honestly, this isn’t wishlist isn’t asking for much, and it’s a damning indictment of “modern” frontend development that we’ve come to this:
- Let me copy text so I can paste it.
- If something navigates like a link, let me do link things.
- …
I’ve come to believe the best way to look at our Mars program is as a faith-based initiative. There is a small cohort of people who really believe in going to Mars, the way some people believe in ghosts or cryptocurrency, and this group has an outsize effect on our space program.
Maciej lays out the case against a crewed mission to Mars.
Like George Lucas preparing to release another awful prequel, NASA is hoping that cool spaceships and nostalgia will be enough to keep everyone from noticing that their story makes no sense. But you can’t lie your way to Mars, no matter how sincerely you believe in what you’re doing.
And don’t skip the footnotes:
Fourth graders writing to Santa make a stronger case for an X-Box than NASA has been able to put together for a Mars landing.
This extract from Baldur’s new book is particularly timely in light of the twipocalypse.
I wrote a while back about descriptive and prescriptive design systems—and a follow-up post—but I didn’t realise there was such a thing as descriptive and prescriptive engineering.
I like the way this work-in-progress is organised—it’s both a book and a personal website that’ll grow over time.
Dave laments the increasing number of complex jobs involved in front-end (or “full-stack”) development.
But whereas I would just leave at that, Dave does something constructive and points to a potential solution—a corresponding increase of more thinsliced full-time roles like design engineering, front-end ops, and CSS engineering.
Write about what you learn. It pushes you to understand topics better. Sometimes the gaps in your knowledge only become clear when you try explaining things to others. It’s OK if no one reads what you write. You get a lot out of just doing it for you.
Lots of good advice from Addy:
Saying no is better than overcommitting.
Even when each new layer of complexity starts to bring zero or even negative returns on investment, people continue trying to do what worked in the past. At some point, the morass they’ve built becomes so dysfunctional and unwieldy that the only solution is collapse: i.e., a rapid decrease in complexity, usually by abolishing the old system and starting from scratch.
Jim shares his thoughts on my recent post about declarative design systems. He picks up on the way I described a declarative design systems as “a predefined set of boundary conditions that can be used to generate components”:
I like this definition of a design system: a set of boundaries. It’s about saying “don’t go there” rather than “you can only go here”. This embraces the idea of constraints as the mother of invention: it opens the door to creativity while keeping things bounded.
This is really interesting. I hadn’t thought too much about the connection between design engineering and declarative design before now, but Jim’s post makes the overlap very clear indeed.
Time and again, organizations have sought to contain software’s most troublesome tendencies—its habit of sprawling beyond timelines and measurable goals—by introducing new management styles. And for a time, it looked as though companies had found in Agile the solution to keeping developers happily on task while also working at a feverish pace. Recently, though, some signs are emerging that Agile’s power may be fading. A new moment of reckoning is in the making, one that may end up knocking Agile off its perch.
Browsers give you a ton of stuff for free, built right in, out-of-the-box. SPAs break all that, and force you to recreate it yourself with JavaScript. Most developers do it wrong, and for the ones who do it right, it results in a ton of extra code to recreate features the browser already gave you for free.
This forthcoming podcast about design engineering sounds like my cup of tea!
Design engineering explained, with diagrams.
I have never worked anywhere where there wasn’t someone trying to close the gap. This role is often filled in accidentally, and companies are totally unaware of the need. Recruiters have never heard of it, and IT consultancies don’t have the capability in their roster. We now name the role “Design Engineer” because the gap is widening, and the role has become too complex to not exist.
Sneaky social engineering in Slack.