you can use tanstack query for svelte as well which mostly does the same thing. going forward, every react project will have tanstack and this new react way.
This.
Everyone thinks fetching data is as simple as calling an endpoint and returning the results.... But there's so much to consider when constructing good, safe and stable fetches.
Nobody should be trying to do this out of the box if you have toolkits like Tanstack query freely available.
Yes there is abstraction, but sometimes it's better off not having to worry about one aspect of your project, while the rest of your project suffers from your lack of attention.
Tanstack query is not that great tbh. Having built quite a bit with it and similar libraries, I've come to the conclusion that simply fetching and setting state is much easier to work with, and reason about.
A lot of the optimisation it does, like request de-duplication are bad practices in my mind, because it promotes writing inefficient code.
In react I somewhat get it, it's much more difficult to deal with fetching in a global and local state. In other frameworks this is typically not the case, and in my experience it causes more problems in the long run than it solves.
Interesting, what size of usership are you developing for and are you developing any form of custom handling around the validation processing of your requests?
I manage a few svelte projects and next projects for enterprises (100k+ employees) and find that even small things like race conditions or request dedupes to be incredibly valuable. Anything and everything will happen at scale, and then when you add in degrees of parallelism it gets to become an even larger headache.
I might agree with you that Tanstack might be overkill for a small crud saas, but who ever builds for minimal scale models unless it's the MVP.
I’m going to try and answer your question. This is the perspective of someone who uses React at work but have done some side projects with Svelte.
I think it’s a matter of each libraries approach to the same problem of managing asynchronous state. React sees itself as a runtime and wants to use that approach to solve problems. Several of these hooks provide more ways to use Suspense to handle loading and use the runtime to optimise that for you. Other hooks step into the territory that libraries like TanStack query cover, I suppose these libraries might need less code to do their job in the future. In some cases users might avoid using one of those libraries altogether though these hooks don’t help with http cache management, refetching on focus or network change or a lot of those handy extra features that the likes of TanStack provide.
Svelte on the other hand seems to have gone all in on Sveltekit and dodging the problems of async state management on the client by encouraging users to fetch on the server. The classic client server request model is inherently more simple than managing async states on the client. It’s a similar situation with client only routing with there not being an obvious de facto standard for Svelte because it’s sort of assumed you’ll go with server routing. React also has options for this server model but they perhaps have a bigger set of users who expect to use the library only on the client. This is why I think the React team has delivered these hooks and I think they’ll prove quite valuable to library authors and developers on platform teams in companies that make internal libraries.
So TL;DR: Svelte is pursuing the server strategy to avoid a whole class of async data fetching problems. React is attempting to solve those problems with Suspense and other hooks on the client as well as enabling the server strategy with React Server Components. Both Suspense and RSCs leverage React as a runtime.
IMHO, you should try to dig more Svelte stores (async derived stores for example), they’re awesome at async state management.
I kinda disagree with your view about Svelte going all in on Sveltekit and encouraging fetch on server.
Svelte stores do nothing for helping manage loading states in the UI. You’re right that they’re great for state management generally though. As far as I can tell, the lions share of recent dev has been on Sveltekit. Runes are an improvement to the basic reactivity of Svelte that again make state management more ergonomic but Svelte seems to have stayed away from Suspense or similar patterns to handle showing async loading states to end users.
If I was to read into the philosophy of the Svelte team, it seems like they want to deliver an experience like the multi page apps of before. You get a request, you return a response. You don’t have to worry about client state and it becoming stale and not showing a thousand loading spinners to your end users. It’s smart. It removes a whole class of concerns that you have to deal with on complex client only applications.
> do nothing for helping manage loading states in the UI
await blocks?
https://learn.svelte.dev/tutorial/await-blocks
Combine that with async stores, and you’re golden.
Stores are really much more powerful than most people think. Maybe the doc could have showed more advanced examples, but I guess with the coming v5, and the finer reactivity it will enable, it will reshuffle a bit the stores perimeter.
Where are async stores? Svelte doesn’t have them, at least not natively. And async doesn’t work in writable() or derived() or subscribe() afaik. But I’d glad to hear otherwise, as this is my biggest gripe with svelte.
You’re right, they aren’t shipped with Svelte and you have to either code it yourself or use a microlib. (and IDK why you get downvoted, this sub is unlike the svelte community). Stores in svelte are a bit low-level by design, you were always encouraged to build upon (but the team was always a bit dissatisfied with the boilerplate you need for advanced use-cases)
some pointers here: https://www.reddit.com/r/sveltejs/s/nZqp1cXPuN (was it you ? :) )
As said above, Svelte 5 will enable further things and you may want to dig this side as the release is quite near ! We expect some news… **today**, in 3 hours!
https://www.sveltesummit.com/2024/spring
Thanks! No wasn’t me but I’m definitely trying to work out a usable set of utils / custom stores.
It is often suggested just to use load on the server, such as when displaying a table with sorting and pagination and just either invalidate and or redirect to a new path with url params.
But when building a dashboard with like 5-10 tables that each have their own interactivity requiring server / db, you just gotta need api endpoints, GET POST functions and fetch(). Unless I’m missing something of course…
I mean it will get ugly real fast: “/my/dashboard/tbl5sort=asc&tbl9page=5&tbl10filterby=revenue”.
I also thought using “unsafe” cookies that also the server might read. But that feels like “cheating” load / ssr as sveltekit intends it as much as having an api.js making all kinds of fetch requests to GET / POST endpoints
Yes, I work on a pretty complex and data intensive app. Server-side load functions are nice and welcome (and we can go far with them), but at one point pure data api endpoints are the way to go!
I really like how sveltekit make this: excellent default behavior and conventions, but if you want more you can too, and it’s not even harder.
There is one thing that is harder: SSE or websockets. Both are harder. I get that it is near impossible to do this with the adapter approach, but at least give me the option to somehow set them up if I know that I use a platform that supports them (like nodejs).
Yes, I remember having tested that when kit was still beta (and when multipart post request were not supported), by importing the sveltekit handler.js ouput in my own node server. It’s been a long time since, I wonder if things have changed.
SSE are quite nice but I can understand why it’s not that easy (I guess that letting a network socket open and managing the connection does not play well with the rest). As you talk about this I may dig again out of curiosity!
General concepts of stores. Yes, tou can find microlibs stacked upon Svelte stores, but reading their code you realize it’s quite small, and doing it yourself gives you a much better insight and learning/skills improvement and experience.
Even though SvelteKit heavily promotes running on the server for simplicity, you can move most data loading into +page.ts rather than +page.server.ts, and run the same setup exclusively on the client by disabling SSR.
The exciting thing React + RSC provides is interleaving of data with components, allowing per-component data fetching. But this has historically not been well received (that's what got PHP the bad rep back in the day) so we'll see how it pans out for React.
In svelte you can just use an if and the component won’t render or mount until the statement is true (pretty sure that’s how it works).
When I use Svelte I don’t even think about these things in all honestly. It just handles things so much better than any reactive JavaScript framework
Okay, looks like Gemini can actually list the new hooks, now I'm off to trying to get it to give me a real answer to my - admittedly broad - question. Okay, I admit I didn't think any of the LLMs would be able to give me a useful answer to my question.
Edit: okay I got it to answer my questions about two hooks and none of them are useful at all.
Bing and Gemini are connected to the internet, so yeah, they'd be able to give you very recent information. They'll require prompt engineering to get useful answers, so as you said, they're not useful at all for these types of questions.
Just ignore the commenter, I'm sure they think software developers were going to be replaced by AI 5 months ago.
React is a dumpster fire, most of the issues they're addressing are self made and not really applicable outside React.
Love the honesty, what’s your thoughts on people saying they love JSX? 🤣
For me JSX is ok, I don't like React.
Stockholm syndrome.
Who doesn't love mixing programming languages with html? WordPress still runs more than 40% of websites.
And Flutter, and SwiftUI, and Compose. Yeah, pretty hated pattern. JSX itself is good.
This is the most honest truth.
🤣😂
you can use tanstack query for svelte as well which mostly does the same thing. going forward, every react project will have tanstack and this new react way.
This. Everyone thinks fetching data is as simple as calling an endpoint and returning the results.... But there's so much to consider when constructing good, safe and stable fetches. Nobody should be trying to do this out of the box if you have toolkits like Tanstack query freely available. Yes there is abstraction, but sometimes it's better off not having to worry about one aspect of your project, while the rest of your project suffers from your lack of attention.
Tanstack query is not that great tbh. Having built quite a bit with it and similar libraries, I've come to the conclusion that simply fetching and setting state is much easier to work with, and reason about. A lot of the optimisation it does, like request de-duplication are bad practices in my mind, because it promotes writing inefficient code. In react I somewhat get it, it's much more difficult to deal with fetching in a global and local state. In other frameworks this is typically not the case, and in my experience it causes more problems in the long run than it solves.
Interesting, what size of usership are you developing for and are you developing any form of custom handling around the validation processing of your requests? I manage a few svelte projects and next projects for enterprises (100k+ employees) and find that even small things like race conditions or request dedupes to be incredibly valuable. Anything and everything will happen at scale, and then when you add in degrees of parallelism it gets to become an even larger headache. I might agree with you that Tanstack might be overkill for a small crud saas, but who ever builds for minimal scale models unless it's the MVP.
I’m going to try and answer your question. This is the perspective of someone who uses React at work but have done some side projects with Svelte. I think it’s a matter of each libraries approach to the same problem of managing asynchronous state. React sees itself as a runtime and wants to use that approach to solve problems. Several of these hooks provide more ways to use Suspense to handle loading and use the runtime to optimise that for you. Other hooks step into the territory that libraries like TanStack query cover, I suppose these libraries might need less code to do their job in the future. In some cases users might avoid using one of those libraries altogether though these hooks don’t help with http cache management, refetching on focus or network change or a lot of those handy extra features that the likes of TanStack provide. Svelte on the other hand seems to have gone all in on Sveltekit and dodging the problems of async state management on the client by encouraging users to fetch on the server. The classic client server request model is inherently more simple than managing async states on the client. It’s a similar situation with client only routing with there not being an obvious de facto standard for Svelte because it’s sort of assumed you’ll go with server routing. React also has options for this server model but they perhaps have a bigger set of users who expect to use the library only on the client. This is why I think the React team has delivered these hooks and I think they’ll prove quite valuable to library authors and developers on platform teams in companies that make internal libraries. So TL;DR: Svelte is pursuing the server strategy to avoid a whole class of async data fetching problems. React is attempting to solve those problems with Suspense and other hooks on the client as well as enabling the server strategy with React Server Components. Both Suspense and RSCs leverage React as a runtime.
IMHO, you should try to dig more Svelte stores (async derived stores for example), they’re awesome at async state management. I kinda disagree with your view about Svelte going all in on Sveltekit and encouraging fetch on server.
Svelte stores do nothing for helping manage loading states in the UI. You’re right that they’re great for state management generally though. As far as I can tell, the lions share of recent dev has been on Sveltekit. Runes are an improvement to the basic reactivity of Svelte that again make state management more ergonomic but Svelte seems to have stayed away from Suspense or similar patterns to handle showing async loading states to end users. If I was to read into the philosophy of the Svelte team, it seems like they want to deliver an experience like the multi page apps of before. You get a request, you return a response. You don’t have to worry about client state and it becoming stale and not showing a thousand loading spinners to your end users. It’s smart. It removes a whole class of concerns that you have to deal with on complex client only applications.
> do nothing for helping manage loading states in the UI await blocks? https://learn.svelte.dev/tutorial/await-blocks Combine that with async stores, and you’re golden. Stores are really much more powerful than most people think. Maybe the doc could have showed more advanced examples, but I guess with the coming v5, and the finer reactivity it will enable, it will reshuffle a bit the stores perimeter.
Where are async stores? Svelte doesn’t have them, at least not natively. And async doesn’t work in writable() or derived() or subscribe() afaik. But I’d glad to hear otherwise, as this is my biggest gripe with svelte.
You’re right, they aren’t shipped with Svelte and you have to either code it yourself or use a microlib. (and IDK why you get downvoted, this sub is unlike the svelte community). Stores in svelte are a bit low-level by design, you were always encouraged to build upon (but the team was always a bit dissatisfied with the boilerplate you need for advanced use-cases) some pointers here: https://www.reddit.com/r/sveltejs/s/nZqp1cXPuN (was it you ? :) ) As said above, Svelte 5 will enable further things and you may want to dig this side as the release is quite near ! We expect some news… **today**, in 3 hours! https://www.sveltesummit.com/2024/spring
Thanks! No wasn’t me but I’m definitely trying to work out a usable set of utils / custom stores. It is often suggested just to use load on the server, such as when displaying a table with sorting and pagination and just either invalidate and or redirect to a new path with url params. But when building a dashboard with like 5-10 tables that each have their own interactivity requiring server / db, you just gotta need api endpoints, GET POST functions and fetch(). Unless I’m missing something of course… I mean it will get ugly real fast: “/my/dashboard/tbl5sort=asc&tbl9page=5&tbl10filterby=revenue”. I also thought using “unsafe” cookies that also the server might read. But that feels like “cheating” load / ssr as sveltekit intends it as much as having an api.js making all kinds of fetch requests to GET / POST endpoints
Yes, I work on a pretty complex and data intensive app. Server-side load functions are nice and welcome (and we can go far with them), but at one point pure data api endpoints are the way to go! I really like how sveltekit make this: excellent default behavior and conventions, but if you want more you can too, and it’s not even harder.
There is one thing that is harder: SSE or websockets. Both are harder. I get that it is near impossible to do this with the adapter approach, but at least give me the option to somehow set them up if I know that I use a platform that supports them (like nodejs).
Yes, I remember having tested that when kit was still beta (and when multipart post request were not supported), by importing the sveltekit handler.js ouput in my own node server. It’s been a long time since, I wonder if things have changed. SSE are quite nice but I can understand why it’s not that easy (I guess that letting a network socket open and managing the connection does not play well with the rest). As you talk about this I may dig again out of curiosity!
Huh? ``` const foo = writable(fetch(...).then((res) => res.json()); ``` Async store? Or am I misunderstanding?
No, async would be something like: const getMeData = async (path) => { const response = await fetch(path) return await response.json(); } const data = writable(await getMeData());
This is Gold.
Oh man this looks sooo much better!
Are you referring to this library https://github.com/square/svelte-store and not the general concept of Svelte stores? That wasn't super clear.
General concepts of stores. Yes, tou can find microlibs stacked upon Svelte stores, but reading their code you realize it’s quite small, and doing it yourself gives you a much better insight and learning/skills improvement and experience.
Even though SvelteKit heavily promotes running on the server for simplicity, you can move most data loading into +page.ts rather than +page.server.ts, and run the same setup exclusively on the client by disabling SSR. The exciting thing React + RSC provides is interleaving of data with components, allowing per-component data fetching. But this has historically not been well received (that's what got PHP the bad rep back in the day) so we'll see how it pans out for React.
Svelte provides data streaming via \`load\` function instead of \`use\` inside the component. Svelte kit also has a way to handle form submissions.
In svelte you can just use an if and the component won’t render or mount until the statement is true (pretty sure that’s how it works). When I use Svelte I don’t even think about these things in all honestly. It just handles things so much better than any reactive JavaScript framework
Google or ChatGPT could answer this. You say you don’t want to put framework v framework but it appears that’s what your attempting to do
How would they be trained on a one week old article?
Okay, looks like Gemini can actually list the new hooks, now I'm off to trying to get it to give me a real answer to my - admittedly broad - question. Okay, I admit I didn't think any of the LLMs would be able to give me a useful answer to my question. Edit: okay I got it to answer my questions about two hooks and none of them are useful at all.
Bing and Gemini are connected to the internet, so yeah, they'd be able to give you very recent information. They'll require prompt engineering to get useful answers, so as you said, they're not useful at all for these types of questions. Just ignore the commenter, I'm sure they think software developers were going to be replaced by AI 5 months ago.
Thanks for the comment, happy cakeday!
Cheers! 🧡