I feel like my problem with design in general today is that folks want to burn everything to the ground and start again all the time. Whether that’s with a website, or a new web standard, or a political policy. They don’t want to fix what’s wrong with things bit by bit, everyone wants Thing 2.0 whilst jumping over all the small improvements that are required to get there.
Most experienced designers want concision—clear, robust, consistent, elegant systems that avoid redundancy. Concise designs are smoother to implement, faster to render, quicker to understand, and easier to hand-off and maintain. Achieving a simplicity with clarity means that you’re engaging with the fundamentals of the problem (and of your craft) at the correct fidelity. You’ve cut through complexity with insight, understanding, and committed decision-making. That third one is critical. A lot of complexity comes from an unwillingness to commit to the things that insight and understanding surface.
Geocities, LiveJournal, what.cd, now Yahoo Groups. One day, Medium, Twitter, and even hosting services like GitHub Pages will be plundered then discarded when they can no longer grow or cannot find a working business model.
Considering the needs of someone who wants to make and maintain a website, without the ridiculous complexity of “modern” web tooling:
How do we make web content that can last and be maintained for at least 10 years? As someone studying human-computer interaction, I naturally think of the stakeholders we aren’t supporting. Right now putting up web content is optimized for either the professional web developer (who use the latest frameworks and workflows) or the non-tech savvy user (who use a platform).
The goal in putting these stories together has never been to create a warm glow, or lull anyone into a false sense of complacency. The challenges facing the human family right now are big and scary and there’s no guarantee we will overcome them.
As millions of people have demonstrated in the past 12 months though, action is possible, better solutions are available and a better future can be built.
I feel my trajectory as a musician maps to the trajectory of the web industry. The web is still young. We’re all still figuring stuff out and we’re all eager to get better. In our eagerness to get better, we’re reaching for more complexity. More complex abstractions, build processes, and tools. Because who wants to be bored playing in 4/4 when you can be playing in 7/16?
I hope we in the web field will arrive at the same realization that I did as a musician: complexity is not synonymous with quality.
Can I get an “Amen!”?
Worlds of scarcity are made out of things. Worlds of abundance are made out of dependencies. That’s the software playbook: find a system made of costly, redundant objects; and rearrange it into a fast, frictionless system made of logical dependencies. The delta in performance is irresistible, and dependencies are a compelling building block: they seem like just a piece of logic, with no cost and no friction. But they absolutely have a cost: the cost is complexity, outsourced agency, and brittleness. The cost of ownership is up front and visible; the cost of access is back-dated and hidden.
Facebook and even Instagram are at odds with the principles of the open web.
The transcript of Andy’s talk from this year’s State Of The Browser conference.
I don’t think using scale as an excuse for over-engineering stuff—especially CSS—is acceptable, even for huge teams that work on huge products.
When you ever had to fix just a few lines of CSS and it took two hours to get an ancient version of Gulp up and running, you know what I’m talking about.
I feel seen.
When everything works, it feels like magic. When something breaks, it’s hell.
I concur with Bastian’s advice:
I have a simple rule of thumb when it comes to programming:
less code === less potential issues
And this observation rings very true:
This dependency hell is also the reason why old projects are almost like sealed capsules. You can hardly let a project lie around for more than a year, because afterwards it’s probably broken.
It’s fantastic that our web plumbing has gotten more powerful—tooling today is capable of so much. But all too often, that power comes with increased complexity that negatively impacts developer efficiency. Sometimes that’s unavoidable. The simplest approach doesn’t always win. But that should be the goal—to make things as simple as possible while still accomplishing what needs to be done. Like excellent plumbing, these systems should be as mostly invisible—chugging along, doing what we need them to do without getting in our way.
Twenty hard-won lessons from Dan from ten years of Dribbble.
We sent 50 shirts along with a card to friends and colleagues announcing Dribbble’s beta back in 2008. This first batch of members played a pivotal role in the foundation of the community and how it would develop. The shirt helped guilt them into actually checking out the site.
I think I still have my T-shirt somewhere!
This is how it goes. We put a load of shit into a single web page. This makes the page slow. Slow to load, slow to render. Slow.
Instead of getting rid of the shit, we blame the page refresh.
This is very handy! Export your data from Ev’s blog and then import it into a static site generator of your choice.
You may have noticed the recent movement of people looking to get off Medium. Most of us are motivated by a desire to own our content, have data portability and get more control over how/where our content is displayed and monetized. Most importantly many of us consider our blog/site to be a core part of our online identity and while Medium offers a fantastic writing experience it sacrifices other important values. Luckily there’s a modern approach to running your blog which aligns with these ideals, its called the JAMstack and its all around us.
I missed this when it was first posted three years ago, but now I think I’ll be revisiting this 12 minute interview every few months.
Everything that Kyle says here is spot on, nuanced, and thoughtful. He talks about abstraction, maintainability, learning, and complexity.
I want a transcript of the whole thing.
I would urge front-end developers to take a step back, breathe, and reassess. Let’s stop over engineering for the sake of it. Let’s think what we can do with the basic tools, progressive enhancement and a simpler approach to building websites. There are absolutely valid usecases for SPAs, React, et al. and I’ll continue to use these tools reguarly and when it’s necessary, I’m just not sure that’s 100% of the time.
This is a bit ranty but it resonates with what I’ve been noticing lately:
I’ve discovered how many others have felt similarly, overwhelmed by the choices we have as modern developers, always feeling like there’s something we should be doing better.
I think we’re often guilty of assuming that because our tools are great solutions for some things, they’re automatically the solution for everything.
Let’s take a meandering waltz through what other people have to say about simplicity.