7 ms·
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 pr
by cetra3 3y ago
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 https://github.com/cetra3/divedb - deployed at https://divedb.net/ https://divedb.net/
- onion2k 3y agoLibrary 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.
- Kiro 3y agoWhat does that mean?
- onion2k 3y agoIt 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.
- reducesuffering 3y agoBefore, 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
- yunohn 3y agoBut that doesn’t mean React will /break/ existing libraries? It’s just a new feature that they need to start supporting, as you described.
- yunohn 3y agoI don’t know much about the former, but it’s not clear why React server components are going to kill library support.
- siquick 3y agoPretty 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.
- solarkraft 3y agoI think you may have missed that you can circumvent all of this by declaring your components to be client components.
- flagrant_taco 3y agoWhat'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.
- solarkraft 3y agoYou'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.
- flagrant_taco 3y agoIs 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.
- gl-prod 3y agoI know the routing isn't the easiest, but I find myself navigating with CTRL+P and typing the route I want to work on.
- madacol 3y ago> 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
- benmccann 3y agoCan 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.
- renatofontes 3y agoHaven'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.
- fortunateregard 3y agoRich Harris demo'd an upcoming "shallow routing" feature a few weeks ago: https://youtu.be/HdkJTOTY-Js?t=419 https://youtu.be/HdkJTOTY-Js?t=419 around the 7:00 min mark
- scosman 3y agoGiant +1 to everything being named “+page.svelte” being painful. It clashes with every dev environment I’ve tried (vim tabs, vs code).
- benmccann 3y agoI 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 https://github.com/microsoft/vscode/issues/41909 will get implemented so we can make the problem go away entirely
- nop_slide 3y agoCool 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 :)
- cetra3 3y agoThank 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.
- nop_slide 3y agoAwesome thanks for getting back to me, all of those decisions make sense to me :) Cheers