You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
The text was updated successfully, but these errors were encountered:
Quick Glance
v2
branch is partly brokenui
package is emptyDescription
Given Svelte 5 was recently released, together with
sv
, I identified some discrepancies between recommended practices and practices used in thev2
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
CLIDatabase
sv
introduces the possibility to quicky adddrizzle
, which helps defining data structures, initializing the schema and some more useful things. My suggestion would be to usedrizzle
for database management. Database Management is also where thev2
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 acontent
table which is later refered to aspublished_content
, causing multiple errors. Drizzle would drastically reduce mistakes like this.User Authentication
sv
introduces the possibility to quickly addlucia
, but I don't know if thelucia
implementation is better or worse than the implementation used inv2
. The code of thev2
implementation was not reviewed or tested, so I can't really tell.Internationalization
sv
introduces the possibility to quickly addparaglide
, which would add the option of translatingsveltesociety.dev
, making it available for more people. I recommend adding i18n, but sincesvelte.dev
isn't translated either, this is just a suggestion.Why the monorepo?
The
v2
branch is currently structured like this: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 theui
package to keep yourwww
site clean. But that hasn't happened here. Theui
package does not seem to contain anything (nor is it included as a dep inwww
), 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 theui
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 newv2
sites use a design system that greatly differs from the design system used onsvelte.dev
. Yes, Svelte and Svelte Society are two different things. But are they, really? Let's see:v2
)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.
The text was updated successfully, but these errors were encountered: