Tags: libraries

81

sparkline

The React is “just” JavaScript Myth - daverupert.com

In my experience, there’s no casual mode within React. You need to be all-in, keeping up with the ecosystem, or else your knowledge evaporates.

I think Dave is right. At this point, it’s possible to be a React developer exclusively.

React is an ecosystem. I feel like it’s a disservice to anyone trying to learn to diminish all that React entails. React shows up on the scene with Babel, Webpack, and JSX (which each have their own learning curve) then quickly branches out into technologies like Redux, React-Router, Immutable.js, Axios, Jest, Next.js, Create-React-App, GraphQL, and whatever weird plugin you need for your app.

And, as Jake points out, you either need to go all in or not at all—you can’t really incrementally add Reactness to an existing project.

What’s in a pattern name? — Ethan Marcotte

Ethan emphasises the importance of making a shared language the heart of any design system. I heartily agree!

This isn’t new thinking, mind: folks like Alla Kholmatova and Charlotte Jackson have been talking about this for ages. (And in doing so, they’ve massively influenced how I think about modular, pattern-driven design.)

A Framework Author’s Case Against Frameworks - YouTube

A terrific talk by Adrian Holovaty. I really hope front-end developers talk its message to heart.

A Framework Author's Case Against Frameworks

Designing Button States - Cloud Four

The canonical example in just about every pattern library is documenting button variations. Here, Tyler shows how even this seemingly simple pattern takes a lot of thought.

Design, system. — Ethan Marcotte

Wise words from Ethan on how to react when people create bespoke patterns instead of using something in an existing pattern library.

It’s easy for an organization to look at that one-off pattern as a problem of compliance, of not following the established rules. And in many cases, that might be true! But it’s also worth recognizing when a variation’s teaching you a lesson: namely, that your design system isn’t meeting the needs of the people who’re using it.

The Good Room – Frank Chimero

Another brilliant talk from Frank, this time on the (im)balance between the commercial and the cultural web.

Remember: the web is a marketplace and a commonwealth, so we have both commerce and culture; it’s just that the non-commercial bits of the web get more difficult to see in comparison to the outsized presence of the commercial web and all that caters to it.

This really resonates with me:

If commercial networks on the web measure success by reach and profit, cultural endeavors need to see their successes in terms of resonance and significance.

Seva Zaikov - Single Page Application Is Not a Silver Bullet

Harsh (but fair) assessment of the performance costs of doing everything on the client side.

HTML templating with vanilla JavaScript ES2015 Template Literals – Ben Frain

Ben makes the very good point that template literals allow you to do a lot of useful stuff that previously would’ve required a library:

Template Literals afford a lot of power with no library overhead. I will definitely continue to use them when complexity of handlebars or similar is overkill.

Chris made a similar observation a little while back. Throw in a little script like lit-html and now you’ve got DOM-diffing too. You might not need insert-current-framework-name after all.

Kinda cool that these mini-libraries exist that do useful things for us, so when situations arise that we want a feature that a big library has, but don’t want to use the whole big library, we got smaller options.

All That Glisters ◆ 24 ways

I thought this post from Drew was a great way to wrap up another excellent crop from 24 Ways.

There are so many new tools, frameworks, techniques, styles and libraries to learn. You know what? You don’t have to use them.

Chris likes it too.

Why Design Systems Fail ◆ 24 ways

Great advice from Una on getting buy-in and ensuring the long-term success of a design system.

The User Experience of Design Systems

When you start a redesign process for a company, it’s very easy to briefly look at all their products (apps, websites, newsletters, etc) and first of all make fun of how bad it all looks, and then design this one single design system for everything. However, once you start diving into why those decisions were made, they often reveal local knowledge that your design system doesn’t solve.

In this talk transcript, Rune Madsen enumerates the reasons for his informed scepticism towards design systems:

  1. The first concern, which is also the main argument of this talk, is that humans – especially designers and engineers – are obsessed with creating systems of order. This is not really driven by a demand from users, so they often tend to benefit the designer, not the user.
  2. My second concern relates to what I believe design systems is doing to our digital experience. We’ve always had trends in graphic design (Swiss design, Flat UI, etc), but I’m getting increasingly concerned that this broad adoption of design systems is creating a design monoculture that really narrows the idea of what digital products can be.
  3. My third concern is that with all this talk about design systems, there’s very little talk about the real problem in digital design, which is processes and tools. Designers love making design manuals, but any design system will completely and utterly fail if it doesn’t help people in the organization produce faster and better products.

Design Systems Handbook - DesignBetter.Co

A weirdly over-engineered online book with bizarre scrolljacking (I would advise disabling JavaScript but then all the links stop working so you won’t be able to go past the table of contents) but it’s free and the content—by Marco Suarez, Jina Anne, Katie Sylor-Miller, Diana Mounter, and Roy Stanfield— looks good:

A design system unites product teams around a common visual language. It reduces design debt, accelerates the design process, and builds bridges between teams working in concert to bring products to life. Learn how you can create your design system and help your team improve product quality while reducing design debt.

A collection of awesome design systems

A table of design systems, pattern libraries, style guides, or whatever we’re calling them.

The Burden of Precision | Daniel T. Eden, Designer

I think Dan is on to something here—design tools that offer pixel perfection at an early stage are setting us up for disappointment and frustration. Broad brushstrokes early on, followed by more precise tinkering later, feels like a more sensible approach.

With the help of a robust and comprehensive design system, I am certain that we could design in much broader strokes, and concentrate on making the finished product, rather than our design outputs, highly precise and reflective of our ideal.

Design Guidelines — The way products are built.

A collection of publicly available design systems, pattern libraries, and interface guidelines.

Building Flexible Design Systems // Speaker Deck

The slides from Yesenia’s talk on scenario-driven design.

Distilling How We Think About Design Systems

Advice on building design systems:

  • If you can avoid being ambiguous, please do.
  • Favor common understanding over dictionary correctness.
  • Make great operations a priority.
  • Don’t get trapped in defining things instead of explaining things.

Netflix functions without client-side React, and it’s a good thing - JakeArchibald.com

A great bucketload of common sense from Jake:

Rather than copying bad examples from the history of native apps, where everything is delivered in one big lump, we should be doing a little with a little, then getting a little more and doing a little more, repeating until complete. Think about the things users are going to do when they first arrive, and deliver that. Especially consider those most-likely to arrive with empty caches.

And here’s a good way of thinking about that:

I’m a fan of progressive enhancement as it puts you in this mindset. Continually do as much as you can with what you’ve got.

All too often, saying “use the right tool for the job” is interpreted as “don’t use that tool!” but as Jake reminds us, the sign of a really good tool is its ability to adapt instead of demanding rigid usage:

Netflix uses React on the client and server, but they identified that the client-side portion wasn’t needed for the first interaction, so they leaned on what the browser can already do, and deferred client-side React. The story isn’t that they’re abandoning React, it’s that they’re able to defer it on the client until it’s was needed. React folks should be championing this as a feature.

Can You Afford It?: Real-world Web Performance Budgets – Infrequently Noted

Alex looks at the mindset and approaches you need to adopt to make a performant site. There’s some great advice in here for setting performance budgets for JavaScript.

JavaScript is the single most expensive part of any page in ways that are a function of both network capacity and device speed. For developers and decision makers with fast phones on fast networks this is a double-whammy of hidden costs.

Design Systems | susan jean robertson

Susan reviews Alla’s superb book on design systems:

If you’re interested in or wanting to create a design system or improve the one you have or get buy in to take your side project at work and make it part of the normal work flow, read this book. And even better, get your colleagues to do the same, so you’ll have a shared understanding before you begin the hard work to build your own system.

Susan also published her highlights from the book. I really like that!