• Skip to primary navigation
  • Skip to main content
  • Skip to primary sidebar

Dion Almaer

Software, Development, Products

  • @dalmaer
  • LinkedIn
  • Medium
  • RSS
  • Show Search
Hide Search

Web Platform

Building a modern design system in layers

May 15, 2023

So often, when building a design system, we end up building something rigid that we will struggle with as time goes by. When this is done, we can try to evolve it well, and to make it so good that developers are somewhat happy with it even if they don’t like the rigid choices that were made.

This happens in all eras. Most recently, you will find many design systems that are React design systems vs. Web design systems that offer idiomatic React as an awesome option. As soon as you have made that choice you have locked in an audience and a lot of option value is taken off of the table.

Let’s consider that you are building a design system at a company that is on the path to becoming a 100 year company where you aspire to think long term. I contend that it makes sense to build your design system in layers that:

  • Have the wiggle room to move independently
  • A layer can even be replaced
  • Developers can swap out layers, especially those higher up in the stack

If I were holding a React design system today, and I was offered the opportunity to go back in time, I would swap it out for a layered Web design system.

What would this look like?

Let’s quickly talk about these layers.

Design foundational layer

Modern CSS can do so much these days. Start building out as much of the design system as possible with HTML and CSS. Components that used to be complex nested can not be a with some sprinkles. If you want some inspiration, check out the fine work of folks such as: Adam Argyle, Una, Jhey, and Josh W. Comeau.

Here you create your helpful guardrails via design tokens, your low level primitives, and your higher level components. I would consider using something like Adam’s Open Props as a strong foundation.

With some exploration, you will probably find that this layer gets you quite far these days, and with a nice story book playground developers will love to tinker as they learn it.

Interactivity layer

Next up you can loosely wire up the pieces via custom elements. This should be a relatively thin layer that brings to full life. You can choose a helpful tool such as Lit or Stencil to make it even easier.

These components run on top of the Web Platform, and are thus incredibly future proof.

Framework layer

Some developers will happily take the custom elements and use them directly, but most will probably want to use some bindings that feel idiomatic in the framework of their choice. There is no need for a holy war of “Framework vs Web Components!” They can happily work together these days. In fact, tools such as Lit have wrapper tools to make it easier to take your components and vend them as idiomatic framework components such as React.

Reach, Value and Future Proofing

With this approach you have set yourself on a solid long term path. Your work can now reach web developers that are choosing a variety of frameworks. If there is one thing we know about the web, it’s that there is healthy innovation and evolution on this layer. We can’t predict the future, but we both know that there will be new frameworks with significant developer share AND there will be a ton of apps running React and jQuery and … for some time. Both are true, so why not support both?

Now, you may be thinking: “We aren’t resourced to support all of the items in the framework later!” This is often true, however you don’t have to support them all, you can choose levels of support, such as:

  • First class / Well lit path: you make sure yourself that everything fully works end to end using code that you write and maintain.
  • Community support: with a well lit path or two out there, the community can take a look at the end to end solution, along with the layer below that it relies on, and create their own idiomatic bindings. The more you document the first class stack, the easier it will be for the community to take high quality code, with tests, and a spec of sorts and build something of high quality themselves. Make sure to elevate the work and effort that they put into it!
  • Individual usage: if there isn’t a library itself, a developer using their framework of choice can just use the custom elements to build on. Chances are one of these will jump up to the level of community support… especially if you incentivize and foster this.

I don’t know about you, but it feels like we are in a frothy time for the Web framework space. React has an army of developers, but there is some confusion on which direction to go. Will RSC fully pan out? When should you use Next.js or Remix?

This shines through when you see videos showing up putting forth points of view such as always bet on react! and I don’t hate react, i’m just moving on. It’s a time of change, right when there are amazing non-React options such as Solid, Svelte, Vue, Preact, and more. This is healthy, and having written web applications with more different frameworks than hot dinners that I have consumed, they can all help you deliver something great for users. So, it’s kinda win win.

It does make you think about…

Learn in Layers

Some wanna-be-gatekeepers have poo poo’d developers who come in and learn React first, and often skim some of the knowledge of the Web platform. There’s no need for the gate keeping, and this can be a great starting point.

That being said, I have always been a believer in Glen Vanderburg’s philosophy that it’s very much worth your time to understand one layer of abstraction below and potentially above you.

This means that you should have a solid understanding of the Web Platform APIs, as well as the core technology of JavaScript, CSS, and HTML. Often this naturally bleeds through, and although we are sometimes taught that a good abstraction doesn’t leak, some of the best abstractions are known as onion skin APIs when ”leaking” becomes a feature, an escape hatch.

ActiveRecord is a great example, where SQL isn’t hidden from you. Git has long built layers where you have porcelain and plumbing.

My good friend Dimitri has recently written about porcelains in the context of how we changed the API of Polymath with respect to talking to OpenAI. Instead of abstracting all of the fetch calls, we embrace the fact that developers probably know fetch well, and may want to use advanced features. We instead vend an API that understands the service via a request and response, so you end up with something such as:

While there has been a lot written in the form of “Web Components vs. $FRAMEWORK”, you find that this is totally the wrong frame. There are a variety of Web Platform APIs in the umbrella of Web Components, such as Custom Elements and Shadow DOM. If you take the time to learn this layer, you may find reason to use it with your web framework of choice. And if you do so, this knowledge will be durable no matter what other frameworks you use now and in the future. The browser moves slowly, and these APIs are here ~forever.

I recently worked with a team that deliver a high quality design system that is tied to React. If I could go back in time I would switch to this layered system in a second. It pained me to talk to developers that used the platform that the design system was used for but hadn’t chosen React. They want to deliver the same look and feel for users, so what do they end up doing? Many would view source and copy HTML and CSS and add interactivity. That’s a LOT of toil, and they have to keep up with changes in a painful manner with lots of diffing. If they could grab the lowest level, or maybe the custom elements with it, they would be off to the races in a sustainable manner.

Others felt they had to use React for these pieces, and hired consultants to do that work. This ate into their profits, and in dire situations could change the entire ROI of their solution (for small apps with a one or two person team).

I believe this design system will iterate and change over the lifetime of this company, that aims to be a 100 year one. You could argue that they are big enough to always make sure the React version is solid and updated and that developers have resources to keep with it.

Or, the evolution could happen at each level of the stack. Long time developers would understand the lower levels, and as they changed the highest framework level, they would be able to reuse that knowledge, use a community layer, or maybe the company has changed the first class framework and can use that solution.

If you have a modern design system, learn from my mistakes, and build it in layers.

That way a developer that chooses a different graph of tools from the subset of the options as Kent shows here, versus your exact path (which you will change too in the future), can play too.

/fin

The holy grail of a Web SDK

June 7, 2022

As I sit here watching WWDC, I get that same feeling. Everything is vertically integrated. The layering of the SDKs, with much that is shared, and then differences for iOS vs. Mac vs. tv, etc. You can’t hope but look at the Web and think “oh man, the paradox of choice over here… with so much evolving and changing to keep up with!”

The old analogy comparing dictatorships vs. democracies continues to ring somewhat true.

I have made the mistake in the past of wanting to chase the holy grail of a Web SDK that has the benefits of a unified stack that takes care of everything. However, I have learned that this is a holy grail in the sense that it can’t actually exist on the Web in the form that you think of.

The quest is wrong. We shouldn’t try to be like Apple, and compete in the same way with a history and ecosystem that isn’t setup to succeed in that form.

Well, what is the right quest?

  • We should embrace the ecosystem, and the players lower in the stack (e.g. browsers shipping the web platform) should embrace the fact that so much evolution happens on top. Plan for this. Be malleable and modular, and allow for shifts and changes. Most of all, be enablers for the stack on top.
  • The web platform can absolutely do better with undergrounding gains that come from the evolution in user space. The Web is a meta-platform that ships with browsers. Anything in user space is fairly costly, but has the trade-off where it can evolve quickly (downloading libraries / updating libraries).
  • It is a fair criticism that the Web has many primitives baked in for documents, but leaves much of app development to user space. If you build something truly app-y, you can end up somewhat frustrated. It’s improving all the time, and there are things that are amazing about building web apps, but there is a ton to improve here.
  • In general, there is value in seeing what primitives are needed to help the various types of experiences that users choose on the Web. It’s so broad, and the needs for content, commerce, apps, and games are different and yet share a lot.

I am seeing a lot of progress in areas that push us forward:

  • WebAssembly as a lot level runtime for client AND server that can change the game, opening up a TON of room for the ecosystem to innovate.
  • Massive CSS improvements with container queries and new helpful syntax bumps, and losing the need for preprocessors for obvious changes (this is all good undergrounding!!)
  • Apple hiring and catching up with app related APIs (e.g. Web Push, making PWA not be somewhat broken). There is still so much that is needed here, both in WebKit catching up and also the entire Web pushing forward. Dogfooding with Active Recall is very humbling!

Let’s lean in. Platform folks work together and build hooks and capabilities that those on top can innovate with. App devs and framework/library folks, share what you need. Together, push on where we want the Web to go and use the fact that it isn’t run by one company.

App Mode

August 17, 2021

What would <html app> do? 🤔

The Web can continue to evolve by taking the long term view and chipping away with adding necessary functionality, and eliding some of the mistakes (albeit hard).

However, I have been pondering if we should be exploring some bigger bets:

  • First, looking at certain verticals (content, commerce, apps) and prioritizing web platform features and tooling to make them successful holistically
  • Second, breaking out of the “browser” and be progressive all the way to the native platforms by adding escape hatches

I also miss Flash (or at least the capabilities and DX thereof), so I'm probably worth ignoring…

— Paul Lewis (@aerotwist) August 12, 2021

Now, let’s take another look at building the UI for apps on the Web in a very webby way, embracing what’s good about HTML, CSS, and JavaScript, but really re-thinking it for apps.

Don’t let evolution get in the way

How connected are we? Very.

Evolution is resilient and special. Pair it with immense time frames, and life will find a way, even as many experiments will be left on the way side. One of the strengths of the Web is how it evolves as a platform, but it can be a double edge sword.

We can’t expect to constantly evolve while keeping the entire history front and center. We have fragments in our DNA that go back to the birth of life, but much of it is very much hidden and ignored.

We can embrace evolution that allows us not to keep the baggage around. If you look at a hello world web app, that supports a decent set of browsers, you will find yourself setting up resets of sorts, meta tags, and a series of cruft. This cruft creates cognitive overhead for developers.

In hindsight, we will always make mistakes in the platform and come up with solutions. One simple example that we all know, is that of box-sizing.

I don’t want the default content-box model, and instead agree with Paul from 2012, and many since, who recommend we go all in and flip the default to: box-sizing: border-box;

In 2021, the vast majority of your users will be coming at you via an evergreen modern browser. This is huge, and allows us the ability to flip to a modern-first approach of development that doesn’t tax all of our users for the lowest common denominator. Finally, we can speed up evolution!

While it’s phenomenal that old content sitting on the Web can still be browsed (but of course, this isn’t always true, plenty of old content breaks), it also means that browsers are constrained. They can’t just flip the defaults because *new* content is being developed using new ways, thus we are a lil stuck.

How could browsers do the best job they can at rendering all content, including great content written many moons ago, whilst allowing for new content?

Multiple Rendering Paths

Remember quirksmode? I still see developers accidentally finding themselves confused, because they have put their document into quirks vs. standard mode.

We also have AMP, which forces a constrained mode, optimized for documents keyed off of:

<html ⚡ lang="en">

So, what if we took a leaf out of these books, and had something like:

<html app lang="en">

This could give us a way to tell the browser that we want a new world, one optimized for apps rather than documents. A way to trigger a reset. This would give us a chance to re-think building web apps that still uses HTML, CSS, and JavaScript and feels very webby, but in a sane way for the app use case that is quite different to content.

What could we see?

App-oriented Layout

I love our Grid and Flexbox world, but we could also look into constrained layout modes, working closely with tooling vendors as the Android team did when they shipped their most recent layout systems.

App-oriented Components

Take another look through the HTML spec and the various elements you have built in. I bet you will find some elements that you have never used, such as <aside>. There are a ton of document focused elements, which is great!

But we stopped. While it’s great to abstract and create our own components, either through Web Components themselves, or via framework abstractions that spew out div soup, why haven’t we undergrounded the great learnings from the ecosystem? My kingdom for tabbed UI, and the good ole UITableView! Fortunately, I am seeing more exploration and appetite for this!

App-oriented Data Flow

When you are building rich web apps, and you try to really build your app offline-first, with optimistic UI, you run into a lot of issues around data and syncing.

It’s a shocking shame IMO. Maybe I’m remembering history a lil incorrectly but I think Mozilla was one of the proponents to get rid of WebSQL and Indexeddb was implemented on top of …… SQLlite!

There is room for IDB, especially cleaned up, but ….

— Dion Almaer (@dalmaer) August 12, 2021

We just saw James Long dig into the mess that is IndexedDB and the lack of a portable WebSQL/SQLite. What can we do to really enable experiences that can rely on data?

Are we forcing it? What about WebAssembly?

But wait a minute, are we barking up the wrong tree here? Maybe the solution is to keep HTML, the DOM, and friends for the content Web? Or maybe content++… allowing for interactivity but not as far as full on apps!

Flutter using the Web as a target

With WebAssembly, we could keep URLs, but have them toss back apps that are WebGL renderers! We could just use Flutter for Web as an example. This would allow many runtimes to evolve on top, and bobs your uncle.

While this may make sense for some use cases, and I love that Flutter developers have a path to Web, I don’t think that we should cede all apps to this model, as it naturally ends up with blobs at the end of URLs, and we lose a lot of what is great about the HTML/CSS/JS web.

I know that it is quite niche, but I love how Chrome Extensions can compose and hack the Web. This is a super power akin to an after market for car parts. Someone can create functionality that helps you with another services, and I would like more of that, not less. The Web is fantastic at streaming UI, and we can do more to make this all work well with apps, versus the years of fighting against it and downloading the world before rendering anything.

Thus, I find myself dreaming of layers, or adding the primitives that allow for evolution, but also having another go at baking app UI right into the web as a first class citizen, instead of it being a render target with so many foot guns and uncanny valleys. I dream of a studio of tools, aligned with the platform, to make this possible working hand in hand.

Chrome 91 removed the ability to do alert(), confirm() etc from cross-origin <iframe>s. https://t.co/1n1hhfVhE5

Probably a net-good move, but that means you literally can't use these on CodePen (and others) in any way.

Is there a sandbox flag or something to re-allow?

— Chris Coyier (@chriscoyier) July 27, 2021

And then I wake up to see debates around a simple alert(), and how hard it is to make changes, and I once again ponder escape hatches that allow us to make bold changes.

It’s complex and hard to make some moves, as when you have a platform you need to make sure that both:

  • developers have a happy path, know when they are doing something sub-optimal and how to fix it, and make that happy path the one that doesn’t lead you there
  • and, we minimize the attack surface to make it as hard as possible for bad actors to do harmful things to users and businesses.

And there’s often the rub, as the same capabilities and loopholes can be used for both.

Apps were born on a document platform, and we are still lacking a holistic web-first app platform that could unlock experiences that have great attributes from the web, but are also more fun and productive for developers to build.

What is in your app mode?

Next Page »

Primary Sidebar

Twitter

My Tweets

Recent Posts

  • The Pursuit of Taller Hills: Lessons from Football and Product Management
  • Building a modern design system in layers
  • Google A/I/O 2023: In Person Matters
  • Help Mario Reach The Next Platform!
  • I have scissors all over my house

Follow

  • LinkedIn
  • Medium
  • RSS
  • Twitter

Tags

3d Touch 2016 Active Recall Adaptive Design Agile Amazon Echo Android Android Development Apple Application Apps Artificial Intelligence Autocorrect blog Bots Brain Calendar Career Advice Cloud Computing Coding Cognitive Bias Commerce Communication Companies Conference Consciousness Cooking Cricket Cross Platform Deadline Delivery Design Design Systems Desktop Developer Advocacy Developer Experience Developer Platform Developer Productivity Developer Relations Developers Developer Tools Development Distributed Teams Documentation DX Ecosystem Education Energy Engineering Engineering Mangement Entrepreneurship Exercise Family Fitness Football Founders Future GenAI Gender Equality Google Google Developer Google IO Habits Health Hill Climbing HR Integrations JavaScript Jobs Jquery Kids Stories Kotlin Language Leadership Learning Lottery Machine Learning Management Messaging Metrics Micro Learning Microservices Microsoft Mobile Mobile App Development Mobile Apps Mobile Web Moving On NPM Open Source Organization Organization Design Pair Programming Paren Parenting Path Performance Platform Platform Thinking Politics Product Design Product Development Productivity Product Management Product Metrics Programming Progress Progressive Enhancement Progressive Web App Project Management Psychology Push Notifications pwa QA Rails React Reactive Remix Remote Working Resilience Ruby on Rails Screentime Self Improvement Service Worker Sharing Economy Shipping Shopify Short Story Silicon Valley Slack Soccer Software Software Development Spaced Repetition Speaking Startup Steve Jobs Study Teaching Team Building Tech Tech Ecosystems Technical Writing Technology Tools Transportation TV Series Twitter Typescript Uber UI Unknown User Experience User Testing UX vitals Voice Walmart Web Web Components Web Development Web Extensions Web Frameworks Web Performance Web Platform WWDC Yarn

Subscribe via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

Archives

  • May 2023
  • March 2023
  • February 2023
  • January 2023
  • September 2022
  • June 2022
  • May 2022
  • April 2022
  • March 2022
  • February 2022
  • November 2021
  • August 2021
  • July 2021
  • February 2021
  • January 2021
  • May 2020
  • April 2020
  • October 2019
  • August 2019
  • July 2019
  • June 2019
  • April 2019
  • March 2019
  • January 2019
  • October 2018
  • August 2018
  • July 2018
  • May 2018
  • February 2018
  • December 2017
  • November 2017
  • September 2017
  • August 2017
  • July 2017
  • May 2017
  • April 2017
  • March 2017
  • February 2017
  • January 2017
  • December 2016
  • November 2016
  • October 2016
  • September 2016
  • August 2016
  • July 2016
  • June 2016
  • May 2016
  • April 2016
  • March 2016
  • February 2016
  • January 2016
  • December 2015
  • November 2015
  • October 2015
  • September 2015
  • August 2015
  • July 2015
  • June 2015
  • May 2015
  • April 2015
  • March 2015
  • February 2015
  • January 2015
  • December 2014
  • November 2014
  • October 2014
  • September 2014
  • August 2014
  • July 2014
  • June 2014
  • May 2014
  • April 2014
  • March 2014
  • February 2014
  • December 2013
  • November 2013
  • October 2013
  • September 2013
  • August 2013
  • July 2013
  • June 2013
  • May 2013
  • April 2013
  • March 2013
  • February 2013
  • December 2012
  • November 2012
  • October 2012
  • September 2012
  • August 2012

Search

Subscribe

RSS feed RSS - Posts

The right thing to do, is the right thing to do.

The right thing to do, is the right thing to do.

Dion Almaer

Copyright © 2023 · Log in

 

Loading Comments...