My biggest issues with Svelte in 2025...

### Transcript {ts:0} Spelkit is my favorite framework, but that doesn't mean it's without its {ts:3} problems. And today I wanted to talk about those problems. I've been building way more complex stuff with Spelt ... Been testing out more advanced stuff, with streaming, with effect, with building library implementations for {ts:15} stuff like React Query in Spelt. I've been doing a lot. I've really started to run up against the edges of this {ts:20} framework and I've gotten a much better idea of how it really feels. So I wanted to talk about it. There are three things {ts:25} I want to cover here and that's going to be the new runes primitives, the extensibility and ecosystem around spelt {ts:31} and spelt kit and the one component per page thing. And I want to go over what the issues here are, some of my {ts:39} solutions, and just general thoughts and vibe on the framework and how it just feels to build with these days. So, {ts:45} let's start with the runes primitives. ... {ts:171} does a really good job of showing how these things actually work. But because these are signals, this means that the {ts:177} reactivity is a little weird. And the way we pass these into functions is also a little weird. We need to use getters {ts:183} and setters in order to actually make those variables work reactively by passing them into like for example this … {ts:336} switching the cache entry and I believe if I increment this up to four these two will now be synced. So now I go here and {ts:343} then these two are now in sync. So that did work in the basic one but in the more complicated version of this it {ts:349} didn't work because we had other pieces within our query definition that were also reactive. … These things work super well. Basic derives basic effects in the happy {ts:375} path. They are incredible. As soon as you get into these weird complicated use cases, they get a lot more painful. And {ts:381} it's I don't know, the React primitives are can be annoying to work with on the Happy Path because they're so verbose … I love using them in these classes, but when you get to these complicated edge {ts:478} cases, they get a little more painful. The next thing I want to talk about is the overall ecosystem and library {ts:483} support for spelt. One of the things you'll always hear with React is how good the ecosystem is, how many awesome … And I've especially run into this when trying to do weird things {ts:547} like markdown rendering. Something I've been working on recently is trying to get better with HTTP streams, seeing how {ts:553} these things work and working with like LMS and stuff like that. So, I ended up building a very minimal chat app in … And a lot of even just some of the methods when I was {ts:603} using it just kind of broke and didn't really work. So, I had a lot of trouble actually using that package. And {ts:609} initially, I was kind of annoyed because I'm like, well, the third party support isn't great here in React. … {ts:776} it hasn't really limited me. The last thing I want to talk about here is going to be the one file per component {ts:781} problem. When I first made my Spell Vive reactions, this was one of the biggest problems I had with the framework at the {ts:787} time was I didn't like that I couldn't have multiple components in one file. … {ts:932} up at the top and then use those without in my markdown. It's really great. It's basically resulted in me often having a {ts:940} page. And then right next to it, some class that maintains all the state for that page. And then the page is {ts:947} responsible for the actual markdown and then basic event listeners like a handle submit or an onclick or whatever. … {ts:973} work, you would probably have to turn make it look a bit more like React where you would have to probably define a {ts:980} component as a function. It would have to return JSX or some weird HTML thing. It would have to put all this logic into {ts:988} the top of the function. it would end up being kind of awkward and weird.