Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Restart development of v2 #700

Open
Wombosvideo opened this issue Oct 25, 2024 · 1 comment
Open

Restart development of v2 #700

Wombosvideo opened this issue Oct 25, 2024 · 1 comment
Labels

Comments

@Wombosvideo
Copy link

Wombosvideo commented Oct 25, 2024

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.

@Wombosvideo
Copy link
Author

BTW, I am opening an issue on v2 because I didn't like the user experience of v1, wanted to contribute, and then saw you were already working on v2.

@MacFJA MacFJA added the 2.0 label Nov 3, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants