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

#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!

Release Spotlight: Container Queries

Release Spotlight: Container Queries

#tldr: Container Queries are another new feature coming with the Open Source release of kickstartDS. It’s a proposed feature for CSS that allows the styling of elements to be based on the size of the container in which they are placed, rather than the size of whole browser frame. This is important for Design Systems because it allows for more flexibility and modularity in the design of components.

Setting up a working Design System in less than a day

In this post we demonstrate how kicking off a Design System, by applying tokens and adding some customization, can be done in under a day. In the process recreating the Sanity.io landing page, with its style and content, as a fully functional prototype based on the resulting components.

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

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…