Tags: frame

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!

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.

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.

Henry From Online | How To Make a Website

Write meaningful HTML that communicates the structure of your document before any style or additional interactivity has loaded. Write CSS carefully, reason your methodology and stick to it, and feel empowered to skip frameworks. When it comes time to write JavaScript, write not too much, make sure you know what it all does, and above all, make sure the website works without it.

The whole article is great, and really charmingly written, with some golden nuggets embedded within, like:

• You’ll find that spending more time getting HTML right reveals or even anticipates and evades accessibility issues. It’s just easier to write accessible code if it’s got semantic foundations.
• In my experience, you will almost always spend more time overriding frameworks or compromising your design to fit the opinions of a framework.
• Always style from the absolute smallest screen your content will be rendered on first, and use @media (min-width) queries to break to layouts that allow for more real estate as it becomes available.
• If your site doesn’t work without JavaScript, your site doesn’t work.
• Always progressively enhance your apps, especially when you’re fucking with something as browser-critical as page routing.

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.