Defaulting on Single Page Applications (SPA)—zachleat.com
This isn’t an opinion piece. This is documentation.
You can’t JavaScript your way out of an excess-JavaScript problem.
Link tags: ie
2330
The machines won’t save your design system — Hey Jovo Design
Every day, a new marketing email, Medium post, or VC who will leave Twitter when they’re cold in a body bag tells us that machine learning (ML, which they call AI because it sounds more expensive) is going to change the way we work. Doesn’t really matter what your job is. ML is going to read, write, code, and paint for us.
Naturally, the excitement around ML has found its way into the design systems community. There’s an apparent natural synergy between ML and design systems. Design systems practitioners are tantalized by the promise of even greater efficiency and scale. We wish a machine would write our docs for us.
We are all, every single one of us, huge fucking nerds.
Hello, internet | Sam O’Neill
I have been reminded time and time again of the utility of writing. How it is a way to turn messy thoughts into coherent ideas, and how – as we all know – practice makes perfect. So I’m going to give it a go.
Welcome to the indie web, Sam!
Learn Privacy
Stuart has written this fantastic concise practical guide to privacy for developers and designers. A must-read!
Smoke screen | A Working Library
The story that “artificial intelligence” tells is a smoke screen. But smoke offers only temporary cover. It fades if it isn’t replenished.
Pixel Pioneers Bristol 2023 Speaker Spotlight: Jeremy Keith
Oliver asked me some questions about my upcoming talk at Pixel Pioneers in Bristol in June. Here are my answers.
Craft vs Industry: Separating Concerns by Thomas Michael Semmler: CSS Developer, Designer & Developer from Vienna, Austria
Call me Cassandra:
The way that industry incorporates design systems is basically a misappropriation, or abuse at worst. It is not just me who is seeing the problem with ongoing industrialization in design. Even Brad Frost, the inventor of atomic design, is expressing similar concerns. In the words of Jeremy Keith:
[…] Design systems take their place in a long history of dehumanising approaches to manufacturing like Taylorism. The priorities of “scientific management” are the same as those of design systems—increasing efficiency and enforcing consistency.
So no. It is not just you. We all feel it. This quote is from 2020, by the way. What was then a prediction has since become a reality.
This grim assessment is well worth a read. It rings very true.
What could have become Design Systemics, in which we applied systems theory, cybernetics, and constructivism to the process and practice of design, is now instead being reduced to component libraries. As a designer, I find this utter nonsense. Everyone who has even just witnessed a design process in action knows that the deliverable is merely a documenting artifact of the process and does not constitute it at all. But for companies, the “output” is all that matters, because it can be measured; it appeals to the industrialized process because it scales. Once a component is designed, it can be reused, configured, and composed to produce “free” iterations without having to consult a designer. The cost was reduced while the output was maximized. Goal achieved!
Why aren’t logical properties taking over everything? - Chris Coyier
Good question.
I think it’s mostly inertia.
Tech-last
I’ve spent a lot of time thinking, talking and writing about evaluating technology and what Robin describes here is definitely a bad “code smell” that should ring alarm bells:
What’s really concerning is when everyone is consumed with the technology-first and the problem-last.
Unless you’re working in an R’n’D lab, start with user needs.
I’m certain now that if you want to build something great you have to see through the tech. And that’s really hard to do when this cool new thing is all that anyone is talking about. But that’s why this one specific thing is the hallmark of a great organization; they aren’t distracted by short-lived trends and instead focus on the problem-first. Relentlessly, through the noise.
When JavaScript Fails
So, if progressive enhancement is no more expensive to create, future-proof, provides us with technical credit, and ensures that our users always receive the best possible experience under any conditions, why has it fallen by the wayside?
Because before, when you clicked on a link, the browser would go white for a moment.
JavaScript frameworks broke the browser to avoid that momentary loss of control. They then had to recreate everything that the browser had provided for free: routing, history, the back button, accessibility features, the ability for search engines to read the page, et cetera iterum ad infinitum.
I doubled-down on RSS – Eric Bailey
In which Eric says:
Jeremy Keith, you magnificent son of a bitch.
I’ll take it.
Appropriately enough, I read this post in my feed reader.
Light Years Ahead | The 1969 Apollo Guidance Computer - YouTube
This video was in my “Watch Later” queue for ages but I finally got ‘round to watching it this weekend. It’s ace! Great content, great narrative, great delivery—would’ve made a good dConstruct talk.
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.
On Container Queries, Responsive Images, and JPEG-XL – Cloud Four
Container queries can’t be used in the sizes attribute for responsive images. Here, Jason breaks down why that is (spoiler: it’s the lookahead pre-parser) and segues into a truly long term solution: a “magical” image format.
If you’ve ever thought it felt weird to put media conditions inside the HTML for responsive images, this will resonate.
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.
Montaigne
This is an interesting little blogging tool: it turns a folder of notes on your Mac into a website.
- Create dedicated folder in the Apple Notes.
- Connect it to Montaigne.
- Add notes with your content.
- Everything will be published to the web automatically.
The (extremely) loud minority | Andy Bell
I’ll compare WordPress with React and Vue, because if you didn’t look at the data, you’d think everyone was building with them, right? Absolutely wrong.
Andy reminds of the skewed world of dev perception:
It’s understandable to think that JavaScript frameworks and their communities are eating the web because places like Twitter are awash with very loud voices from said communities.
Always remember that although a subset of the JavaScript community can be very loud, they represent a paltry portion of the web as a whole.