Link tags: libraries

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!

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.

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.

The case for frameworks | Seldo.com

Laurie reiterates the fact that:

React isn’t great at anything except being popular.

And Laurie thinks that’s okay.

I don’t.

Why I’m not the biggest fan of Single Page Applications - Manuel Matuzović

I guess the biggest criticism here is that it feels like people who believe in the superiority of single page applications and the entire ecosystem focus more on developer experience (DX) than user experience. That sounds like a dangerous blanket statement, but after all these years, I never had the feeling that the argument “better DX leads to better UX” was ever true. It’s nothing more than a justification for the immense complexity and potentially significantly worse UX. And even if the core argument isn’t DX, other arguments like scalability, maintainability, competitive ability, easier recruiting (“everyone uses React”), and cost effectiveness, in my experience, only sound good, but rarely hold up to their promises.

Modern Health, frameworks, performance, and harm – Eric Bailey

A person seeking help in a time of crisis does not care about TypeScript, tree shaking, hot module replacement, A/B tests, burndown charts, NPS, OKRs, KPIs, or other startup jargon. Developer experience does not count for shit if the person using the thing they built can’t actually get what they need.

We’re all trying to find the guy who did this

Imagine the web is a storefront, React is a hot dog car, and here’s Create React App dressed as a hot dog:

HTML is the cornerstone of the web — so why does creating a “React app” produce an empty HTML file? Why are we not taking advantage of the most basic feature of the web—the ability to see content quickly before all the interactive code loads? Why do we wait to start loading the data until after all the client-side code has finished loading?

Patrick / articles / Is the developer experience on the Web so terrible?

Over the past 10 years or so, we’ve slowly but very surely transitioned to a state where frameworks are the norm, and I think it’s a problem.

I concur.

Use the frameworks and libraries that make sense for you to deliver the best UX possible. But also learn the web platform from the ground up. Take time to understand how web browsers work and render webpages. Learn HTML, CSS, JavaScript. And keep an eye, if you can, on the new things.

CSS { In Real Life } | Disentangling Frameworks

I just quoted Chris saying:

I think some tools are a good idea. But as few as possible, and the easier they are to stop using, the better.

Now Michelle asks:

Suppose we want to stop using Tailwind one day?

Turns out it’s a bit of a roach motel, much like most JavaScript frameworks: you can get in but you can’t easily get out.

So whenever possible, the safest, and most future-proof bet is to use the native features of the web platform.

The Performance Inequality Gap, 2023 - Infrequently Noted

It is not an exaggeration to say that modern frontend is so enamoured by post-scarcity fairy tales that it is mortgaging the web’s future for another round of night drinking at the JavaScript party.

Strong—and true—words from Alex.

This isn’t working for users or for businesses that hire developers hopped up Facebook’s latest JavaScript hopium. A correction is due.

I concur.

Frontend’s failure to deliver in today’s mostly-mobile, mostly-Android world is shocking, if only for the durability of the myths that sustain the indefensible. We can’t keep doing this.

If you disagree, I encourage you to dive into the data that Alex shares.

Transient Frameworks · Matthias Ott – User Experience Designer

Frameworks come and go. They are transient. Web standards, on the other hand, are the reason the Web is good now and it will become even better in the future.

Remix and the Alternate Timeline of Web Development - Jim Nielsen’s Blog

It sounds like Remix takes a sensible approach to progressive enhancement.

The transitional web | Go Make Things

I’ve smelt the same change in the wind that Chris describes here—there’s finally a reckoning happening in the world of JavaScript frameworks and single page apps.

Why We’re Breaking Up with CSS-in-JS | Brad Frost

I’ve seen the pendulum swing back and forth many times over my years building on the web. I too feel like there’s something in the air right now, and people are finally acknowledging that most single page apps are crap.

But Brad makes the interesting point that, because they were incubated when profligate client-side JavaScript was all the rage, web components may have ended up inheriting the wrong mindset:

So now the world of web components has egg on its face because the zeitgeist at the time of its design didn’t have such a strong focus on SSR/HTML-first/ progressive enhancement. Had web components been designed in the current zeitgeist, things would almost certainly be different.

Two JavaScripts

There are two JavaScripts.

One for the server - where you can go wild.

One for the client - that should be thoughtful and careful.

Yes! This! I’m always astounded to see devs apply the same mindset to backend and frontend development, just because it happens to be in the same language. I don’t care what you use on your own machine or your own web server, but once you’re sending something down the wire to end users, you need to prioritise their needs over your own.

It’s the JavaScript on the client side that’s the problem. What’s given to the visitor.

I’d ask you, if you’re still reading, that you consider a separation of JavaScript between client and server. If you’re a dev, consider the payload, your bundle and work to reduce the cost to your visitor. Heck, think progressive enhancement.

A Web Component Story

I get it. React feels good and it’s sticky. But all frameworks eventually fizzle out.

Thanks to Web Components, large companies are realizing you don’t need to rebuild buttons and other UI primitives every few years. Teams don’t need to argue about frameworks anymore. You can have your cake and eat it too!

I think this may be the best long-term argument for web components:

Any org that goes all in on a single framework will eventually find themselves swimming upstream to hire talent to maintain legacy code and avoid framework rot. But you can reduce this burden (and the associated costs) by using Web Components in your design system.

The self-fulfilling prophecy of React - Josh Collinsworth blog

Matcalfe’s Law in action:

Companies keep choosing React because they know there’s a massive pool of candidates who know it; candidates keep learning React because they know companies are hiring for it. It’s a self-sustaining cycle.

But the problem is:

React isn’t great at anything except being popular.