This is THE Framework You Should be Using in 2026
By Ben Davis
Summary
Topics Covered
- SvelteKit Tops Full-Stack Primitives
- Async Await Transforms Svelte Markup
- SvelteKit Server Components Excel
- AI Masters Svelte via Patterns
Full Transcript
I honestly kind of miss the days when we were constantly getting brand new JS frameworks. It kind of feels like the
frameworks. It kind of feels like the world has just moved on to AI stuff and no one's really thinking about it.
They've just settled on React. But I
really haven't cuz I do not like React at all. I want something better and that
at all. I want something better and that something better is felt. I've talked a lot about it before, but I wanted to go through and talk about why a I think it is still worth learning something new
and different in 2026. Even though the LLMs are hypothetically not as good, which I disagree with. I'll show you that later. And I just want to talk
that later. And I just want to talk about all of the insane things that have changed in 2025 for spelt. It is not the same framework it was a year and a half ago. And the direction they're going
ago. And the direction they're going with this is really, really good. And I
think it's just a fundamentally better primitive for building sites. And I want to talk about it because I have built a lot of stuff with spelt big thing 2.0 which is super close to shipping. I'm
hoping it'll happen this week. We'll
see. But that's the current plan. Uh
this is a big spelt kit app. Um all the ry stuff internal management for my channel and Theos entirely written with spellkit. Uh better context. Doesn't
spellkit. Uh better context. Doesn't
have a super heavy web component yet, but that is coming and that will again all be written in spellkit. Stack on top of that the insane amount of like side projects and random things I've worked on. I have a lot of experience with this
on. I have a lot of experience with this framework at this point. This
visualization posted by Bead is the entire reason that I wanted to make this video. I think it does a really good job
video. I think it does a really good job of showing just how much has really been changing in this framework. If you
looked at it before a couple years ago or you've just seen it in and out of the news over the last few months, I guarantee you this framework is not as you remember it. And they have made a bunch of changes that I think have
fundamentally turned it into the best primitive for building full stack web applications in 2026. I don't think anything can really compete with it at this point. There's certain frameworks
this point. There's certain frameworks which can do certain pieces slightly better, like spelt 5.0 brought in the new rune syntax, which gives us signals based reactivity. And you could maybe
based reactivity. And you could maybe argue that solid does it a little bit better. It's slightly faster on some
better. It's slightly faster on some benchmarks, but as an overall workhorse solution, the spelt one is really, really good. Then they have the remote
really good. Then they have the remote functions, which are their RPC endpoint type things. You could maybe make the
type things. You could maybe make the argument that Tanstack start is doing a similar thing and they're a little more flexible there and they can hook into React query primitives better which can maybe make them a little more flexible
but just as a core robust primitive within the framework itself I think they're really really good and give you pretty much everything you need to actually build a compelling full stack
app with type safety especially with the form remote function the command remote function we also have async felt and async ssr which I hadn't put this together until recent We'll talk about this when we get here, but um they kind
of added server components to spelt. I
know that sounds very heretical to say and I'll justify it later, but you know, this is one thing where you know, Nex.js and spelt are kind of doing the server component thing. I think spelt's doing
component thing. I think spelt's doing it much much better than Nex.js is. Um
but I think you kind of see the point here where it has all of the pieces you need to build whatever you want. a
really solid layer for API routes, really solid layer for RPC functions for getting data up and down from the client to the server. You've got great reactivity primitives with the runes.
You have create context for global stores. You have add attached for
stores. You have add attached for directly working with the DOM. You have
an MCP server for giving agents updated context on how to actually use felt plus ways to actually check the spelt code that they write with their one of the tools that they expose. OTEL is built in
as a first class citizen of the framework. So, it's incredibly easy to
framework. So, it's incredibly easy to get good observability traces on your spellkit app. What's actually happening?
spellkit app. What's actually happening?
You just kind of have it all here.
Runes, again, I've covered this one a lot. A lot of other people have covered
lot. A lot of other people have covered it. It's the new reactivity primitive.
it. It's the new reactivity primitive.
It's signals based. I'm going to have a video coming out about solid very soon.
We'll talk about signals there. I don't
I don't want to waste time for now. One
of the biggest changes that got almost no attention was the addition of spelt boundary. This is very similar to the
boundary. This is very similar to the suspense boundary within React where you can define in here you have some asynchronous call within this boundary and then you can provide a snippet for
the loading state and then you can also have a snippet for the error state. It's
basically just like the loading block within a clientside component. It is now possible to use the await keyword within the script tag of a component inside of a derive function and inside of your actual markup. And what that means is
actual markup. And what that means is that stuff like this is now possible.
You can now have some fetch call that would go fetch some data from the server and you can have that be an await that just runs the function within your markup. But the thing that makes the
markup. But the thing that makes the await keyword even more interesting is the fact that remote functions were introduced into spelkit. Because of the way async spelt works, we can call get post which is a remote function defined
on the server with full stack type safety. You invoke it like a normal
safety. You invoke it like a normal asynchronous function. It'll do the data
asynchronous function. It'll do the data fetching right here in the component and work exactly the way you would think. We
wait for the posts and then we render out each of them in a list and that's it. Hey, so uh me from the future here.
it. Hey, so uh me from the future here.
I am editing this video and realized the example I used for how all the async remote function stuff comes together is kind of weak. I think I actually wanted to show you guys this one instead. I
posted this last night mostly as a gag of I'm so hyped to ship code to an official ping project that would give Theo a stroke. And this code would give Theo a stroke. I am abusing every single
possible new spelt thing for the compiler to work.
I know he is not a fan of the notjs thing, but that's not really the point here. The point here is this code kind
here. The point here is this code kind of shows everything I was just doing.
This is the live actual version of it.
So you can see the background removals popped in there slightly after the page loaded because it was fetched on the client. The code for this is really
client. The code for this is really really simple. You have a snippet which
really simple. You have a snippet which is basically just like a component within a component for spelt. Spelt
components are just pages. There's no
concept of multiple components in one file really. Not in the sense that there
file really. Not in the sense that there is in like react or solid. So one thing I do miss like every time I work on solid. I'm like man I really I really
solid. I'm like man I really I really wish we had multiple components in spelt but I don't really know how they would even do that without fundamentally breaking the way the framework works and
feels. you would probably have to bring
feels. you would probably have to bring in something either like JSX or JSX itself. But then at that point, we're
itself. But then at that point, we're kind of just solid with a compiler and it loses a lot of the the magic that spelt has where it feels really close to HTML. There's no JSX, there's no class
HTML. There's no JSX, there's no class name, there's nothing weird. It's just
writing some HTML pages with a script tag that feels like normal HTML. I
really like that about the framework. I
don't really want to lose it. So
snippets are kind of the middle ground that we've got right now that basically just make it easier for me to organize the logic here where I have this snippet that has the boundary which you talked about earlier. Then the pending which is
about earlier. Then the pending which is just a little loading component. Nothing
special here. A failed snippet which will render every single time the asynchronous call in here fails which is this. I am doing a call to a remote
this. I am doing a call to a remote query that will get me the background removal limits for the loggedin user uh based on their org. Do a bunch of display down here. Literally nothing
interesting. The only kind of neat thing is this. Uh this is a very this codebase
is this. Uh this is a very this codebase is entirely effectified. I am not going to talk about effect in this video.
There will be a lot of effect content this year. Trust me, it's coming. Um I'm
this year. Trust me, it's coming. Um I'm
fully all in on this. I love how it works. But yeah, I mean you can just see
works. But yeah, I mean you can just see like imagine there isn't the effect nonsense here. This is a normal async
nonsense here. This is a normal async function on the server where we're getting some data about the user's current usage from autumn which I'm using for payments. It's really, really good. Return the result. Get it down and
good. Return the result. Get it down and show it here. Uh, if we did have an error, so like if I uncommented this effect.fail, I'll refresh. And yep,
effect.fail, I'll refresh. And yep,
we're going to get this 521. So, it
broke. RIP. That's rendering out the correct app error cuz I'm doing a bunch of a bunch of crazy stuff to make error handling really good in this project.
Uh, another video for another time when we go deep on effects stuff in progress.
One last thing I kind of glossed over in the original recording is the MCP server. I didn't really talk all that
server. I didn't really talk all that much about it because I'm still going back and forth on it. I have not given it a super heavy real shot. If you've
watched my content before, you know I'm very much skeptical of MCP. There are a lot of things I don't like about it. I
think there are better ways for communicating with the agents, but at the same time, the tools that are available here are very good. Listing
sections of the documentation, getting a piece of the documentation. The
autofixer is really really nice where it'll do some static analysis on spelt code you pass into the model which will give the LLM up-to-date suggestions of like hey you have a syntax error here fix this before you actually apply that
diff to the codebase and then the playground links are also very very nice. It's a subtle thing, but the fact
nice. It's a subtle thing, but the fact that spelt has such a good built-in playground system, like if you go here, you can see it. They have a great ripple that just exists in the browser where you can run a little spelt app. Being
able to have the LM generate a component, run it up in the ripple, that's really cool. All this is really good. I just don't know if MCP is really
good. I just don't know if MCP is really how I want the agent to be getting access to it. But at the same time, the spell team very much believes in MCP.
And generally speaking, at this point, when I believe one thing and the spell team believes another, at bare minimum, I need to re-evaluate and do more research into what we disagree on because they are very smart and very
good at what they do. So, I haven't had time to do it yet. I need to do a deep dive on MCP. Hopefully, pretty soon. Uh,
over the next couple weeks, there will definitely be a video of either Theo was wrong about MCP or yeah, MCP sucks. So,
one of those two videos will come out soon. We'll see how I end up feeling
soon. We'll see how I end up feeling about it. But for now, really the big
about it. But for now, really the big point here is that there are a lot of efforts being made to make sure that spelt does work well with LMS. And I think oldM is about to talk about that more. Another wild thing added in was
more. Another wild thing added in was async SSR. This is what I was talking about earlier when I jokingly said that spelt kind of has server components. Now
we kind of do have server components where if you look at this, if we have an SSR page in spellkit and within that components markup, we have this await delayed send a message here. It waits a
second. The actual HTML that gets sent
second. The actual HTML that gets sent down to the client doesn't have any of this in it. It's fully server side rendered. So that page doesn't get sent
rendered. So that page doesn't get sent down until we finish all of the awaits within it. It's serverside rendered,
within it. It's serverside rendered, which means that instead of having to do like a load function, which we would have to do before, we can just put an await within the script tag or whatever or maybe within the meta tag so that we
can get the up-to-date SEO data or something like that. That is now just a thing that is built into speltkit and works very well. And what's really nice about this is you don't have to SSR everything that's an await if you want that data fetch to happen on the client
itself. You can wrap it in a spelt
itself. You can wrap it in a spelt boundary with this pending snippet so that the actual HTML sent down to the browser looks like this. And then once it starts hydrating this will get updated to include the what's info. So
the pitch for you actually using Spellkit is the really good full stack type safe data fetching story, the great serverside rendering stuff, the amazing reactivity primitives, no virtual DOM,
the ability to just very easily directly interact with the DOM, no weird reconciler to deal with or anything like that, a very rich ecosystem because the reality is any normal client sidejs
package works beautifully with spelt.
don't need a special spelt package so that you can wrap up the context and make sure that it works nicely with state variables and rerenders and all this stuff. No, it just it just works.
this stuff. No, it just it just works.
And you will find as you're doing more and more complicated stuff, having a framework with better primitives really does make a difference. I've done some pretty big stuff in React in the past and I just I don't ever really want to
deal with it again. I don't think it's worth having that extra mental overhead just for a worse performing framework.
It doesn't make any sense to me. you
will be very happy if you switch to something like this or something else. I
think that, you know, if you want to go do like solid or something like that, that makes total sense. You don't have to do what the random guy on the internet says. I just think that this is
internet says. I just think that this is really neat. The problem then becomes,
really neat. The problem then becomes, well, this is all really cool. Sure, it
sounds nice, but how the hell am I going to have Opus45 write code for me. Opus45
can write really, really good Nex.js and React code, but how is it going to write spelt code? And the reality is the
spelt code? And the reality is the modern frontier AI models actually do really, really well with spelt. There
are some things that they don't know how to do. Like I think this graph is a
to do. Like I think this graph is a really good visualization of the basically context cut offs for these models. The GPT series I think their
models. The GPT series I think their training cut off has been like right around here sometime in late 2024 for a very long time which sucks. Gemini
series I I don't know what they're doing. I I do my best not to think about
doing. I I do my best not to think about Google. It's good it's good for my
Google. It's good it's good for my mental health to not think about Google.
That company sucks. Um, but then outside of Google, the actually good lab anthropic, their models generally speaking, it seems like their training cutoff is like around July of this year.
So like July to August, that range and you can see remote functions in Async are right on the line there where they really don't know anything about them.
They can't write them out of the box. If
you tell even Opus to write you a remote function, it's going to try and do like a load function or a form action or something like that. But there are ways around this. For one, if you are just
around this. For one, if you are just very much in the driver seat and controlling how all this stuff works, which you should be if you're building anything outside of a CRUD app, all you really need to do is give it some examples of how to actually do it and
then they will figure out the rest from there. They're very, very good at that.
there. They're very, very good at that.
When I was building out this project, I've viodated most of the UI on this and a lot of the server side stuff. The way
I've really found myself building projects, and this will be a separate video later, too, is I will go through and build like the first version of something myself. So, for example, this
something myself. So, for example, this remote get 2025 videos remote function.
I did not write this. This was written entirely by Opus. But if you go up a little higher here, this um I believe it was yeah, it was this one. This is the first remote function that I wrote for this project. The remote create channel.
this project. The remote create channel.
It's a form remote function. It takes in the create channel schema. It calls uh off remote runner, which is also a helper function that I wrote. I had to do all of this stuff myself. I didn't
just let the LLM do it. But once I had this written as an example of like, okay, here's how remote functions work.
It was able to do the rest of these zero issue. Once it has that pattern, it can
issue. Once it has that pattern, it can latch onto the pattern and the training data for modern web frameworks is your own code in your own project. Another
great example of this is this morning I was going through and trying to update the subscription logic in Pick Thing 2.0. Basically, if your subscription was
2.0. Basically, if your subscription was pending cancellation, I would have you resume that within the Stripe dashboard instead of using Autumn's primitives to do it, which was causing problems with desyncing the two. I just told it like,
hey, I want you to make this change on this page, do some stuff to fix the sub, and you can look at the code it outputed here. First of all, on the server, this
here. First of all, on the server, this is correct effect code. It is making a resume subscription method within the autumn service, doing all that correctly based on stuff that I had already written and made. Then it made the
remote resume subscription command, which is a remote function. Again,
didn't tell it how to do it there, but it was able to look at what I already had and pattern match off of that and do it correctly. And then finally called it
it correctly. And then finally called it correctly on the client. Uh updated some UI. It's very good at UI and that kind
UI. It's very good at UI and that kind of thing. Ran the check function and
of thing. Ran the check function and we're done. I had a little bit of
we're done. I had a little bit of follow-up. Uh but now the feature is
follow-up. Uh but now the feature is done and it works super super well. And
there are actually a lot of ways to get up-to-date info on these things. Uh this
is actually something that I've been thinking about and working on a lot because I have a tendency to these more weird niche technologies like spelt and effect where yeah the models can't write them out of the box and getting
up-to-date info on them is kind of a pain. So I've been working on this thing
pain. So I've been working on this thing which it's fully open source and free.
It's fully open sourced and basically what I can do is like at spelt how does the form remote function work in spelt kit? So I ask it this it's going to go
kit? So I ask it this it's going to go through and actually search the codebase. It's not the fastest thing in
codebase. It's not the fastest thing in the world, but it is very lossless and it works really, really well. I've
actually found this is a really great way to learn new technologies is just kind of talk to them and go back and forth with the actual codebase. And as
you can see, this is correct info on how the four remote function works. You can
have the model call it with the CLI.
There's a lot of useful stuff you can hook up here. Again, this project's not done. I have a lot more work I want to
done. I have a lot more work I want to do on it. I'll talk about that when it's done. But yeah, there are ways to deal
done. But yeah, there are ways to deal with this. There's ways to get around
with this. There's ways to get around it. I don't think that the models being
it. I don't think that the models being quote unquote better at some random language or framework really matters all that much. Last thing before I finish
that much. Last thing before I finish this up, I there's a couple personal things I wanted to go into here. So, if
you're not super interested in that, hope you enjoyed the video. Subscribe
for more spelt and AI and random tech stuff, but there are two pretty big changes coming to the channel very soon here. Uh, one is I'm going to start
here. Uh, one is I'm going to start streaming probably every week is the goal, I think. Um, if you've watched Theo's videos, which if you're watching my videos, you almost certainly have. uh
his system for recording his videos on stream and doing things that way is really really good. And I want to be more consistent with videos. I've been
very much on a like two to three videos a month cadence for a while, which is fine, but it's not what I really want it to be. There's so much stuff I want to
to be. There's so much stuff I want to talk about. Like just looking at my
talk about. Like just looking at my notion, I have seven videos in planning that I actively want to talk about like the Tanstack AI SDK, SolidJS, Monor repos, how I'm actually using AI, the primitive base system for building
projects that I've been working on, Elixir. There's just there's a lot of
Elixir. There's just there's a lot of stuff that needs to get talked about.
It's just because of what my job and life is at this point. I need a very structured time of like, hey, this is when I'm going to go live and record stuff every week. So, keep an eye out for that. I'm targeting like a Tuesday
for that. I'm targeting like a Tuesday or a Thursday type thing. So, I'll post them about on Twitter and YouTube, but hope to see you there when I start doing that. And the other major change is I am
that. And the other major change is I am going to start working with some brands, doing some sponsor spots on the channel.
No sponsored videos. That is not a thing that I am going to do, period. Very much
going to do the ad spot model kind of similar to what Theo does. I have been going back and forth on doing this for quite a while. I ultimately just settled on like, hey, it's really the biggest
thing is it makes spending the time and effort to research and plan and edit and shoot all of these videos. It makes that a lot more worthwhile. And B, it also just like forces me to make more content, which is something that I need
to do. There's just there's so much
to do. There's just there's so much stuff I want to do and make, and this justifies that very well. And also, it gives me an excuse to talk about some really cool stuff I want to talk about that I just can't really fit into a
video. The brands that I'm working with
video. The brands that I'm working with off the rip. It's going to be Gravile, Daytona, Agent Ingentuity, and Upstash.
All of these are companies that I use and really, really like. Daytona I've
been using for some crazy sandboxing stuff where I can run an open code instance in the cloud like BTCA, the better contact stuff that is going to get hosted on Daytona so that you can
run it up there and then stream that down via an MCP server or a CLI or a web app or a TUI. any of these different ways you can get a cloud hosted version of an agent with actual file system
access. It's gonna be really really
access. It's gonna be really really cool. And then I'm going to do some
cool. And then I'm going to do some background jobs with that and like it's going to be insane. It's an amazing technology. I love the founder. I love
technology. I love the founder. I love
the team. That'll be super fun to talk about. Reptile is an interesting one cuz
about. Reptile is an interesting one cuz I really didn't think that I would care about AI code review because a a lot of the projects I work on is just kind of me by myself just hacking on stuff. But
having adopted it for the last like month and a half, it's it's really really good. It's really changed my
really good. It's really changed my workflow to where I'm actually bothering with PRs even when it's just me working on stuff. I've also been adap adopting
on stuff. I've also been adap adopting uh graphite. Not going to be working
uh graphite. Not going to be working with them. They got acquired by Cursor.
with them. They got acquired by Cursor.
That's not going to be a thing. Uh I
just think their product's really good.
Using their stacked diff system with Gravile has been really really good.
It's great workflow. Hype to be able to talk about that more. Agentuity, I just I love those guys. I love the team. They
I gave them an insane amount of feedback on why their product sucked six months ago. all the things that needed to be
ago. all the things that needed to be fixed and changed and they have taken it to heart. They've done an amazing job
to heart. They've done an amazing job fixing everything and changing it. The
thing it's basically turned into like a convex for AI agents and it's really really really cool. I cannot wait to talk about that one more and upst one.
I'm going to be working with Josh Tried coding on that one. We're going to be doing some cool stuff with their real time streaming SDK and some other things they're working on. I just I love that company. I love that team. And really
company. I love that team. And really
that's the whole point of all of this.
The very hard line that I'm setting with this is it is stuff that I am either actively shipping or using or something that if I had that specific problem, it would be the solution that I picked. So,
I'm basically just taking all of my favorite technologies and trying to convince them to pay me to do some ad spots so I can sneak them into other videos. Like, sandboxes makes no sense
videos. Like, sandboxes makes no sense as a topic in a solid video unless it's an ad spot, which means that I do get to talk about them there. And I hope you guys end up liking them. I hope it uh all ends up going well and we can do
more of that and it'll just result in more videos, more content, more useful stuff, more open source projects, all that. That's really my goal for 2026. I
that. That's really my goal for 2026. I
really want to make a lot of videos. I
want to do a lot of open source work. Um
BTCA, River, all that stuff. That's a
big focus for me. Keeping Theo's channel running it and up is a very major one.
And that's it. Life's good. Just need to do more of it. So, if you enjoyed all this, really appreciate you sitting through that little rant.
Loading video analysis...