DEV Community: Jonas Ulrich

Unlocking the frontend – a call for standardizing component APIs pt.2

Jonas Ulrich — Tue, 05 Mar 2024 15:56:55 +0000

#tldr Why Design Systems, and a more structured approach to frontend engineering in general, might be key to a more shared frontend ecosystem. And how this thought might hit an interesting inflection point rather sooner than later, with the advent of production-ready Web Components as a shared technical standard and foundation for interoperability.

So what are the missing pieces? And how could our latest release, and the accompanying schema tooling open sourced with it, play into this? And what would a blog post be today, without tying it into AI? Buckle in: this will be a long one!

Status Quo

Sometimes, at least to me, the current Status Quo in the frontend world feels more fragmented then ever before. Between Tailwind UI and the likes, CSS-in-JS, and a multitude of (differently) opinionated frameworks fighting for our attention “for all the right reasons”.

Meanwhile, web standards seem to rapidly catch up… with native nesting and @layer in CSS and, to name just two great features we’ve won on that front lately, web components getting Declarative Shadow Dom, the Design Token standard rapidly approaching, React finally merging web component compatibility for React 19 it seems, the list goes on.

Nonetheless, we’re still mostly redoing a lot of work, especially those trying to craft bespoke frontend solutions… and not just hitching their wagon to something like Material UI / MUI, and calling it a day.

Does this have to be so fragmented? Don’t we all, in the end, “just” build interfaces based on HTML, CSS and JavaScript… that happen to mostly run in the browser?

via [GIPHY](https://giphy.com/gifs/q9AgIEA8kKWWI2paHT)

Finding universality

Thinking about it… what actually is universal in components? I’d say: They all have an API. Call it Component Props like React, Vue and Svelte do, or Property Binding in Angular, Variables in Figma, or even the structure of Frontmatter typically found in an 11ty code base.

Currently definition of those structures is dominated by either a backend system / API, leaking a backend view of the world into the implementation, or Figma / Sketch / etc design prototypes which attempt to model them, which can skew the focus into a too visually reductionist direction. Either way, it gets really hard to reuse stuff, because you have to re-adapt your code every time a change occurs. You’re “downstream” from the decisions being made and their resulting changes affecting you; and now imagine how people working with the resulting interfaces on a daily basis must feel 😱.

Why else might this be a problem? It shouldn’t be (solely) developers or designers who own this type of API. And this is where we think Design Systems enter the picture, as they establish a collaborative process of component API creation. Nathan Curtis describes this quite nicely:

A design system aspires to achieve a shared vocabulary between designers and developers. As we build visual style and UI components, we make many decisions about how a feature is composed and configured.

Nathan Curtis

I’d add content editors and select stakeholders to that process. Having enough context matters, especially when creating a Design System. I really liked Eduardo da Silvas article on “Sociotechnical architecture”, and I think it very much applies to the introduction of a Design System into an organization!

When also taking into account the structure of most every headless CMS out there, many of those having themselves adopted a component based approach for their content modeling, you start to notice that there already seems to be something like a standard, and shared way, to express this: JSON!

So why do we still have to chase the ball when creating frontend code? Why reinvent the wheel for every project… painstakingly redefining everything, remapping it to CMS and backend systems, and so forth. Can’t we take more control of this process somehow? And wouldn’t it, as a concern, be better handled in something like a Design System anyways?

So how could such a standard look like?

Enter the world of JSON Schema

As luck would have it, there’s JSON Schema… let me quote their central mission statement:

Build more. Break less. Empower others. JSON Schema enables the confident and reliable use of the JSON data format.

https://json-schema.org/

Already embedded deep into quite a few development workflows (either through the Open API standard, where it is used for model definitions, or something like Postman to build APIs collaboratively) this immediately enables safer, greater and more meaningful interactions between frontend engineers, backend engineers and those working on APIs / microservices. It’s also already in use in some Design System tooling (like Knapsack), or behind the scenes in headless CMS systems.

For a more in-depth intro, give Ben a listen on his great video here:

Again: I’m pretty convinced that this layer could be universal!

If, additionally, you decouple the Design System as a rule-based framework for design, component, UI and product creation from specific implementation choices taken for components, or a component library as part of your Design System, the value gets more obvious. You start differentiating between the structure and function of a component, and its implementation. Or even multiple implementations when supporting different frontend technologies simultaneously. A mix of components from different frameworks, or different component libraries inside the same framework, starts to become an implementation detail, while everything stays unified under the umbrella of your Design System.

An idea brewing for quite a while already

As our roots stem from 20 years of agency business, we’ve early on started trying to find ways to reuse frontend code, and better decouple frontend from backend engineers in the process. Back then, for us, this meant integration of independently developed frontend code into (mostly) PHP based backend systems like TYPO3 and WordPress (being an “integrator” was an actual job profile in places, with certifications and everything).

Through integrated templating engines (like Fluid for TYPO3) we started exploring better abstractions for reusable frontend code, and ways that could help map it to a backend system.

While this helped ease integration work, in parallel to that we also started exploring more systematic approaches on the frontend side itself. With the advent of Brad Frost Atomic Design, and tools like Pattern Lab, we started using a more component-centric approach. This included colocating all styling (CSS), behavior (JavaScript) and semantic structure (HTML) for a component, and way better encapsulation as a whole. And most influential for us, it turns out, it meant documenting all our expected variants of a component as JSON data:
https://patternlab.io/docs/overview-of-data/

This left us with a pretty extensive, reusable frontend component library, as most of the projects at the time had pretty similar base requirements, especially when it comes to creating content-driven websites (I’d argue even more so today).

When finally deciding to end our journey as an agency in 2021, to instead transform to an Open Source, product-led business with kickstartDS, this meant we already had a great starting point and a heap of experience with creating complex, modular and reusable frontend setups (we’ve also built some early Design Systems for German DAX listed enterprises around 2013-2016, for good measure).

The first thing we did was a complete rewrite of our code base, with everything we had learnt so far in mind. We ditched Pattern Lab for Storybook, replaced Handlebars with React (but only for its templating capabilities in JSX, everything still usable as pure HTML), updated all client code to vanilla ES6, but most importantly: we ported all of our existing Pattern Lab components and variants by encoding their data.json files into JSON Schema backed component definitions, or component APIs as we like to call them today.

via GIPHY

JSON Schema was something that had accompanied us for quite a while already by then. Back in 2013 we started experimenting with using it to structure data for static site generation. A colleague of mine, over 10 years ago 🤯, even wrote quite a nice (somewhat foreshadowing?) article about it:
https://pascalhertleif.de/artikel/silicon-zucchini/

This also marked our first time experimenting with generation of editor interfaces for content, based on our already existing JSON Schema definitions. Which ultimately lead to the release of our kickstartDS low-code CMS starters, and the tooling behind it, today!

What did we build?

We’ve built out tooling that can take component APIs as JSON Schema definitions, like those used in kickstartDS, and process and convert them to other useful formats.

What’s a format, you might ask. For us, currently, this can mean one of two things:

Development: Mainly pure TypeScript types for your components, and other related, generated output like GraphQL fragments or dereferenced JSON Schemas definitions
Integration: Headless CMS configuration; processing and mapping your Design System to the concepts of a specific content authoring solution, like Storyblok

That second part is what enables our CMS starters. They use this to take the Design System for design-system.agency and transform it to respective CMS configuration (for Static CMS, Storyblok and Netlify Create / Stackbit as of today) that can be used to start building a website based on such a Design System immediately. Everything demoed with those starters works the same for every Design System built with kickstartDS. To be more precise: it should work with every Design System that decides to encode its component API in JSON Schema. It’s completely generalized!

https://github.com/kickstartDS/schema

And if compatibility with every kickstartDS based Design System is one important dimension of creating the starters and converters, in the process building out the concepts and tooling to make creating connectors easier might actually be the more impactful one. The starters, and their respective connectors, are mainly meant as a demo on how powerful a strong JSON Schema-backed Design System can be. We hope it inspires others to build their own like-minded integrations for their (rightfully so) super specific needs. Hopefully our tooling can aid people in implementing those!

But after all… this is still mostly our own silo. This doesn’t unlock any greater effort, yet…

via GIPHY

And why might this matter!

I hinted at this in the very intro to this lengthy post. Web Components seem to be leaving behind their growing pains. With Declarative Shadow DOM arriving, one of the last missing pieces seems to finally complete the picture there.

With React (it seems) finally moving to support everything needed (they are the last major framework lagging behind substantially), too, we might be moving to a world post-framework discussions, and real interoperability on a technical level. I think Jake Lazaroff motivates this beautifully with his articles “Web Components Eliminate JavaScript Framework Lock-in” and “The Web Component Success Story”.

Brad Frost also recently wrote about his dream of a global Design System, and Web Components play a vital role there, too:

Given the above principles, I think it would make sense for the Global Design System to be a library of Web Components. Web Components are part of the web platform and are interoperable (in theory at least) with any web-based tech stack.

Brad Frost, A global Design System

In another great article of his, “The Design System Ecosystem”, you’d probably recognize it when he talks about the “core design system”. And some frameworks, like Astro, experiment with similar ideas about composition and collaboration, irrespective of specific frameworks, already.

If you now couple this with a shared way of documenting features and properties for shareable components (🗣️ JSON Schema), you can truly unlock the compositional potential the frontend should have.

We actually think people should build their own tailored casings around different component libraries, frameworks, and standards as they see fit for their requirements, there should be no lock-in:

Design: Connect your Design Tokens to a MUI theme to cover for your backoffice dashboards, or to Figma to enable a better designer-developer-workflow
Implementation: Integrate specialist libraries for specific requirements, like we do with Bedrock Layout Primitives for layout needs in kickstartDS itself
Structure: Use JSON Schema to add structure for interoperability with other systems and integrations (referencing could bridge and connect different systems through URIs)
Content: Use our kickstartDS Content module to fill gaps in your coverage of modern content page requirements

Add automation to leverage all of that to automatically, or at least more easily, connect and integrate your adopting systems. kickstartDS was built with those assumptions deeply embedded, and can serve as a great starting point to achieving the same for your Design System!

via GIPHY

A call to reverse roles

When building a Design System as described, you invest effort upfront, and justifiably so. If done right, this should not become a throwaway product. It shouldn’t die with a rebrand or redesign… or the change of CMS / backend. In my opinion it should be even more long-lived than every other aspect of your digital toolchain. Especially with the rise in composable and MACH architectures it will be increasingly important to have such a cornerstone in place.

How you interface with your users, customers or editors as a business should not be dependent on technological decisions. Only changes to your organization, or its embedded processes, should necessitate changes to your technical approach and ultimately the stuff you build, not the other way around.

And if your business, or some of your use cases, change or expand, having it set up like this can dramatically reduce the effort needed to reflect those changes downstream in your stack. A change of CMS for a some of your editors can be as easy as switching the integration you use.

This way we can realize the true potential of Design Systems, as the stabilizing core of your digital ecosystem.

via GIPHY

How this relates to AI

There’s a lot of buzz around AI in Design Systems currently (to be fair: this is probably the case for every imaginable niche out there).

With tools like Hermae (your custom Design System assistant) or Magic Patterns (your copilot for UI creation) launching, packaging existing ideas and workflows into an easy-to-digest form factor, while others like Jonathan of Roboto Studio show how this can also work by just using the right IDE, there’s still a lot of finger-crossing and LLM-wrestling involved when working with the results.

In the end, someone has to define what your org needs, and how its processes look like. AI can’t (I mean: it shouldn’t) do that. This is where you can use the human element to your advantage, as leverage for (generative) AI. If you know what you need, and you should have made sure that you do (remember the article I mentioned earlier about “Sociotechnical architecture”), encode it in a way that it can also be used for guided generation / Gen AI!

And I think “just” Markdown doesn’t quite cut it for safe guidance. For example: directly generating content for your components. But I’m really excited about tooling like outlines appearing, with a greater focus on guided generation for structured data. Because this is often what we actually need!

Taking outlines: as a coder you could easily plug your Design Systems JSON Schema into it… immediately getting complete safety on the data being generated actually being compatible to your component APIs. Or you could opt for .json, by the authors of outlines, to use the same capabilities through their API, even without deeper technical knowledge.

This is the strength we see in JSON Schema as a guiding factor in structured generation, good docs automatically serving as semantic context for the AI model / LLM.

via GIPHY

Looking forward

What does this mean for us? We’ll keep a good eye on Web Components, as this seems like the next evolution to go through. Replacing our React templates with pure Web Components, gaining even more framework-independence, seems like a pretty sure thing to happen.
We’ll also keep exploring ways of content generation, using tools like outlines. We already have encoded the concepts of website settings, content pages and blog posts into JSON Schema, powering our CMS integrations today. It would be a logical next step, to have guided content-generation, independent of headless CMS in use: “Please draft me content for a page about our upcoming release, use our Design System components for guidance”.

We also foresee a need for better general migration support (e.g. when changing a component in a breaking release), and ways of more flexibly mapping / connecting data to component APIs, or gluing together different component APIs for compatibility (e.g. when integrating with third party libraries).

And in general, I sincerely believe that at the intersection of Web Components and JSON Schema lies the potential to unlock the full power of a shared frontend ecosystem!

What do you think? Let me know on Twitter at @tsnmp or Bluesky at @tsnm.bsky.social. You can also connect with me on LinkedIn here!

Or join our community on Discord: https://discord.gg/mwKzD5gejY

Launching the Design System Concierge

Jonas Ulrich — Mon, 01 May 2023 22:16:28 +0000

Introduction

We’re thrilled to share the Design System Concierge with you! You can reach him here as of today: https://www.kickstartDS.com/concierge/

Watch a small dramatization of what interacting with our Concierge looks like:

Support us on Product Hunt for our launch:

Design System Concierge - Your AI-powered Design System assistant | Product Hunt

Get Design System answers, fast! Our AI-powered Concierge offers insights from our vast Design System database sourcing expert content only. Ask any question, get pointed to the right source. Your ultimate Design System assistant.

producthunt.com

Why build the Design System Concierge?

As Design Systems gain more and more traction these days, the amount of available content can be overwhelming, making it difficult to know where to start. Our AI-powered Design System Concierge can help by providing expert guidance and pointing you towards the right resources, whether it’s implementation guides, architecture documents, adoption strategies, or other content.

Talking to the Design System Concierge

To get the best possible help from our Design System Concierge, we recommend asking detailed questions instead of engaging in a chat. The Concierge provides quick and transparent answers by summarizing the most relevant content sources. Every answer includes underlying sources that you can easily check and visit. Trust us to deliver accurate and reliable information for all your Design System-related queries.

It’s important to note: The final answer is generated by Open AI GPT-3, and even if we take great care to reduce wrong answers you should always dive deeper. The answer given is not really meant as the end of your interaction. You can, and should, dive deeper into the sections most relevant to your question… as the Concierge is great at giving directions, but not really an expert himself (just like in real life!).

Why use it

Using it is free

Asking questions to the Concierge is completely free of charge for you. We’ve developed, and are now hosting, it, because we want to help lower barriers of entry when it comes to Design Systems. After all our mission is to “Democratize Design Systems”.

Additionally it’s a great opportunity for us to learn what you, as a user, actually want to know more about when it comes to Design Systems… or features that you’d expect from a Design System. This in turn can inform us on features to develop for kickstartDS, articles to write, or documentation gaps to fill in.

It’s specialized for Design Systems

Though the final answer is generated by Open AI GPT-3, all input given to it as context is completely controlled by us, and our integration. Only carefully selected sources (= domains with content relevant to Design Systems) are added to the Design System database, backing the Design System Concierge. This ensures answers will be relevant to the topic, and hallucinations are minimized. If there’s no relevant content in the database, no answer will be generated!

Additionally, by providing the exact sources the answer by the Concierge was based on, you should always verify it for yourself by diving deeper.

It promotes great content & creators

Sometimes it’s tough to just “google” your answer, especially when faced with highly individual and specialized questions… the ones you’d typically have when starting out, or when facing new challenges. Good content gets drowned out by a sea of content farm spam. By asking the Concierge instead, you get a highly curated set of content as the backbone. Best case: you discover a new blog author, content creator, or a specific Design System example to follow, helping inform your Design System journey.

How to use it

For a quick overview, have a look at the following, short animation:

1. Ask a question

Enter detailed, natural questions instead of trying to engineer your way out of a thick jungle of content spam, only armed with the waning powers of Google-Fu:

2. Get initial answer

Receive an initial answer instantly by the Concierge. This should be taken as a first summarization by an enthusiastic, helpful assistant… not as the final expert answer to end all answers:

3. Dive into sources

Even more useful then the initial answer are the sources provided by the Concierge. Those are the sections of text in our database that were found to be most relevant to your question. This should provide full transparency, and enables using the Concierge as a great guide-post to the real content:

How it’s done

Database of expert content

The Concierge is backed by a vast database of content curated, prepared and catalogued specifically by us:

For a full list of sourced domains, go to the Concierge. All domains are listed in the section “Knowledge database” over there.

Behind the scenes

The implementation is mainly following the great blog post (and example code) provided by Supabase. Their post was also the main reason for me to use Supabase with their PostgreSQL + Edge Function for the main hosting in the end. It’s a super nicely packaged solution, was just loving the DX!

Going into all the nitty gritty details would go beyond the scope permitted by such a blog post as this one (Spoilers: it includes non-Open AI SBert embeddings, a Fly.io Python- / Flask-Webservice for runtime embedding of questions, spliced and transformed Server Sent-Events streams, pgvector for database support of embeddings, etc, etc). Feel free to join us on Discord to discuss further… and for all the quiet explorers among you, I’ve made a Miro board outlining how everything works, over here:
https://miro.com/app/board/uXjVMdpB0ao=/

Alternatively, you can just go to the Github repository for the Concierge. All the code is public and Open Source here:
https://github.com/kickstartDS/concierge

Conclusion

We really hope the Design System Concierge can help you along your personal journey through the Design System space. We’re thrilled to see all the questions you’ll try on him, and what the overall reaction will be. We already have a truckload of ideas to explore further, if this resonates with the community!

If you want to give feedback to us, have ideas on what to improve or add, or just want to tell us what cool answers you’ve received… we’d love for you to join our small Discord community. Or maybe the Concierge was completely missing the mark for you? We’d especially like to hear about those cases, too!

kickstartDS is Open Source now. Let’s start to democratize Design Systems today

Jonas Ulrich — Tue, 15 Nov 2022 11:26:26 +0000

Finally, the wait is over … today we are very proud to announce the Open Source release of kickstartDS. It’s been roughly one year since we started to go to market by publishing our first website, and we are thrilled to now share the kickstartDS core with everyone in the Design System community.

We’re also officially live on Product Hunt! Feel free to drop as an upvote 🎉
https://www.producthunt.com/posts/kickstartds

Why have we decided to go Open Source?

Some of you might have read my post on why we are creating kickstartDS. Today, I can proudly say that we reached the next big milestone of our mission to democratize Design Systems. Last year we started to implement kickstartDS for selected pilot customers, keeping the source behind closed doors. We wanted to validate technical decisions taken, and learn how developers interact and adapt kickstartDS.

During that time, while doing user research, presenting our ideas and solutions to developers, we often heard that they really like it… and that they would love to test it by directly installing “the package”. Well, who would go for a no-name, closed solution to build up something highly important like their Design System?

Open Source is the way! A couple of months ago we took the decision to share all our learnings and practices, wrapped up in the baseline of what kickstartDS is today. We want to continue that learning journey. That will be even easier with people working with kickstartDS independently, who hopefully also share their experiences and stories with us in the process. That is what we’d like to encourage users to do. Just try our setup guide… and once you own your Design System based on kickstartDS, really make it your own. Tell us how you adapted it towards your individual needs, even how you named your components, how you get along with it adoption are super interesting to us! So please share it with us and the community.

Help democratize Design Systems!

The term Design System describes a broad topic, growing more and more momentum. Where large organizations today mostly have problems with the adoption or governance of theirs, in small to medium enterprises the problem often already is to get a Design System started at all. For example, when standard frameworks are too difficult or complex to adapt, when stakeholders need to be won in a time when frontend experts are a rare good. The approach is doomed and will lead to compromised technical solutions; consuming even more time and budget.

Today quite some companies are already tackling similar problems. Talking of Knapsack.cloud, Backlight.dev, Specify, Supernova and many more, here. They all deliver value to simplify workflows for setup, integration, documentation and management of Design Systems. This is all super helpful in spreading the love about Design Systems to teams out there, and is a huge benefit to the process side of things. But you usually still need to create or import all of your components, which means that you still have some hard work before to you yourself, before finally benefitting from these tools. There’s also a lot (knowledge and work) going into the setup of a Design System (semantic tokens, hardened components, etc) that’s not solved by those tools, yet.

Setting up a code first Design System has never been easier

Developer Documentation

Visit our GitHub

To help you getting started quickly, we created documentation guiding you through the installation process of your first Design System built with kickstartDS… in just 5 rather simple steps.
The main steps will go as follows:

Start your Design System
Design Application
Configure Storybook
Add Components
Publish your Design System

Although the resulting Design System will obviously not be finished by finishing these steps, you’ll have everything set up to start on the real work.

The essential part

At that point you already got rid of some of the core challenges. Plus, this might even give you the mental freedom to tackle the unique components to your organizations actual needs.

Thinking of such components … usually, every company has content to display. On their website, on marketing or landing pages, in their intranet or documentation, you name it. You can now start developing the perfect “Hero Visual Component” with our basic Open Source components or you can skip even that by relying on our complex content components, which you can easily buy for a few bucks to add as additional building blocks for your freshly created Design System.

That package, additionally, really puts you in the driving seat… speeding up the ride for even the most individual and complex cases you’ll want to solve, the “next component your organization needs”. (this refers to Dan Mall’s talk on Converge’22, available through their registry here)

What’s next?

Now that kickstartDS is public we look ahead to its future with an open mind. We still have to work on many details to let our documentation really shine, for example. As we want to explain the underlying concepts in-depth. And since everyone is now free to install, test and use kickstartDS we believe in the great openness of the Design System community. We rely on your feedback by adapting to your needs, so that kickstartDS will really become the Design System starter digital teams like to work with.

Releasing kickstartDS doesn’t mean that the development is completed. We have lots of ideas in mind. Features or modules which may find the way into the portfolio, thinking of telemetry, adapters, transformers and much more based on our Component API.

Not to forget: a Design System is nothing without systems using it!

A Design System is there to generate value, to support the organization to better reach its objectives. Naturally there will be product or feature teams using it. About that, a 6th Step could and maybe even should be added to the setup process of the Design System.

Step 6: Apply your Design System

Whilst setting up kickstartDS you made quite a lot of decisions adapting the library to your organizations’ specific needs. You decided which properties every component needs, how to name components, and much more. What would you say if we told you: you can even add a CMS, using these exact Design System components, with just a handful of clicks? Where your editor immediately benefits from all your decisions, because the properties of components in the editor UI are always aligned with those from your Design System.

We offer adapters for some well-known content management systems already, e.g. Sanity.io, NetlifyCMS, Storyblok, Contentful and even WordPress.

One more reason why we think: relying on kickstartDS when building your Design System is of huge value for you and the Open Source community, who can start building more adapters and implementations on top of kickstartDS to simplify the process of applying Design Systems.

The importance of the growing Design System community

Thinking about the best thing we could achieve with kickstartDS, and as already written in this posts’ headline: do our part in democratizing Design Systems. The more people know about kickstartDS, the more organizations use it, the more developers build Design Systems based on it, the better it will become in the future. Helping organizations adopt best practices, and hopefully help everyone to get their Design System that decisive bit faster, while having fun doing it!

Join our Discord community to share feedback, ask us questions and start any discussion around kickstartDS.

Take a look at kickstartDS on GitHub, and tell us what you think.

And if you're on Product Hunt, we'd love your vote 🤗
https://www.producthunt.com/posts/kickstartds

Quarterly Design System and Frontend Podcast Roundup - Q1/22

Jonas Ulrich — Thu, 21 Apr 2022 19:07:11 +0000

#tldr Read our roundup of podcasts released in the first quarter of 2022. Everything related to Design Systems, Frontend development and headless CMS / Jamstack.

I’m listening to quite a collection of podcasts regularly, as I just love to learn about new stuff… and what others are building. And sometime at the end of last year I decided to favorite all those episodes that were really interesting to me. So this will be the obvious bias here… 😅
But maybe this turns out to be useful for others, let me know!

Podcast themes include: Design Systems, Frontend, UI, React, headless CMS, Jamstack

And I’ve added everything I starred in April so far, too… for good measure 😉

Podcasts featured:

PodRocket: https://podrocket.logrocket.com/ (12 episodes)
JS Party: https://changelog.com/jsparty (5 episodes)
devtools.fm: https://devtools.fm/ (3 episodes)
JavaScript Jabber: https://javascriptjabber.com/ (3 episodes)
That’s my JAMstack: https://thatsmyjamstack.com/ (3 episodes)
JAMstack Radio: https://www.heavybit.com/library/podcasts/jamstack-radio/ (2 episodes)
Front End Happy Hour: https://www.frontendhappyhour.com/ (2 episodes)
Console DevTools Podcast: https://console.dev/podcast/ (2 episodes)

This also means (at least for me) that PodRocket takes the crown for most listened podcast of the quarter… and by quite the margin, too! 🚀

On to the monthly overview:

April

April 15th, 2022

PodRocket: “Remix with Chance Strickland”

Hosts: Kate Trahan, Kaelan Cooter
Guest: Chance Strickland
Length: 26m 8s
Link: https://podrocket.logrocket.com/remix

April 14th, 2022

devtools.fm: Episode #28 “Steve Sewell – Builder.io, partytown, Qwik, mitosis”

Hosts: Andrew Lisowski, Justin Bennett
Guest: Steve Sewell
Length: 01h 06m
Link: https://devtools.fm/episode/28

April 14th, 2022

JAMstack Radio: Ep. 99 “Headless Commerce Engine with Sebastian Rindom and Nicklas Gellner of Medusa”

Host: Brian Douglas
Guests: Sebastian Rindom, Nicklas Gellner
Length: 28m 01s
Link: https://www.heavybit.com/library/podcasts/jamstack-radio/ep-99-headless-commerce-engine-with-sebastian-rindom-and-nicklas-gellner-of-medusa/

April 8th, 2022

Front End Happy Hour: Episode 147 “Debugging Asynchronous JavaScript – Awaiting My Drink”

Hosts: Ryan Burgess, Jem Young
Guest: Jenn Creighton
Length: 44m 56s
Link: https://www.frontendhappyhour.com/episodes/debugging-asynchronous-javascript-awaiting-my-drink/

April 6th, 2022

PodRocket: “Storybook with Chantastic”

Hosts: Kate Trahan, Noel Minchow
Guest: Chantastic
Length: 51m 59s
Link: https://podrocket.logrocket.com/storybook

April 5th, 2022

PodRocket: “KendoReact with Kathryn Grayson Nanz”

Hosts: Kate Trahan, Noel Minchow
Guests: Kathryn Grayson Nanz
Length: 42m 39s
Link: https://podrocket.logrocket.com/kendoreact

April 1st, 2022

PodRocket: “AgnosticUI with Rob Levin”

Host: Paul Mikulskis
Guest: Rob Levin
Length: 30m 12s
Link: https://podrocket.logrocket.com/agnosticui

March

March 29th, 2022

PodRocket: “SPAs, island architecture, and the future of development with Ryan Carniato and Dylan Piercey”

Hosts: Kate Trahan, Noel Minchow
Guests: Ryan Carniato, Dylan Piercey
Length: 51m 00s
Link: https://podrocket.logrocket.com/island-architecture

March 29th, 2022

JavaScript Jabber: React Component and State Management – JSJ 526

Hosts: AJ O’Neal, Charles Wood, Dan Shappir
Length: 01h 8m
Link: https://javascriptjabber.com/react-component-and-state-management-jsj-526

March 18th, 2022

JS Party: Episode #217 Going full-time on Eleventy

Hosts: Jerod Santo, Nick Nisi
Guest: Zach Leatherman
Length: 58m 00s
Link: https://changelog.com/jsparty/217

March 18th, 2022

PodRocket: Polaris: The Shopify design system with Alex Page and Yuraima Estevez

Hosts: Kate Trahan, Noel Minchow
Guests: Alex Page, Yuraima Estevez
Length: 50m 51s
Link: https://podrocket.logrocket.com/shopify

March 16th, 2022

PodRocket: Final Form with Erik Rasmussen

Hosts: Kate Trahan, Paul Mikulskis
Guest: Erik Rasmussen
Length: 41m 32s
Link: https://podrocket.logrocket.com/final-form

March 11th, 2022

PodRocket: Accessibility with Ben Myers

Host: Kate Trahan, Brendan Downing
Guest: Ben Myers
Length: 39m 20s
Link: https://podrocket.logrocket.com/accessibility

March 8th, 2022

PodRocket: Composing layouts with Travis Waith-Mair

Hosts: Kate Trahan, Noel Minchow
Guest: Travis Waith-Mair
Length: 40m 35s
Link: https://podrocket.logrocket.com/composing-layouts

March 4th, 2022

JS Party: Episode #215 Remix helps bridge the network chasm

Hosts: Kevin Ball, Ali Spittel, Divya
Guest: Kent C. Dodds
Length: 01h 13m
Link: https://changelog.com/jsparty/215

March 4th, 2022

devtools.fm: Episode #25 Anthony Fu – Vue, Vite, Vitest, UnoCSS

Hosts: Andrew Lisowski, Justin Bennett
Guest: Anthony Fu
Length: 52m 30s
Link: https://devtools.fm/episode/25

March 3rd, 2022

Console DevTools Podcast: Designing dev products

Host: David Mytton
Guest: Ellen Chisa
Length: 32m 45s
Link: https://console.dev/podcast/s02e09-designing-dev-products-ellen-chisa-boldstart/

February

February 25th, 2022

JS Party: Episode #214 Vitest && Slidev

Hosts: Jerod Santo, Nick Nisi
Guests: Anthony Fu, Patak
Length: 55m 00s
Link: https://changelog.com/jsparty/214

February 23rd, 2022

PodRocket: Slinkity with Ben Holmes

Hosts: Kate Trahan, Paul Mikulskis
Guests: Ben Holmes
Length: 32m 59s
Link: https://podrocket.logrocket.com/slinkity

February 11th, 2022

JS Party: Episode #212 A deep-dive on Vite

Hosts: Amal Hussein, Nick Nisi
Guest: Evan You
Length: 01h 14m
Link: https://changelog.com/jsparty/212

February 9th, 2022

That’s my JAMstack: REMIX! Tamas Piros on islands architecture, Astro and media usage

Host: Bryan Robinson
Guest: Tamas Piros
Length: 28m 52s
Link: https://thatsmyjamstack.com/episodes/tamas-piros-remix/

February 9th, 2022

PodRocket: Modern React with Paige Niedringhaus

Host: Kate Trahan, Noel Minchow
Guest: Paige Niedringhaus
Length: 50m 00s
Link: https://podrocket.logrocket.com/modern-react

February 6th, 2022

Front End Happy Hour: TypeScript migration – Strict type of cocktails

Host: Ryan Burgess
Guests: Sumana Mohan, Joe King
Length: 48m 22s
Link: https://www.frontendhappyhour.com/episodes/typescript-migration-strict-type-of-cocktails/

February 4th, 2022

JS Party: Episode #211 A Solid option for building UIs

Hosts: Ryan Burgess, Jem Young, Stacy London
Guests: Sumana Mohan, Joe King
Length: 55m 00s
Link: https://changelog.com/jsparty/211

February 3rd, 2022

Console DevTools Podcast: Devtools investing

Host: David Mytton
Guest: Ed Sim
Length: 30m 38s
Link: https://console.dev/podcast/s02e05-devtools-investing-ed-sim-boldstart/

January

January 27th, 2022

JAMstack Radio: Ep. #95, Islands Architecture with Ben Holmes of Slinkity

Host: Brian Douglas
Guest: Ben Holmes
Length: 27m 58s
Link: https://www.heavybit.com/library/podcasts/jamstack-radio/ep-95-islands-architecture-with-ben-holmes-of-slinkity/

January 26th, 2022

PodRocket: MUI with Olivier Tassinari

Host: Ben Edelstein
Guest: Olivier Tassinari
Length: 31m 43s
Link: https://podrocket.logrocket.com/mui

January 25th, 2022

JavaScript Jabber: Virtual DOM and the React Way, Part Deux – JSJ 518

Hosts: Aimee Knight, AJ O’Neal, Dan Shappir, Steve Edwards
Length: 01h 32m
Link: https://javascriptjabber.com/virtual-dom-and-the-react-way-part-deux-jsj-518

January 21st, 2022

devtools.fm: Yang Zhang – Plasmic

Hosts: Andrew Lisowski, Justin Bennett
Guest: Yang Zhang
Length: 57m 04s
Link: https://devtools.fm/episode/22

January 18th, 2022

JavaScript Jabber: Can JAMstack do REAL Web Apps? with James Q Quick – JSJ 517

Host: AJ O’Neal, Charles Wood, Steve Edwards
Guest: James Q Quick
Length: 01h 20m
Link: https://javascriptjabber.com/can-jamstack-do-real-web-apps-jsj-517

January 12th, 2022

That’s my JAMstack: Raymond Camden (REMIX) on the amazing expansion of the Jamstack ecosystem and how far we’ve come

Host: Bryan Robinson
Guest: Raymond Camden
Length: 27m 31s
Link: https://thatsmyjamstack.com/episodes/raymond-camden-remix/

January 04th

That’s my JAMstack: Salma Alam-Naylor on shipping, learning, and rendering in the Jamstack

Host: Bryan Robinson
Guest: Salma Alam-Naylor
Length: 27m 59s
Link: https://thatsmyjamstack.com/episodes/salma-alam-naylor/

And if you’re missing one from the list, one you’ve enjoyed a lot, let me know on Twitter! Always happy to add another one to my subscriptions 🙂

Unlocking the frontend - a call for standardizing component APIs pt.1

Jonas Ulrich — Sat, 26 Mar 2022 19:46:09 +0000

#tldr We're still wasting massive amounts of valuable development cycles in the frontend world by working in silos, or by to at least some extent reinventing the wheel for every project. Results suffer in the process, impacting real world results for users and content creators alike.
How did we get here, and how could a way forward look like? How we've already come a long way, and why still (so far) even Jamstack hasn't been the sole answer, either...

So what's wrong?

This is something I've been thinking about for a while now.
Way back in the day, when you wanted to build a website or digital product, you built everything yourself. You had no choice, you had to! This began with defining models and relationships, adding logic on top of it to extract the correct data to display, and implementing actions that should be triggered upon user interaction. Typically mutating server state of some sort. And then, finally, you purpose-built your frontend accordingly, for those exact circumstances.

All in all, oftentimes a very interlocked process between all parties involved. Be it between software specification and backend development, design creation & specification and frontend development or frontend and backend development.
Changes of every kind typically being costly as a consequence, leading to everyone trying to over-spec even more... a vicious cycle of ultimately missed expectations

via Columbia on GIPHY

Classic architectures

We've moved away from this by adding frameworks and new, more flexible development approaches into the mix. Mostly adopting a Model-View-Controller (MVC) approach in the process, doing some domain driven design, and as a result agreeing to a way more manageable amount of shared best practices. This happened for almost every programming language (e.g. Symfony for PHP, Rails for Ruby, Express for Node.js, Spring for Java).

In combination with adopting more agile processes to structure our development, this enabled everyone to be more resilient to often changing requirements. Because changes could be made in a more predictable fashion, and were better aligned with real needs, the resulting positive feedback loop kept converging everyone to adopting those shared best practices, fostering further exchange and standardization. Often designed into the respective frameworks from the start, as plugins, extensions or addons. Associated marketplaces further incentivizing this.

What about websites?

In parallel those conventions took hold for website development, too. Instead of general purpose frameworks (like Rails), which were still to expensive as a basis for the often repeated customer needs, content management systems (CMS solutions like WordPress, TYPO3, Drupal) took that place.

Adding already established models, and thus a specific domain for content, to the open approach of working with "just" a MVC framework. This also enabled them to create much more tailored interfaces for editors working with said content, and layering additional functionality on top; as you just knew much more about what everyone was working with.

But you still had to fine-tune it for every customer to create a truly fitting editor experience, and the frontend still got painstakingly re-implemented with every major overhaul. Additionally you had to fit everyone into the same monolithic system, increasing complexity and cognitive overhead for all different types of editors involved (news, career, marketing, blog, internal communication, the list goes on, all with different editorial needs).

via GIPHY

The first wave of ecosystems for the web

Both ways of building web interfaces (website vs application, or custom vs CMS) succeeded in establishing flourishing ecosystems around their approaches, though, allowing developers to start exchanging real code instead of just ideas or framework best practices... getting more efficient in the process, while generally also creating better results. But you were still locked into that specific ecosystem, trying to build a monolithic jack-of-all-trades, even more so if your goal was to have a consistent experience over all the different brand touchpoints a user may encounter on his customer journey.

by kickstartDS

Emancipating the frontend

For websites, lately, this mental model has been challenged again by the notion of headless content mangement systems, and more generally speaking by completely detaching the frontend from the backend in an approach now often called the Jamstack (in comparison to the LAMP stack traditionally found in a CMS).

This decoupling enables establishing a shared contract between both sides, an API. Making teams working on them more independent of each other, while also increasing stability because everyone can test against it in isolation.

With generators (Gatsby, Next.js, 11ty) being a central part of the Jamstack approach, one additional super power that's unlocked by them is the possibility to use multiple sources to feed into one resulting interface or website. Ultimately mix-and-matching backend and API solutions into one consistent experience, with everyone using the tool most suited for his daily job. The marketing team may work with WordPress to create long form content and something like Storyblok to build engaging landing pages. The main website could be built with Sanity, or other structured content-oriented solutions, as the headless CMS to really leverage connected, long-lasting content where it matters. Even other data can be spliced into the mix by adding third-party APIs as needed.

Frontend frameworks like React embrace that way of working by optimizing for composability, while tech like GraphQL helps with enabling that same composability for APIs. In combination with a lot of SaaS offerings being API based, or at least supplying really rich, well documented APIs as par of their open source strategy, this unlocked a huge potential in the space for re-use, specialization and standardization. And I'm sure we've just started experiencing the paradigm shift associated with that!

But... where's my frontend ecosystem? 😓

Unfortunately though, we still often build frontends completely isolated from each other. Creating and reinventing one-off work that suffers as a consequence, because you just can't invest the time that's needed to make something really good (in regards to performance, accessibility, responsiveness, cross browser-compatibility) in the time allotted for such frontend work. All while additionally trying to stay on top of the current trends, and changes inside our own ecosystems because of the rapidly changing landscape.

Way too often still you're confronted with some form of digital design (be it Sketch, Figma or Adobe XD) on the one hand, and data structures that are the result of decisions that were made in your absence, when choosing and building the generator and APIs on the other hand. It's your job then to create a component from that, hopefully creating something re-usable, which is expected to be universally understood by everyone to be the same thing. And did you know that the same component is supposed to work on the blog, too? But it should look and behave slightly different? A thankless job at best.

Man stands face to face with the irrational. He feels within him his longing for happiness and for reason. The absurd is born of this confrontation between the human need and the unreasonable silence of the world.

Albert Camus, The Myth of Sisyphus and Other Essays

This all, unfortunately, still makes frontend development a pain. While valuable engineering time goes into chasing problems that have been solved a thousand times before. Often even by oneself, just two projects before the current one...

Why just creating a Design System is not the answer, either

For product teams tasked with starting a Design System today, this also way too often feels like just another added thing on top, that's expected to be delivered, en passant. Neglecting that for that to work the focus would have to shift dramatically, adjusting the way frontends are architected, and enabling frontend developers to realise the potential demanded from them. And also fulfill those Design System promises like "automatic" consistency, more efficient development cycles or magically aligned stakeholders.

There needs to be a better way to foster the same exchange, longevity and interchangeability between frontend developers and the results of their work! Unlocking the frontend potential, like it has already been unlocked for other parts of the products and pages we're building! In a world of Design Systems this also means letting the frontend somewhat dictate the rules of engaging with components more, in some places inverting the way we work today.

And the attentive reader could have already spotted: we haven't even really spoken about content strategy, connected content and the influence content creators and editors should have in those architectural decisions. Which for most just reflects the way digital interfaces are built today... with the people working with the resulting software unfortunately being an afterthought. And the results suffering in the process. Only in uniting all those stakeholders in the decision making process will the end result, a tangible page or application that is generating true value for both the user and the creator, be successful.

via Gilmore Girls on GIPHY

So what now?

What was behind every major evolution of the web in the past was people rallying around shared principles, doing something in a more coordinated and repeatable way. I'm pretty convinced that for the frontend this has to mean some kind of standardization. Standardizing the way components can be compared, the way they expect and consume data, and effective ways of mapping between all of those. I'll explore those thoughts in part 2, and try to showcase how we're trying to solve for this today inside kickstartDS, for our users. And maybe, just maybe, this could someday align with a greater approach to all of this, unlocking not only the true potential of something like kickstartDS, but the potential of the wider frontend development world.

How this has impacted our work over the last 15 years? How possible solutions to this could look like? And why we think to be having some potential answers at the core of kickstartDS, today?

Read more in part 2, very soon!

Also, hit me up on Twitter at @tsnmp to exchange ideas (or to tell me where I'm possibly getting it all wrong 😋). Would love to hear others takes on this!