svelte-headlessui VS svelte-it-will-scale

As a side note, my project was the first to be published under the name svelte-headlessui and is both more popular and more complete than the other project. I don't know why the other guy picked an identical name but it drives me a little nuts because of how unnecessarily confusing it is.

There is an unofficial Svelte port here but it doesn’t appear to be maintained so there may be a better option… that said there are a ton of better options if you want to use Tailwind with Svelte.

This and passing styles to slots, are biggest bottlenecks in wrapping components (your use case) and creating headless components (see headless ui).

Headless UI as in svelte-headlessui?

Svelte Headless UI should get some new PRs merged soon based on some comments u/ryangossiaux posted in the repo less than a week ago. He stepped away from the project for a bit after putting in a tremendous amount of work into it, and as someone who has used his library alongside Tailwinds UI on a number of projects, I’m super thankful for what he’s managed to do, and I hope that more people from the community will help support the project.

The component's come pre-styled. Styles can be overridden by tailwind classes, and here's a guide for that on the docs! If you want to use components that don't come pre-styled, I would suggest using something like Svelte Headless UI.

Just in case you haven't seen it, I ported Headless UI to Svelte recently: https://github.com/rgossiaux/svelte-headlessui

About two weeks into my first project I did purchase Tailwind UI. It is a massively useful resource, and I use it several times a week. It is a great reference tool, and is being actively added to. I have definitely recovered my initial investment in time saved. If you're using React or Vue, it is a no brainer - support if first class (along with Headless UI). I actually pivoted to SvelteKit, and started using the Tailwind UI HTML components until recently when this dropped: https://github.com/rgossiaux/svelte-headlessui. I now start with the React component.

That N is very large. E.g. here's a page that talks about it: https://github.com/halfnelson/svelte-it-will-scale. I'll note that was done with Svelte 3 and that with Svelte 4 components are at least 10% smaller, so it's actually even better than that. SvelteKit is also very efficient at JS splitting per-route thanks to Vite. It ensures only the JS that is necessary for a page is loaded and you're extremely unlikely to be using anywhere near that many components. Based on the article above, you'd have to have three entire sites worth of components on a single page.

Sure, performance (bundle size), performance/predictability, simplicity (blog post)

Finding Svelte's Inflection Point

yes am aware, but also in any realistic scenario, code splitting comes in well before the crossover point where that even remotely comes into question. this has been independently verified twice now:

https://twitter.com/sveltesociety/status/1301168598988107776...

https://svelte-scaling.acmion.com/

https://github.com/halfnelson/svelte-it-will-scale

sveltekit has further opportunities for whole-app optimization but honestly given this research i lost interest bc its more than good enough

Svelte lowers the initial size of your app, however the incremental cost of each component creates an inflection point, where the added size of each component exceeds the size of a pre-bundled framework. What actually matters is where this inflection point is. This experiment actually evaluates that https://github.com/halfnelson/svelte-it-will-scale. Essentially, you would need a project equivalent to four times the size of the svelte.dev website to reach this point.

Naturally, the first thing I want to do is put these to the test, but it would be anecdotal at best. The first thing that came to mind was the comparison of Svelte Component Scaling compared to React. Some sort of test to see how much difference a small library that ignored all this compared to a large library that didn't.