The Svelte Ecosystem Misconception
One of the most common concerns and complaints I get about Spelt is that it doesn't have the same ecosystem that React does. React has tons of amazing packages for everything you could ever want to do. And Spelt just doesn't have that, which makes it a less supported framework, a riskier bet, and not something that you would ever want to seriously use. And I sort of believe that when I first started working with Spelt, I genuinely do not believe that at all anymore.
We have a couple of like really really good libraries that handle basically everything you could ever need to do with like Runed that has a ton of really useful like utilities and functions and stuff that I'm about to go talk about with Shadcn Svelte, our Shadcn alternative. While we might not have a D3 for spelt package the way you would for react or you might not have like a markdown rendering package that's really good for spelt or whatever like whatever random thing you need.
The reality is raw normal JS stuff and raw normal HTML stuff can actually work really really well in this framework.
Introducing Runed: URL State Management
This library is called Runed. It is something that I've kind of been eyeing for a little while here, but I didn't actually try until recently, and I have absolutely been missing out. It's a bunch of really nice extensions on top of the Svelte 5 reactivity of runes that give you things like useSearchParams. They give you like a really nice way for working with context. They give you a bunch of really cool things with like elements to check, you know, your scroll state or get the dimensions of an element or check whether or not the user's idle or if a document is visible. All these little things that you've probably ended up handwriting yourself that are just like one-off utilities that are super super useful. They just have built in.
And I wanted to talk about this because I've been using it really heavily in Pick Thing 2.0 where like if you notice when I'm on the assets page here and I toggle hide background, the URL updates to have removeBG be true. And then like I could add in a filter here where it's only images. And then I could maybe change the sort direction here to be ascending or whatever. And now I have this like filter system built out in the URL. And you'll notice what I can do is like I can just copy this URL, go over to my other browser, paste it in, and I'm still signed in and instantly I will get the same exact permutation of the assets page right here because the state is stored in the URL, which is where it almost certainly should be stored.
The way it works is you just define like a schema for what your URL search params will be. So in this case, it's like page and filter and sort. And then in order to use these, they just end up basically being state variables. You create your params object and then you can access them via derived. You can update them with the update function or just directly setting them. You can see the code for this in the asset store where I have my search param schema and then I have my search params right here by passing in the schema. The filters are based on this derived. Like all of this stuff just kind of works for me out of the box. It's super super convenient.
Why Explicit Dependencies Are Good: The watch Utility
One of the things that I was like the most hyped about when I saw Svelte 5 was that the effect rune didn't have a dependency array. I never liked the dependency array on useEffect in React and I have since learned that I was stupid and wrong about this. Explicit dependency arrays are good because in the trivial case it doesn't matter. It's just an annoyance to type in like the two variables that your effect obviously depends on. But when you have like really big complicated objects and stuff like nested arrays, nested objects that you just inevitably will have when you're working with complex client side apps, it gets really tricky to know exactly what the effect is being triggered by. And you can end up with some crazy foot guns in there that I really don't like. But they have this watch utility which is just a little function that pretty much just gives you a useEffect in Svelte where whenever any of these filters or sort direction change, it will clear the selection.
So like when I'm in here, if I select these three guys or whatever and then I change my sort direction, those will automatically get deselected just because the edge cases on that get really hellish, especially since I'm using indexes for the selection and you probably don't care. Like you don't need to keep them selected when you're like changing sort order. I at least think that's a good compromise. And this made it much easier to set that up without having foot guns because like deep within clearSelection the way signals work, if there's a state variable being called inside of clearSelection and I just put this within an effect, that can trigger the effect in weird random ways that you wouldn't expect or want. This fixes all that. I really like having it.
I'm also using their scrollState utility here on the assets page so that when you're on here and you start scrolling down, you see that this pops up. So like when I'm at the top of the page, that's not there. But you scroll down, you get this jump back to top button, you click it, you go up here, and that's all just coming from their scrollState.
I pass in my root div, which is bound to the root of this page or whatever. I can check whether or not it has scrolled by doing a derive, checking whether or not the scroll.y is greater than 10. So like if we have actually scrolled down, and then whenever I want to like show the element, you just do it conditionally based on this hasScrolled. And you can jump back up to the top by just literally doing an onclick event here on that little button by doing scroll.scrollToTop.
React's Ecosystem Exists Out of Necessity
And then the other quick rant I wanted to do in this video is the like Svelte doesn't have a standard library rant where this was this is like one of the common things you'll always hear whenever you bring up something that's not React is like oh well but React has such a good ecosystem. Look at all these packages and things that support it.
And the reason why React has all that stuff is because it has to have all that stuff. React is weird. The mental model makes a lot of sense once you get it. Like once you understand that oh a component is just a function and every time you just mount the component you're calling the function and when you change a state variable you're going to recall that function which will rerender that whole component again with the new results and then that'll cascade down the tree. Like that's how like the rerendering in state and stuff works in React. And if you understand all that it's very doable and very good. But that also means that you kind of need a library for a lot of things to like make helper hooks for stuff because when you're doing stuff like doing markdown parsing or whatever, the actual function for rendering the markdown needs to go in a callback so that it doesn't rerun every single time the component rerenders and you need to memoize a bunch of stuff and you need to like do a bunch of stuff right in order to make React work.
You really don't have to do that in Svelte and you just, you really don't need a standard library for this. Like we have Runed, I would consider Runed to effectively just be like the standard library for Svelte. It's kind of like you know how like JavaScript or Go or whatever has a standard library. This is the standard library for that. All the utilities you need to just like build real apps.
I also get a lot of questions like oh how am I going to build Svelte apps when I don't have Shadcn or whatever that's like a such a great part of React and Next.js. And we do have Shadcn. We have this amazing first class port of Shadcn built and designed for Svelte and Svelte 5. We just have this. We have the good component library. We have the good standard library. And then everything else you could need, you can kind of just like use normal raw JS libraries.
Integrating Standard JS Libraries: marked and D3
Like in this project right here, this is markdown that's coming from an LLM and I am rendering it out as markdown. Obviously, like the spacing is kind of up because I'm not trimming the new lines and the LM's outputting weird, but like you get the idea here where it spat out some markdown format where like this had the two hashtags in front of it and then this was a bolded list and it renders it correctly using the marked library. For React you would have like a whole like useMarked package or whatever. In Svelte you can just kind of call it and use it where in my agent store here where I'm actually rendering this, whenever I get a new text chunk down, I can grab the new content, like get my updated content or whatever. I call the marked function on here which is a markdown compiles markdown to HTML. I pass in the updated content I get my marked result. I set that as my state variable and then within the page.svelte when it comes time to actually render that to the DOM all I have to do is @html output.parsedContent. I'm just taking the HTML string generated by marked and then displaying it on the page and it just works. I'm styling it with prose from Tailwind and that's it.
Another great example of this is D3, a library for making like crazy powerful and good visualizations or whatever client side. If you're at the point where you're actually writing D3 code, you know enough about React to escape out of React land and then do it correctly. But D3 works by doing like direct DOM manipulation type stuff. It's great for SVGs, great for graphs, that kind of thing. In Svelte, it's just like trivial to actually use D3 under the hood for like a lot of the SVG stuff I've been doing in projects. I'm just kind of using D3. And you can just directly call DOM elements and directly mount HTML elements because there's no weird virtual DOM. There's no like weird random nonsense you have to deal with in Svelte-land.
Conclusion: Svelte's Ecosystem Is Not a Problem
Normal JS libraries, like whenever you go to some project or product or whatever, their normal client side JS thing will almost certainly work really well out of the box with Svelte. There's no weird stuff you have to add to it, which to me makes it so that the ecosystem or whatever is just kind of a non-factor. We have the two like big pieces we need. The actual framework itself has a ton of really amazing utilities built in and everything else. We can just use them out of the box, no problem. Like it's a vanilla HTML site.
The whole thing just feels really good to me and especially at this point where I feel like I've gotten pretty experienced with the framework and generally know what I'm doing. I just really don't miss the React ecosystem, frankly, at all. So, hopefully if you were on the fence about Svelte because the ecosystem or whatever, it's just it's a nonfactor. It's a non-pro.
If you enjoyed this video, make sure you like and subscribe. I'll have a lot more Svelte stuff to talk about probably pretty soon. And uh yeah.
