Hacker News Reader

Comment by cetra3 | Hacker News Reader

I've moved my little hobby website to SvelteKit[1] from react and I am not regretting it.. yet.

The only main frustrations I have are:

- Library support is pretty lousy. You need to fudge things around to get working. I.e, with leaflet and others I have vendored in the libs and redone them.

- Incremental static refresh with svelte kit is not really there. I'd like a web hook or api callback that allows me to refresh certain static pages as I know that changes are made. Right now I'm doing a janky refresh using a file lock notifier & it's a blemish on an otherwise great framework.

- The URL routing in svelte kit is... a little ugly. It's really hard when you have an editor open with 5 `+page.svelte` files. I wish they re-introduced file name routes, rather than folder name routes. It is entirely a personal preference I know, but I have seen a lot of negative things around it.

[1] - https://github.com/cetra3/divedb - deployed at https://divedb.net/

View on HN

Haven't had that refresh issue because I don't use that.

But I'm 100% with you on the routing. It's weird. One thing I had a lot of trouble was with "sub routing", like being in a route, opening a modal and having the url change so it can be linked to.

I had to implement some ugly workaround in the layout to catch hasthag # navigation.

Rich Harris demo'd an upcoming "shallow routing" feature a few weeks ago: https://youtu.be/HdkJTOTY-Js?t=419

around the 7:00 min mark

I know the routing isn't the easiest, but I find myself navigating with CTRL+P and typing the route I want to work on.

How would you otherwise navigate that you find difficult with SvelteKit?

Sorry, just saw the question, I don't really understand what you mean?

Library support is pretty lousy.

Next 13's app directory and React Server Components is killing library support in React, so that's not such a big problem.

What does that mean?

It means that library maintainers are having to make changes to their libraries to get them to work on the serverside, and a lot of them aren't not really doing that very quickly.Consequently moving to RSC reduces the number of libraries that work with your React code.

It's a short term problem because most popular libraries will get updated eventually, but some won't and they'll only ever work on the client side.

In the case of Next, maintainers need to package their libraries differently to support ESM modules, or you need to configure your project to use the experimental.esmModules=false flag. Again, it's not a particularly big problem but it does reduce the size of the available ecosystem a bit.

But that doesn’t mean React will /break/ existing libraries? It’s just a new feature that they need to start supporting, as you described.

Before, there was only client-side. Server-side is opt-in. So all the libraries you used client-side, you can still use client-side by using client-side components

I don’t know much about the former, but it’s not clear why React server components are going to kill library support.

Pretty much every library I have tried to use with Next App Router (and therefore RSC) doesn’t work with RSC. I’m sure it will change but we’ll be sticking for Next Pages for a while yet.

I think you may have missed that you can circumvent all of this by declaring your components to be client components.

What's the point of using RSC if you have to mark everything as client components?

At best you're getting SSR support since client components actually run on the sever as well, but there are already cleaner solutions for SSR react components that rehydrate in the browser.

You're not using RSC if you're marking everything as a client component. The point is that you can do that and continue to use your old components while also able to use the new app router infrastructure.

Is there that much benefit to just the file structure and router?

That feels like a ton of refactoring just to have the same and result for a user, but maybe I'm missing some important gains of the app directory.

> It's really hard when you have an editor open with 5 `+page.svelte` files.

+1. I've been pushed to change tabs using `Ctrl+P` instead (search tab command) and write its route (folder's name). But it's still a bit painful

Can you clarify how you would normally switch tabs and why that's difficult? If I open up a bunch of `+page.svelte` files I see them as "+page.svelte ../docs" or "+page.svelte ../blog" and so it's fairly obvious which one is which to me. Longer-term, I think we can tweak VS Code to get rid of the duplicate "+page.svelte" part as it is duplicative and unnecessary, but I don't find it unworkable at the moment. I'm wondering if it's simply that we have different tolerances for this or if there's something else going on in some cases.

Some people have mentioned liking to set the label format to short under File > Preferences > Settings and then search for Label Format.

Cool site!

I just looked through your repo. I'm still relatively new to SvelteKit and rewriting a similar content based site from React.

What led you to use the SSG adapter vs the node adapter (which uses SSR)?

How long does the build take to pre-render all of your content pages like the sea life?

Was there a particular reason you didn't want to use Form Actions?

Not criticizing your decisions by the way, I'm mostly just curious about the decisions others make to learn something myself :)

Thank you! I've tried to address your questions below. Most of these decisions stem from having the backend written in Rust, & using GraphQL. That decoupling in the end made it a lot easier to port from react.

- I am using a rust backend for the static files and didn't want NodeJS part of the request workflow. Most pages aren't changed all that much, like maybe once every few months & so having yet another service as part of the connection flow just adds resources/delay when it's not needed. It's a lot faster/easier/cacheable to serve a static file.

- The prerender doesn't take all that long, maybe a minute or so, it's fast enough for the site as it stands, but if it got super massive it'd be a different story. I throttle how often it happens currently, so that there is a bit of time between pre-renders.

- The frontend communicates to the backend via GraphQL & the backend is not part of svelte kit, it's an entirely separate service, and so things like `page.server.ts` won't apply.

Awesome thanks for getting back to me, all of those decisions make sense to me :)

Cheers

Giant +1 to everything being named “+page.svelte” being painful. It clashes with every dev environment I’ve tried (vim tabs, vs code).

I haven't had much trouble in VS Code since it shows the directory name just after the file name. Some people have mentioned liking to set the editor tab label format to short. Go to File > Preferences > Settings then search for Label Format.

I'm hoping https://github.com/microsoft/vscode/issues/41909 will get implemented so we can make the problem go away entirely

Reply on news.ycombinator.com