Skeleton Next - Update 11 - Sneak Peak of Zag.js Integration

[endigo9740]

Hey everyone, Chris here from Skeleton! It's been a while since our last progress update, but I wanted to showcase some big changes coming to components in Skeleton v3. As you might expect, it it turns out building and maintaining components for multiple frameworks is hard. This poses a number of both technical and logistical challenges. In fact we've been faced with many of these pain points:

• We've been forced to repeatedly implement features using slightly different tool sets
• Had to utilize different mechanics for maintaining state within each framework
• Experience issues maintaining consistent roles and attributes related to accessibility
• Required lots of extra boilerplate for common keyboard interactions

The team and I have been researching the best way to overcome these issues, and thankfully we think we may have found our solution in Zag.js - an open source framework created by the same team behind Chakra UI. Like Skeleton, the Chakra team appears to have experience many of these same issues, which motivated them to introduce Zag.

What is Zag?

In simple terms, you might compare Zag to tools like Melt UI for Svelte or Radix UI for React. These provide primitive abstractions for generating the underlying structure for components - including logic and state management for common patterns such as Accordions, Tabs, Switches, and more. The result is headless components that can then utilize your own custom design system. In this case, that's the role of Skeleton!

What makes Zag unique is that it is framework agnostic, providing wrappers for popular frameworks such as React, Vue, and Solid.js. As well as pending support for Svelte, which is awaiting a stable v5 release.

The Benefits

Rather than reinventing the wheel, Skeleton can lean into Zag to generate the foundation for our suite of components. This provides a number of other benefits out of the box:

1. Consistent APIs and feature sets for all framework components
2. All components can fully adhere to WCAG standards
3. Battle tested accessibility and keyboard interaction per each component
4. A wide selection of component patterns to draw from, including features we may not support otherwise
5. As well as faster turn around for new components, since the "hard parts" are solved for us

Skeleton essentially delegates the logic and state management to Zag, while focusing purely on what makes our components unique and special - integration with the Skeleton design system, support for Tailwind styling, as well as a few Skeleton-specific features sprinkled on top.

Integration Preview

Over the past week, the team and I have created an internal prototype to test Zag integration. We've been very pleased with the results. You can review updates to the component code, and preview a few examples below:

NOTE: this is an active branch and will continue to improve over the next couple weeks.

• Pull Request: NEXT: Update components to use Zag.js #2778
• Accordion preview
• Avatar preview
• Switch preview

Not only is Zag quick to implement, but we've managed to provide more features and better accessibility, all with less code. This helps boost confidence that we retain API, feature, and a11y parity cross-framework. Especially since everything draws from a single source of truth - Zag.

Breaking Changes

In the short term, expect breaking changes to our existing v3 components as we migrate to Zag. This will occur naturally as we update our props and feature set to conform to Zag's standards. However once complete, our component APIs should remain much more stable. Especially for new components.

What's Next?

The good news is the team and I have already started migrating our components to utilize Zag. It's worth noting that Zag does not provide parity with every Skeleton component (App Bar and Navigation for example). However, those outliers will continue to use our standard component paradigms going forward.

Once this process is complete, we'll continue implementing all planned components, with the goal of reaching v2 parity as soon as possible. Over time (likely post-launch) you may also begin to see some really new and unique components introduced, such as QR Codes, Splitters, Timers, and more.

Zag also introduces a more streamlined path for introducing support for additional frameworks like Vue and Solid.js. This will likely come alongside major releases in the future (Skeleton v4.x and beyond).

Feedback

As always, if you have questions or feedback, we encourage you to leave a comment below.

[stalkerg]

I don't like this idea. This way with spread all params can kill Svelte optimisations.
Svelte is still a compiler and now we are starting to cheat.

[endigo9740]

Hey @stalkerg,

This way with spread all params can kill Svelte optimisations.

I'm not sure what you're referring to here. The internal component implementation does spread attributes, but this should not have any affect on performance (if that's what you mean by optimization). Likewise this is not what you, the user, would ever interface with directly.

Externally the component APIs should remain nearly 1:1. In fact, we shared three example of Skeleton components that currently implement Zag. I'd recommend you open these, tap the "Code" tab for each, and preview what you would actually be using:

• Accordion preview
• Avatar preview
• Switch preview

Take the Accordion for example. Just simple attribute-style props like any prior version of Skeleton:

<Accordion value={someArray} multiple collapsible>
    <Accordion.Item value="club">...</Accordion.Item>
    <!-- ... -->
</Accordion>

Really the most notable changes are the benefits you get from this - first you get a new feature called collapsible. This allows you to toggle the currently open item open/close on demand. Additionally there's a number of non-visible improvements, such as ARIA roles and keyboard interaction. If you tab focus an item, you can now use up/down and home/end to navigate. These all come turnkey from Zag.

[stalkerg]

Thanks for the answer. Yes, I am not worry about end user experience, it should be great as usual in Skeleton, I am worry about performance.
I can be wrong about real effect but if you just update attribute it use this function: https://github.com/sveltejs/svelte/blob/svelte-4/packages/svelte/src/runtime/internal/dom.js#L419
but for spread it uses https://github.com/sveltejs/svelte/blob/svelte-4/packages/svelte/src/runtime/internal/dom.js#L437

it's not here yet, but we discussed to add more static analyze into Svelte and improve optimizations, maybe it's not a case anymore.

[Hugos68]

@stalkerg Hey, although we appreciate your worries, spreading attributes once and then updating them whenever something happens on user interaction is incredibly lightweight. The performance "dip" you're talking about would only matter if we would repeatedly update the dom thousands of time per second. Which doesn't happen. The attributes only get changed when the user interacts with the components. On top of that, the amount of features Zag's provide is unmatched. Think about every keyboard interaction, every click, every role attribute, every aria attribute and doing this across multiple frameworks. It's simply not doable to manage this yourself and have time to build other features. Trust me, we've tried to do it ourselves at the start of V3 but the feature creep of a11y quickly began to rise.

[endigo9740]

Thanks for clarifying @stalkerg, yeah hey we're in the same boat. We care about performance as well. If things aren't meeting our standards then we'll certainly evaluate our options. But so far all of our testing has more than met our expectations. Plus as Hugo mentioned the number of benefits we get from this cannot be understated when it comes to things like accessibility, which has been a top priority for Skeleton since day one.

I would encourage you to review the demos on Zag's site, as well as Ark UI. This is a component library created by the folks from Chakra/Zag. One of the maintainers from either project responded below and mentioned it serves as their showcase for what Zag can do. It's likely a great example of what level of performance you should be able to expect.

[richardvanbergen]

My experience with Finite state machines has not been a positive one, I hope you have better luck building on Zag.

[endigo9740]

Thanks for the input Richard, but it may be more helpful if you share some specifics. Remember that Skeleton is open source and we share these sorts of announcements early into the process so the community has a chance to chime in and provide feedback. If you think there's a better way to solve the problems Zag is fulfilling here, we're all ears.

[richardvanbergen]

We use XState at my work (or rather it's still lingering in our codebase) and debugging is an absolute nightmare. So many levels of indirection for very simple operations.

That said I do trust you guys did your research and I also understand that legacy application code shouldn't be the only yard stick I measure the worth of a concept by. I would be interested to see how it works out. In particular I understand the benefit of something akin to Radix UI to base everything else off. I'm just a little triggered by the term "finite state machine" in relation to client side state.

[Hugos68]

Just to clarify @richardvanbergen. We don't use state machine's, we only use the props that Zag provides and spread them. All the underlying logic is done through state machines but we don't have control over it nor do we care, it's merely an implementation detail on Zag's side.

[endigo9740]

Thanks for explaining Richard. As Hugo mentioned, the state machines in this case are not anything you or even we as contributors will really interface with directly. That's just how things are operating under the hood. In fact our interaction with Zag is fairly minimal. It's like you said, we'll use it more like Radix - but in a framework agnostic manner.

I also think that our components likely represent a valid use case for finite state machines. UI components, by their nature, tend to have a limited set of state. The Zag team does a great job of illustrating this here:
https://zagjs.com/overview/whats-a-machine

That said, I can empathize with being bit before. Sometimes we get stuck with tech that isn't really the right tool for the job, and that can leave a bad taste in our mouth. It's still early days, but I've yet to experience anything like that with Zag.

If you do have any follow up concerns regarding Zag's approach to this, I can at least vouch for the fact their very open and easy to communicate with. In fact one of the maintainers reached out in the comment below. I'd encourage you to reach out and they can likely explain their motivations, which is always better to hear straight from the source!

[cschroeter]

@endigo9740

Hey Chris 👋, nice to meet you. I'm also Chris, maintainer of Zag.js and Ark UI. It's awesome to see you considering Zag.js as the backbone for Skeleton.

Given your roadmap to support multiple frameworks, I recommend looking into Ark UI. It acts as a superset of Zag.js, embracing framework-specific improvements like the use of Context and Providers, and adding other helpful components not based on Zag.js. You might notice that @ark-ui/svelte is currently an empty package—we're waiting for a more stable Svelte v5 and could use some help building this package.

We initially considered using Zag.js directly in Chakra UI but found it too tedious to implement. While this might sound vague, you'll understand better when you compare Ark UI to Zag.js.

Nonetheless, I’m excited to see what you build with the toolchain. Have a great day!

[endigo9740]

Hey Chris, that's awesome. Yeah we've been scoping out Ark as well - which also looks great! I'm sure it'll provide a very helpful reference for us.

You might notice that @ark-ui/svelte is currently an empty package—we're waiting for a more stable Svelte v5 and could use some help building this package.

I think a lot of folks are waiting for v5 to hit stable, including us. It'll definitely affect our window for launch. But here's to hoping it comes soon.

Likewise great to make the introduction and please do reach out any time. We'll be heads down on porting our existing components to use Zag over the next couple weeks, so you may see us pop up here or there with questions, etc.

[AxelBriche]

The more I read about Skeleton Next, the more I get the impression that we're moving away from Svelte and adapting a lot of services and complexity to embrace the React world at the expense of what made Skeleton successful, simplicity.

[Sarenor]

While I can understand how you came to that opinion, I have to disagree with it. If we'd have stuck with "just Svelte" for v3, it'd be highly likely that we'd have used Melt under the hood, which is basically just Zag for only Svelte.

In regards to simplicity, that's still the goal. It shouldn't matter to you as the end user what the library relies on, as long as you still get turnkey themed components with simple but customizable props, which is still the goal for Skeleton v3.
Just with even more theme options and some other goodies thrown in :)

[endigo9740]

@AxelBriche unfortunately that could not be further from the truth. We're rewriting every single Svelte component to utilize Svelte 5, the newest version of Svelte. This takes full advantage of Runes, Snippets, and all other component API changes that come from this update. In fact, one of the coolest additions to Svelte 5 is that it now enables for this attribute spreading technique, which opens the door for Zag. Something that was not possible for Svelte 4.

Additionally, if you're looking at Skeleton as a Svelte-only library, then you may be misunderstanding what makes it unique. If anything, Skeleton is design system built around Tailwind. The heart and core of the library is our Tailwind plugin and all the features it brings to the table, including: themes, utility classes, a Tailwind components (buttons, badges, form element styles, etc). We then pair that with our functional Svelte components that directly integrate our design system.

This is not even taking into account the vast amount of improvements to the components themselves, including the new approach to style props, the new features each component will have, and the variety of brand new components we'll now be able to introduce over time.

Not to mention the fact we've started a brand new open source Svelte project to help expand Popover features for not only Skeleton, but the entire Svelte ecosystem. See Floating UI Svelte if you haven't already:
https://floating-ui-svelte.vercel.app/

Also remember Skeleton is open source. You can take a look at everything we're doing with Svelte directly in the source:
https://github.com/skeletonlabs/skeleton/tree/next/packages/skeleton-svelte

[MLNW]

If anything, Skeleton is design system built around Tailwind. The heart and core of the library is our Tailwind plugin and all the features it brings to the table

This is also how I see Skeleton as well. Recently I started dabbling with Astro and Tailwind to create some (mostly) static web pages. Would it be possible to use Skeleton in this context? I miss the simplicity of using existing components and the easily changeable themes but I value Astro for being so focused on static content with the possibility to add dynamic content with different frameworks if necessary. I know that in the past you explicitly supported Astro but at some point removed it. Based on the quote above it sounds to me like it should be possible to use (at least parts of) Skeleton in Astro?

[Hugos68]

Based on the quote above it sounds to me like it should be possible to use (at least parts of) Skeleton in Astro?

What do you mean with Skeleton? In V3 we will have:

• skeleton: The TailwindCSS plugin, which can run anywhere where TailwindCSS can run
• skeleton-react: A component library that integrates the skeleton design system with accessible turnkey components for React.
• skeleton-svelte: A component library that integrates the skeleton design system with accessible turnkey components for Svelte.

All of these 3 libraries are completely compatible with Astro (In fact, our documentation website, which consumes all these libraries is build with Astro!
Just note that you need the corresponding @astrojs/<framework> integration to support rendering specific <framework> components. For now that will be React and Svelte but we aim to expand the amount of frameworks we support in the future.

TL;DR: Yes, you can use Astro with Skeleton

[endigo9740]

@MLNW to expand on Hugo's post a bit.

The v3 core will 100% be compatible with Astro. This includes anything provided by our Tailwind plugin:
https://next.skeleton.dev/docs/get-started/plugin

As for components, they will be compatible-ish. And I say it like that because while React, Svelte, and others technically work within Astro-land, there are limitations to what it can do. Features like slots are really hit or miss. React requires and experimental flag, and Svelte 5 snippets are a no-go right now. That will hopefully change in the future though.

What this means it it does limit you to more presentational components, or only components with simple usage of React children and React.Node props. We work around this in our doc site by cheating a little bit. We create wrapping "preview" components that put the components in their own native environment. React components inside or React-land, Svelte inside of Svelte-land.

Per Astro support itself, we mentioned when we added the SvelteKit and Next.js install guides that more would be coming. Astro is part of that list. The limiting factor right now is basically just time. We're busy working on components and will return to generate the setup guide closer to launch. This of course will cover the caveats mentioned above!