I’m 100% convinced that working demo-to-demo is the secret formula to making successful creative products.
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.
Design Thinking didn’t change business at all, rather it changed Design into business, adopting its language, priorities and techniques. It sold out Design in an attempt to impress those in power, and in so doing lost its heart.
I think, with the sheer volume of functionality available to us nowadays on the front-end, it can be easy to forget how powerful and strong the functionality is that we get right off shelf with HTML. Yes, you read that right, functionality.
We noticed a trend: students who pick a UI framework like Bootstrap or Material UI get off the ground quickly and make rapid progress in the first few days. But as time goes on, they get bogged down. The daylight grows between what they need, and what the component library provides. And they wind up spending so much time trying to bend the components into the right shape.
I remember one student spent a whole afternoon trying to modify the masthead from a CSS framework to support their navigation. In the end, they decided to scrap the third-party component, and they built an alternative themselves in 10 minutes.
This tracks with my experience. These kinds of frameworks don’t save time; they defer it.
The one situation where that works well, as Josh also points out, is prototyping.
If the goal is to quickly get something up and running, and you don’t need the UI to be 100% professional, I do think it can be a bit of a time-saver to quickly drop in a bunch of third-party components.
A cautionary tale on why you should keep your dependencies to a minimum and simplify your build process (if you even need one):
If it’s not link rot that gets you then it’s this heat death of the universe problem with entropy setting in slowly over time. And the only way to really defend against it is to build things progressively, to make sure that you’re not tied to one dependency or another. That complex build process? That’s a dependency. Your third party link to some third party font service that depends on their servers running forever? Another dependency.
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.
There’s a difference between creativity and production. I knit things but it’s not a creative process for me, it’s a physical one. I’m not interested in doing ‘something new’ with knitting (I don’t even call myself a ‘knitter’ to be honest. I don’t really think I’ve earned it). I haven’t learned the methods of construction. I’ve never tried to make something new out of the stitches I’ve learned. It’s not why I knit. I knit to relax. There’s joy in following a pattern and knowing that a more accomplished, knowledgeable person has done the hard creative work for me, and if I just do what they say, thing’s will probably work out fine. And I love the things I make. I put care into the production process - I take care to get the stitches neat, if I can. But when people look at the things I make and say “you’re so creative” - it’s just not true. In that context I can only ever say “no, I followed a pattern - it’s a good pattern. Do you want the link?”
I remember Lara telling me a great quote from the Clarity conference a few years back: “A design system needs to be correct before it’s complete.” In other words, it’s better to have one realistic component that’s actually in production than to have a pattern library full of beautiful but unimplemented components. I feel like Robin is getting at much the same point here, but he frames it in terms of correctness and usefulness:
If we want to be correct, okay, let’s have components of everything and an enormous Figma library of stuff we need to maintain. But if we want to be useful to designers who want to get an understanding of the system, let’s be brief.
Unless we know why someone made a decision, we can’t safely change it or conclude that they were wrong.
I like this high-level view of the state of CSS today. There are two main takeaways:
- Custom properties, flexbox, and grid are game-changers.
- Pre- and post-processers are becoming less and less necessary.
This is exactly the direction we should be going in! More and more power from the native web technologies (while still remaining learnable), with less and less reliance on tooling. For CSS, the tools have been like polyfills that we can now start to remove.
They could learn a thing or two from the trajectory of CSS: treat your frameworks as cattle, not pets.
Speed for the sake of speed means nothing. If our design systems don’t ultimately lead to better quality experiences, we’re doing it wrong.
When we rush to release one-size-fits-all components, without doing the work to understand different contexts before curating and consolidating solutions, we sacrifice quality at the hands of speed.
The irony? In the long run, this will slow us down. We end up having to undo the work we’ve done to fix the problems we’ve created.
Ultimately, when we prioritise speed over quality, we end up with neither.
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.
Get out of my head, Robin!
I wish the structure of my days could be more like this though; more haphazard, more jumping from thing to thing with reckless abandon. There’s a punch-in-the-gut feeling I get when my days have too much structure to them. I require that feeling of jumping around whenever I want to, and I think it’s what gives me the energy to be a functional person.
I keep seeing Single-Page-Apps with huge JS files that only, in terms of concrete User Experience (UX) benefits, deliver client-side validation of forms plus analytics. Apps rarely leverage the potential of a Single-Page-App. It’s still just the same ‘click, wait for load’ navigation cycle. Same as the one you get with Multi-Page-Apps. Except buggier and with a much slower initial loading time.
When you look at performance, cross-platform and mobile support, reliability, and accessibility, nearly every Single-Page-App you can find in the wild is a failure on multiple fronts.
Replacing those with even a mediocre Multi-Page-App is generally going to be a substantial win. You usually see improvements on all of the issues mentioned above. You get the same general UX except with more reliable loading, history management, and loading features—provided by the browser.
Before you dismiss Baldur as a hater based on what I’ve just quoted, you should really read the whole article. The issue he points to is not with the technical architecture of single page apps, but with management.
Single-Page-Apps can be fantastic. Most teams will mess them up because most teams operate in dysfunctional organisations.
Baldur’s conclusion chimes a lot with what I’ve been saying in conference talks this year: the biggest challenges facing the web are not technical in nature.
The biggest hindrance to the web’s progress isn’t non-expert developers, tooling, libraries, Single-Page-Apps, or Multi-Page-Apps.
It’s always humans.
Elise Hein documents what it was like to build a website (or web app, if you prefer) the stackless way:
- use custom elements (for modular HTML without frameworks)
- match pages with files (to avoid routing and simplify architecture)
- stick to standards (to avoid obsolescence and framework fatigue)
Her conclusions are similar to my own: ES6 modules mean you can kiss your bundler goodbye; web components are a mixed bag—it’s frustrating that Apple are refusing to allow native elements to be extended. Interestingly, Elise feels that a CSS preprocessor is still needed for her because she wants to be able to nest selectors …but even that’s on its way now!
Perhaps we might get to the stage where it isn’t an automatic default to assume you’ll need bundling, concatenation, transpiling, preprocessing, and all those other tasks that we’ve become dependent on build tools for.
create-react-appas the first step, and this exercise has only strengthened my conviction that every beginner programmer should get to grips with HTML, CSS and vanilla JS before delving into frameworks. Features native to the web are what all frameworks share, and knowing the platform makes for a stronger foundation in the face of change.
Simon describes the pattern he uses for content sites to get all of the resilience of static site generators while keeping dynamic functionality.
Most work is pretty mundane. Even work on meaningful things. The most profound stuff is built one mostly boring brick at a time. Even the most creative ideas, the best art, the breakthroughs have to be assembled, and assembly isn’t typically what fires people up.
You don’t get to the exhilarating end without going through the mundane middle. And the beginning and end are the shortest parts — the middle is most of it.