Discussing the potential of a library like this

Hi Nikolai, great work setting up this library!

The community definitely deserves a utility library like this, and to me it seems like the obvious solution for "extending" the behaviour of Svelte. Here's a couple of reasons why i believe a library like this is a good idea:

The Svelte API is by design as lean and extensible as possible - so the framework will never be filled with tons of utility functions.
It follows the philosophy of having as few dependencies as possible. 1 big utility library with no other dependencies > 10+ small utility libraries with no other dependencies
A lot of people will end up writing the same utility functions just to avoid installing other packages. I have a hypothesis that people will eventually get bored of this, and developers will begin looking after libraries that deliver solutions to this, e.g svelteui

Making an open source project popular is no easy job, and it requires a lot of marketing work. The code obviously has to be well written, but looking at the source code i have no doubt that this will be a problem. However, there are a couple of issues that I'd like to address:

The docs. I'm not sure if this is the place to be experimental and create something "completely new". The docs page is cool and all, but users don't want a funky docs page. They want something familiar, easy to navigate and dead-simple to use. Search-functionality is also a must.
The name/branding. This may just be a personal preference, but i feel like svelte libraries that try to integrate the "sv" prefix into their names sound a little corny. Even Rich Harris himself does not do this. A good open source project needs its own brand, and should tell its own story. The readme is important here.
Personal vs organisation. There is nothing wrong with this project being on your personal account, but I believe that others are more likely to engage the project if they work for an organisation instead of a person. This also makes it easier to develop other tools in the organisation and expand if necessary.
Other stuff for scaling; changelogs, pr-templates, issue-templates etc. Not the most important stuff in the beginning, but getting these right is a big, big plus.

The job you've done here is amazing Nikolai, you should be proud! You've caught my attention, and i have a feeling this can be the start of something great for the community!

Hi Mathias,

First of all, I'm honoured that you've taken the time to write such a long and detailed post and have not only voiced (in most cases very valid) critique but also ideas for improvement. Thank you so much!

I'm very glad that you think this is a good idea, and to your 'plus' points I can only say thank you. I have glanced over SvelteUI before and it seems to operate tangentially to this space, though it seems that svu differs in one major point: It appears that SvelteUI is primarily an (opinionated) UI framework that also contains utilities. My idea for svu is to collect utilities only, and leave any sort of styling up to the consumer. They also seem to take a more vue-like approach that requires many utilities to be initialised with an object reference which I personally don't find great DX.

I have thought of maybe adding some completely unstyled components that would handle things like a11y only (think of modals or toast notifications), but this is just a vague idea, and 1. I'm not sure if it's a good idea, and 2. even IF it's a good idea, it would be dead last on my priority list.

Then on to your critiques:

I would like to state that in it's current form svu is in a very alpha state. I've mainly collected stuff I've used before in projects together and added a few things here and there. I've published it in it's current form to collect feedback and see if there's any merit to this idea at all. Fortunately after posting it to the Discord yesterday and the subreddit today the initial reception has been very positive.

So many of your points are a matter of "I didn't want my initial tryout to be too perfect, with the risk of later discovering I've been polishing a turd all along.

re: organisation: Your completely right. Moving to an organisation is a no-brainer.
re: other stuff for scaling: Same! One example: I only realised after I posted the project that I forgot to add a license, so I that's only be added today. There's a changelog in the docs, but adding one to the repo (preferably auto-generated from a single source of truth) would be nice. You have the honour of being the first person to open an issue that is not me! But these things are all definitely on my radar.
re: docs: Similar to the above. In it's current form the docs are a first draft. They are currently a simple mdsvex-file per svu with some styling. If it turned out this would end up as a just-for-me project, this would be more than enough, but I already have an idea for a redesign and a list of improvements in #1. One thing that I explicitly have in mind is that the docs should be a showcase for the actions they promote.
re:name: I saved this one for last, since there's no arguing about taste 😅 I personally don't mind the sv- prefix. In any case the rationale on settling for svu is as follows: It's a short, relatively pronounceable ('svoo'), and easy to type name that gives an idea of what the package is about: [sv]elte [u]tilities. It also had a free npm package name (so we don't have to require anything like import from '@svu/svu'.

Again, thank you so much for your kind words and criticism!

Please voice any further ideas or concerns. It's greatly appericiated!

Thank you for taking the time to answer! I appreciate your openness and the way you reason about the points I listed!

I totally understand the "I didn't want my initial tryout to be too perfect, with the risk of later discovering I've been polishing a turd all along" approach. The project has a lot of potential, and is already beginning to get in the phase of becoming a beta, so it feels like discussing these points can become relevant soon!

I support the idea of not making this another opinionated UI-framework, but keeping it at a utility level. Personally i feel like this approach has a lot of potential, the same way that TailwindCSS revolutionised the CSS echo-system by being a great "utility-first CSS framework". Imagine delivering something like Tailwind for Svelte/JS!

I know that Vue has the concept of Custom Directives, so there are probably a lot of mature projects that can be taken inspiration from.

One thing i want to discuss is slot props. Svelte supports this, but i rarely see it in the wild. One of the components in our company component-library is a "FocusWithin" component, which lets you run JS code on focus-within:

<!-- Creates a fake progress that feels natural and will never reach 100 -->
<FakeProgress let:progress>
    <progress max="100" value={progress}> {progress}% </progress>
</FakeProgress>

These utility components can often come in handy when you don't have an easy way to use an action, e.g. because you only have Svelte-components in your markup.

I am not sure what your vision is with this project, so i want to ask you what you have in mind for the future and what your priorities are. I am interested in supporting this project, I see a lot of potential, and there are a lot of paths to take. I have written a fully fletched close-sourced component library for the company i work in, so i experience from a lot of interesting cases, e.g. writing a complete positioning engine in Svelte.

Lastly i want to say that the name "svu" is probably the cleanest "svelty"-library name i've seen yet. Not saying i love it, but it's okay. I'm just having a hard time adopting this name trend, but I won't let that get in the way 😂

Great to hear that the approach resonates, and even the name gets something resembling a pass 😜

Great ideas on taking inspiration from the Custom Directives. Slot props are an interesting concept, and as you can see there's already one utility component with , so I'm definitely not against that idea.

I've thought about adding actions to components before. I've been deliberating an action that would allow to forward a collection of actions to a component, but I'm not yet sure on the ergonomics of that approach.

Currently it's clear that I've got to figure out how to best take things forward. I don't yet have a great master-plan in mind 😅 I'm super positively surprised by the initial reception.

I think in general the initial work would be on bullet-proofing the current feature set, getting a sustainable project in place (create an organisation etc.) and develop the docs. While on the other hand sketching out a clear path to a 1.0 release. Now is a great time to flesh out the API and there is now still a chance to make any radical changes (if required).

I am definitely open for a collaboration of some kind, and especially if you're interested to help chiseling out things at this early stage I'd be more than happy accepting any form of support (even if only through these kind of discussions). I realise that already being able to discuss this with someone who sees the same potential is extremely helpful in clearing up my own mind about this.

Sounds good! I have no problem collaborating via issues and PR's. A couple of things that i would suggest to look at:

Creating a roadmap for the project
Getting tests setup asap

Great to hear that you appreciate the collaboration, this makes me excited!

Awesome!! I have time again to work on this tomorrow after finishing some client work, will start by sketching out a roadmap 🙂

nikolai-cc / svu

Discussing the potential of a library like this #5