Restart development of v2

Quick Glance

Current v2 branch is partly broken
Unnecessary monorepo -- the ui package is empty
Design system doesn't match Svelte's
Acessibility concerns

Description

Given Svelte 5 was recently released, together with sv, I identified some discrepancies between recommended practices and practices used in the v2 branch.

[!NOTE] This is not a rant. It's just me questioning whether the current implementation is the best one for the users and developers. We can gladly move this conversation to Discussions or Discord if better suited, but I thought I'd make an issue because some things seemed a little inconsistent or out-of-date to me.

The new `sv` CLI

Database

sv introduces the possibility to quicky add drizzle, which helps defining data structures, initializing the schema and some more useful things. My suggestion would be to use drizzle for database management. Database Management is also where the v2 branch is broken: db:init throws an invalid syntax error (even though the database seems to be initialized without any problems). Another problem is inconsistent naming. The schema specifies a content table which is later refered to as published_content, causing multiple errors. Drizzle would drastically reduce mistakes like this.

User Authentication

sv introduces the possibility to quickly add lucia, but I don't know if the lucia implementation is better or worse than the implementation used in v2. The code of the v2 implementation was not reviewed or tested, so I can't really tell.

Internationalization

sv introduces the possibility to quickly add paraglide, which would add the option of translating sveltesociety.dev, making it available for more people. I recommend adding i18n, but since svelte.dev isn't translated either, this is just a suggestion.

Why the monorepo?

The v2 branch is currently structured like this:

- nginx        (Reverse proxy config)
- packages
  - ui         (SvelteKit library project)
- sites
  - www        (SvelteKit website project)

This is great if you want to manage multiple packages or sites in a monorepo. But why do it for sveltesociety.dev? I mean, yeah, you could put all of your ui stuff in the ui package to keep your www site clean. But that hasn't happened here. The ui package does not seem to contain anything (nor is it included as a dep in www), and there also aren't multiple packages or sites, making the monorepo structure seem unnecessary. So what are other reasons one might still want to structure the repo like this? Well, if somebody wants to use sveltesociety.dev UI components in their personal projects, this structure would certainly make it easier. But since the ui package is empty, you can't do that.

So my suggestion would be to either use the monorepo structure, or to switch to a classic single-project repo structure instead.

Design System and Brand Identity

Style Mismatch

Both the old (current) sveltesociety.dev and new v2 sites use a design system that greatly differs from the design system used on svelte.dev. Yes, Svelte and Svelte Society are two different things. But are they, really? Let's see:

	Svelte	Svelte Society
Community-ran	yes	yes
References community packages	yes	yes
Contains documentation	yes	yes (recipies)
Contains tutorials	yes	yes (resources, but only links)
Contains a playground	yes	no
Contains a blog / feed	yes	kinda (`v2`)
Contains events	no (mentions Svelte Society)	yes
Official annoucement channel	yes	yes

So does it really make sense to split up Svelte and Svelte Society? Yes! Svelte Society is the community, and Svelte is the product. That's not the same thing and it's important to distinguish between that. But does Svelte Society need a completely different brand identity? I don't think so, especially because Svelte Society also serves official purposes apart from community purposes (Svelte Summit for example).

Accessibility

Some minor accessibility concern at first glance: The sidebar links have a smaller height than the WCAG recommended minimum of 44px. Also the sidebar section titles might be hard to read for some people due to the combination of light font weight and the text color used. I've also noticed some issues regarding keyboard navigation. Since one of Svelte's main goal is to make the web accessible, it would be weird if Svelte Society didn't have the same standards.

Conclusion

While it's cetainly possible to continue development on v2 the way it currently is, it might be helpful to make a clean restart of the development and put new technologies into use. Also, since Svelte Society is very tighly related to Svelte, I think the design of the website should represent this relation.

[!NOTE] I'm eager to help support the development to make Svelte Society better for everyone.

svelte-society / sveltesociety.dev