Skeleton as a zip file instead of a library

[ocluf]

I recently watched the keynote from Tailwind Connect and I thought their vision for their Catalyst components was really interesting. Instead of importing them as a library you download a zip file into your project and customise the components there as you want.

For example currently when I want to make some arbitrary styling changes to a simple component like the Appbar I currently go into the components type definition, see what component prop I need, and then go back and add my overriding class.
Not only that but if I want to keep the styling consistent I need to add those props to all instances of the component.

Instead of adding a padding prop of p-5 everywhere which overrides the p-4 styling I'd much rather command + N directly the component and directly change the 4 to a 5. And if I would need variability add it myself later. It would also simplify a lot you could remove the entire script tag of the Appbar component.

Anyways I thought I was an interesting concept. Of course there are lots of downsides as well like ease of install and releasing patches. Thank you for all your work on this great library

[endigo9740]

Hey @ocluf

I recently watched the keynote from Tailwind Connect and I thought their vision for their Catalyst components was really interesting. Instead of importing them as a library you download a zip file into your project and customise the components there as you want.

Buckle in, you may be triggering a small rant from me here :)

Development in general, not just web development, moved away from this approach of everything being zips a long time ago, and for good reason, it's really poor in practice. Sure it's simple to get started, but what happens the moment you need an update from upstream? It's not available because you have no package manager to update your dependencies. You have to manually update and reimplement every single detail yourself. It's incredibly painful. Trust me, I'm old as shit and lived through that era of web dev.

I have no doubts that Adam is a smart guy and he is well intentioned, but having maintained a large UI library on top of Tailwind for the last year plus, this puts into perspective misconceptions I believe he has. Some of which has actually had a fairly detrimental effect on Skeleton.

That being that Tailwind is horrible at supporting components and features built using Tailwind, served from a third party source. The reason for this actually not an NPM issue, it's a Tailwind compiler issue. Their compiler assumes that any files it has access to through your Tailwind Config > Content Config settings is actively being used by the project. Obviously this is misguided, as you may only be used some portions of the third party library (component A and B, but not component C). However, given the way the compiler searches through these files, it will automatically assume you're using ALL components found (A, B, and C) and bundle the Tailwind classes found within each of those into your final CSS bundle.

The result is exactly what you might expect - it inflates you final stylesheet with styles for features you're not actively using in your project. We identified this fairly early into building Skeleton, and one of our wonderful maintainers @AdrianGonz97, has been working his ass off to build a solution for this. In simple terms, a Vite plugin that tree shakes the stylesheet to only include styles actively used within your final build of your project. This will launch soon and be an official recommendation from Skeleton.

You might be asking yourself, why doesn't Tailwind just do that? It's the same question we've been asking ourselves for a while. And this short clip of Adam is a bit of a revelation in that regard. It makes clear that he doesn't either:

1. Understand what package managers are, or how they benefit developers
2. For some reason he's adverse to package managers in general

Unfortunately the end result here is a bit of an ideological split. Developers have established paradigms and conventions that work, and Adam is trying to split from that...why? I have no idea. But needless to say Skeleton will never go down this route of returning to tons of zips the user has to self manage. We don't hate you (the end user) and would never put you through that kind of torture.

For example currently when I want to make some arbitrary styling changes to a simple component like the Appbar I currently go into the components type definition, see what component prop I need, and then go back and add my overriding class.
Not only that but if I want to keep the styling consistent I need to add those props to all instances of the component.

Instead of adding a padding prop of p-5 everywhere which overrides the p-4 styling I'd much rather command + N directly the component and directly change the 4 to a 5. And if I would need variability add it myself later. It would also simplify a lot you could remove the entire script tag of the Appbar component.

Keep in mind Skeleton is open source, you ALWAYS have this option - which is to say, you can clone any component or other feature found within Skeleton to your own local project, and modify to your hearts delight. It's not as simple as a zip file, but given we're using Svelte, it typically involves copying only 1-2 files.

I would also say that perhaps you're taking the wrong approach if you think you can only customize components using props. We have a whole section covering customizations via CSS handled in your global app.postcss. Not only are these simple to implement, but it keeps you using the version of the component that will continue to receive updates as we push them out.

https://www.skeleton.dev/docs/styling

Finally, I do have some future plans for making it easier to override the defaults in a global fashion through JS. Though right now that's just loose ideas. But honestly it sounds like you're making things MUCH tougher for yourself than you have to! Definitely give that link above a look please.

[ocluf]

Hey @endigo9740

Those points make a lot of sense. Thank you for all your hard work! every new project since I discovered this UI library has been using Skeleton dev.

[endigo9740]

Glad to help. And thanks for raising the question all the same!