> The entire frontend was only ~75KB, and ~32KB after gzip!
i think this is the pull quote. the whole app (https://sveltekit-todo.ameo.dev/) with complete with drag and drop and crud, comes in at 59-75% the size of the base runtime of React (7k, 3k gzip) + React-Dom (121k, 39.4k gzip).
and js bundle size isnt everything - Svelte wins on other developer experience factors as well, and is just missing ecosystem as OP noted.
As a beginner, I can't really emphasize how frustrating learning React is... at least compared to Svelte which is really just easy to understand and learning curve is less steep.
One thing to be very mindful of is that is a very limited application. The footprint of the various frameworks changes based on how big your application gets as shown here[1]. Swyx, I think you are probably aware of Ryan's article but it's worth contextualising for others who might not be familiar. The more components you have the more Svelte loses its edge.
[2] "preact-compat adds somewhere around 2kb to your bundle size, but has the advantage of supporting the vast majority of existing React modules you might find on npm" https://preactjs.com/guide/v8/switching-to-preact/
In contrast, I had a not-so-great experience attempting to use SvelteKit for a not-full-stack SPA. I wanted an SPA "app" for a side project I'd already written in Elixir/Phoenix and kit turned out to be super immature for that. There's a lot of issues with building a "true" SPA in kit - it is built first and foremost for full stack and will throw up a hundred ways if you try to make an SPA, chiefly by making it inconvenient to use client-only libraries even though you're never running on a server. Svelte is pretty cool but if you want to make an SPA I would recommend vanilla Svelte + Routify instead of Kit.
(Or just React. React is pretty good, and vite comes with a React starter that's super good! You don't have to throw something out just because it's "old"!)
SvelteKit now has a static adapter[1] which is designed for those kinds of scenarios, defaulting to pre-rendering all pages and not requiring a server I think. I've not tried it out myself though, but it might be good for that if you want to bring your own API.
> I would recommend vanilla Svelte + Routify instead of Kit.
That sounds like a solid way to go as well. SvelteKit has some nice tools for 100% static sites that do stuff like generate pages at build time from markdown and stuff like that. But if your site is really simple, then that works fine.
We used sveltekit for the front end of our most recent project, and had pretty much zero problems.
If you want to do true front end though, I hear your pain. The biggest issue I had was I never could figure out how to make all my resource paths work with the static adapter, so I was put in the position of having to redo every image reference (for example) if I wanted to build static files. Pretty frustrating.
But if you are just doing SPA deploying to vercel for development I think sveltekit is just brilliant and just works.
Had the similar experience, and as it happens, I was also looking to build something with Elixir/Phoenix backend..
Its nice that it comes with a proxy `fetch` implementation that you can use to make requests to your API backend from the svelekit "backend", but there are many leaky API surfaces around it, esp when dealing with cookies.
The docs is also rather lacking regarding the many callbacks that can run on both server/client, though it is somewhat understandable given everything is still very much in flux...
How does Routify compare with svelte-spa-router[1]? I really like svelte-spa-router for a simple SPA, though I think a lot of SPA routers don't always handle state well.
I'm really surprised at how easy anything is considered "full stack". Where is the ORM/data access library? The validation framework? The background jobs? The caching system? The translations/i18n system? And the other 1000 things you do need for a full stack real life application? I definitely do have those things in Laravel, Django and rails. Next.js, nuxt.js, sveltekit etc are far, far from full stack. They can certainly run js in the backend, but that's not full stack, you still need 10s of other packages.
Gatekeeping what should be called "full stack" based on your own requirements seems futile at best. Believe it or not, there are businesses built without using those things, even though you've never come across that in your life.
Never used Svelte/SvelteKit myself, but seems the framework takes a "some batteries included, others available" approach to the whole thing, which is one way to about it as well.
Yes, I was pulled in by this being a "full stack" technology and half-read, half-skimmed the article looking for how the back-end parts work. I came away with the impression that sveltekit provides some kind of thin layer on top of express to do things like server-side rendering, so still very view-level focused.
I have the same issue with all these fancy "JAM-stack-ish" technologies like next, nuxt, vercel, etc, etc, etc. They are constantly iterating on the front end and its associated DX, which overall is a net good I think, but almost completely ignoring the back-end concerns.
Contrast with, say, meteor. Meteor came out in what, 2014 or something? And gave you a genuine full-stack development experience. There's not really been anything like it ever since. Weird.
And someone with 3 years of experience is labelled "senior developer".
I agree with your sentiment. I've run in to more than a few people who self-identify as "full stack" developers who do not understand what a database is, nor have ever set one up. Half-joking, but I think they're meaning because they do both javascript and css.
I'm not sure the Svelte Kit team considers it fully full stack... I've answered people's questions in the discord channel and usually suggest a separate API backend project or directory and that has never gotten corrected by maintainers.
The idea I usually promote is to use SK to wrap other APIs (in your control or otherwise) returning the payloads your UI code wants.
All that to say: You're not wrong I think you've identified a new category of tool, the full stack UI, perhaps?
I recently started a side project for our company in SvelteKit (I have zero Frontend experience) and while I really enjoyed the Frontend bits I found the backend bits lacking.
I know it's not GA yet so I don't want to complain and I'm happy to wait for the final release. The documentation is severly lacking (e.g. routing) and best practices are missing. I found the same as you: Most articles about SvelteKit don't talk about the backend/storage part at all.
There is the template example app which has a bit of structure but that doesn't go very far, there are a few articles here and there but they mostly mock interactions with any further services.
So my verdict was: Fullstack, maybe-ish, but not for newcomers (which they also don't advertise for). You need to know what your're doing and which additional tools to use. And, as you point out, that's different in Django et. al.
If it is front to back, that’s full stack as far as I’m concerned.
Everything else is a question of what else is involved, but that’s always what you want to know anyway right? Layers and complexity are a whole other topic IMO.
> Where is the ORM/data access library? The validation framework? The background jobs? The caching system? The translations/i18n system? And the other 1000 things you do need for a full stack real life application?
I love using SvelteKit for full-stack apps so much that I decided to package up and release a template with all the stuff that most apps these days typically need.
> This is a pretty tall stack compared to what I'm used to of just running webpack build or similar, and I'd never used any of its components before this.
really? I remember webpack and co bringing 200mbs in node modules. while vite and esbuild bring around 40mb.
> Even after a good bit of docs searching and code diving, I really couldn't figure out what library was actually performing that transpilation or how to configure it.
Svelte components run super fast (no virtual DOM), have tiny build sizes, stellar interactive documentation, and the developer experience is fire. Svelte was also just voted the #1 most loved web framework in the 2021 Stack Overflow developer survey (it beat out React, Rails, Django, Spring, Laravel, etc ): https://insights.stackoverflow.com/survey/2021#section-most-...
I've also really been loving SvelteKit which isn't even out of beta yet.
Things I like about SvelteKit:
- It removes all the annoying front-end/back-end plumbing you have to do in every app. Backend APIs, JS/TS, HTML, and CSS just work together with no configuration.
- I can use JS/Typescript throughout the entire stack
- File-based routing is a dream — I never have to search through code to figure out how to edit a page!
- SEO-friendly and performant server-rendered routes with client-side hydration
- Static generated pages you can specify individually (you can include the marketing site and app in the same bundle!)
- Optional client-side routing for really fast app-like UIs
- Tiny bundles and fast performance thanks to Svelte
- The dev experience is an absolute delight
I love it so much I decided to package up and release a template with all the stuff most apps these days typically need: user auth, admin dashboards, etc: https://www.sveltesaas.com/
You've worded this message to give the impression that you've already created a template that is available for consumption now, so spamming a link that just wants to collect our email addresses seems slightly disingenuous.
Great write up, but I’m surprised by SvelteKit being described as full stack. It doesn’t seem to offer anything around normal back-end functionality. I’ve normally understood full-stack to refer to a framework like Ruby on Rails.
It's definitely full stack; it has endpoints[1] which are just arbitrary API endpoints where you can implement any logic you want (talk to a database, perform conditional logic, etc.).
It may not be a fully-loaded solution like rails, but minimalism can have its own benefits.
It has a backend component, you use an adapter to run it on edge/lambda services like cloudflare, or plain old nodejs. In usage it's kind of murky (by design) where the exact delineation is between code running on the frontend and code running on the backend.
It's "full-stack" in the sense that it's not only client-side - it's more like next in that you have code that lives on a server and can respond to client invocations, which is useful if you want to do server-side rendering and so on. It has some neat payoffs - you can use cookies for auth even if your frontend lives on a different domain, because the frontend server can read those - but IME it's a pain if you just want an SPA, and despite what most of the Kit community thinks, those are still pretty useful. You can't SSG an E2EE chat app.
Why do people prefer full stack for these sort of frameworks. Doesn’t it create more lock in? What’s the problem with frontend + backend api, the api can even be javascript if people only know one language.
I am using SvelteKit in "production" (smallish) for multiple projects. Aside from the small ecosystem (where in reality I am only really missing a UI lib other than IBM Carbon), Svelte has no error boundaries yet. If an error is not caught, the whole app crashes with no way to recover, or even show the user to refresh the tab. See https://github.com/sveltejs/svelte/issues/1096.
Other than that, Svelte + SvelteKit is awesome. I would not choose React or Vue for small(er) projects.
The only thing I react to is the part about "It feels much like Rust vs. C++. Rather than adding layers upon layers to existing infinitely backwards-compatible software, it takes the best patterns and features and builds them from the ground up.".
Svelte bungled this in one place and that is in the html coding. For example Svelte has different syntax for if ({#if}, else ({:else}) and endif ({/if}. I end up looking this up in the documentation way too often - especially when not doing Svelte fulltime.
I initially preferred JSX ("it's just Javascript"), esp. with Svelte oddities like `$$props`, but after working with Svelte templating for a while I now prefer it due to things like property shorthand and event forwarding.
Re: `:else` syntax, I also made mistakes (`#` and `/` were familiar having worked with Handlebars/Mustache) until I internalized that `:` meant block continuation (also used with await/then/catch).
I use Svelte full-time and absolutely love it, but I do have to admit I sometimes wonder what lead to the decision of {#if}{:else}{/if}, {#each}{/each}, etc syntax. Seems like there had to be less verbose, more consistent approach... But, I'm probably not fully-aware of the constraints and missing something.
I sometimes miss the brevity of the React way (which can also be good and bad) for handling conditional code-blocks {visible && <Component>} or {visible ? <Component1 /> : <Component2 />}
> Additionally, vite-plugin-svelte pulls in esbuild, "an extremely fast JavaScript bundler" written in go, as a dependency. I couldn't find exactly where it was used in the code or what it was doing, but it's what shows up in my terminal tab when I run yarn dev so it must be running down there somewhere.
And then:
> Even after a good bit of docs searching and code diving, I really couldn't figure out what library was actually performing that transpilation or how to configure it.
I smiled reading that and then this. Here you go, it's esbuild, which replaces babel. :-)
It was nice to follow the exploration while reading this article. As someone who is a future-ex React developer who uses Svelte in a personal project, I fully agree with the author on how Svelte feels.
> SvelteKit is still in beta, and hasn't reached its big 1.0 milestone yet. It is the successor to Sapper, which isn't extremely popular itself with ~25k monthly downloads on StackOverflow and never hit 1.0 itself.
I've used Svelte a lot for personal projects, but this quote right here is why I'm still waiting to use it in more professional contexts. I like that they are not rushing an incomplete 1.0, but I'm not sure about using beta software in production.
>I'm not sure about using beta software in production.
It used to be unthinkable that you'd use beta software in production. I think that change says a lot about the state of things, and why people are always complaining about framework churn in the industry.
Long time React and Angular dev here. I've tried Svelte a few times now, hoping it feels better and something clicks with me each time I try it. But, I just don't get it and give up every time. I end up spending more time trying to understand the design decisions and patterns of the framework, and discovering Svelte packages that aren't abandoned/outdated instead of building anything cool or useful. There is nothing you can't accomplish with React or Vue based frameworks IMO, so it then comes down to taste/preferences/goals.
I do think building a meta-framework is the right call for adoption, though. The only way to survive and thrive in the frontend-framework landscape in 2022 is to provide first class support for batteries-included full-stack offerings. The community seems to be in a return to server-side rendering approaches and client-only SPA is moving out of fashion.
I've been using Svelte as my main framework for the past two years. I'm still very happy with it and will continue to use it.
It has many advantages but the main reason for me is that it simplifies your front end code. It's not perfect by any means, but overall its cons are worth it IMO.
What do you use for UI components? I recently built my first SvelteKit project and using Tailwind to compose UI components vs. Vue+Vuetify was like writing binary by hand instead of using an expressive modern language that abstracts away 99% of plumbing.
What takes 10 seconds and 20 chars in Vuetify takes 10~100 minutes and multiple components/sub-components written by hand in Tailwind in Svelte.
Of course talking about Tailwind isn't Svelte/SvelteKit specific: I just couldn't find a remotely comparable UI library for Svelte so I gave up and stuck with Tailwind to get the project done.
It's come up more than a few times on the svelte discord - you should join and check out the projects that've been posted in the past. I don't think anybody ran into any major issues with Tauri + Svelte yet.
[+] [-] swyx|4 years ago|reply
i think this is the pull quote. the whole app (https://sveltekit-todo.ameo.dev/) with complete with drag and drop and crud, comes in at 59-75% the size of the base runtime of React (7k, 3k gzip) + React-Dom (121k, 39.4k gzip).
and js bundle size isnt everything - Svelte wins on other developer experience factors as well, and is just missing ecosystem as OP noted.
[+] [-] kirso|4 years ago|reply
[+] [-] richeyryan|4 years ago|reply
[1]https://dev.to/this-is-learning/javascript-framework-todomvc...
[+] [-] metta2uall|4 years ago|reply
[1] https://preactjs.com/
[2] "preact-compat adds somewhere around 2kb to your bundle size, but has the advantage of supporting the vast majority of existing React modules you might find on npm" https://preactjs.com/guide/v8/switching-to-preact/
[+] [-] square_usual|4 years ago|reply
(Or just React. React is pretty good, and vite comes with a React starter that's super good! You don't have to throw something out just because it's "old"!)
[+] [-] Ameo|4 years ago|reply
> I would recommend vanilla Svelte + Routify instead of Kit.
That sounds like a solid way to go as well. SvelteKit has some nice tools for 100% static sites that do stuff like generate pages at build time from markdown and stuff like that. But if your site is really simple, then that works fine.
[1] https://www.npmjs.com/package/@sveltejs/adapter-static/v/nex...
[+] [-] whiddershins|4 years ago|reply
If you want to do true front end though, I hear your pain. The biggest issue I had was I never could figure out how to make all my resource paths work with the static adapter, so I was put in the position of having to redo every image reference (for example) if I wanted to build static files. Pretty frustrating.
But if you are just doing SPA deploying to vercel for development I think sveltekit is just brilliant and just works.
[+] [-] hdra|4 years ago|reply
Its nice that it comes with a proxy `fetch` implementation that you can use to make requests to your API backend from the svelekit "backend", but there are many leaky API surfaces around it, esp when dealing with cookies.
The docs is also rather lacking regarding the many callbacks that can run on both server/client, though it is somewhat understandable given everything is still very much in flux...
[+] [-] djKianoosh|4 years ago|reply
[1] https://github.com/ItalyPaleAle/svelte-spa-router
[+] [-] uxcolumbo|4 years ago|reply
Just to learn new things or because Phoenix is lacking? Have you tried LiveView?
And can't you use React with Phoenix?
[+] [-] slantyyz|4 years ago|reply
[+] [-] midrus|4 years ago|reply
[+] [-] capableweb|4 years ago|reply
Besides that, I think the things you're looking for are listed here: https://sveltesociety.dev/components/
Never used Svelte/SvelteKit myself, but seems the framework takes a "some batteries included, others available" approach to the whole thing, which is one way to about it as well.
[+] [-] davedx|4 years ago|reply
I have the same issue with all these fancy "JAM-stack-ish" technologies like next, nuxt, vercel, etc, etc, etc. They are constantly iterating on the front end and its associated DX, which overall is a net good I think, but almost completely ignoring the back-end concerns.
Contrast with, say, meteor. Meteor came out in what, 2014 or something? And gave you a genuine full-stack development experience. There's not really been anything like it ever since. Weird.
[+] [-] mgkimsal|4 years ago|reply
I agree with your sentiment. I've run in to more than a few people who self-identify as "full stack" developers who do not understand what a database is, nor have ever set one up. Half-joking, but I think they're meaning because they do both javascript and css.
[+] [-] cpfohl|4 years ago|reply
The idea I usually promote is to use SK to wrap other APIs (in your control or otherwise) returning the payloads your UI code wants.
All that to say: You're not wrong I think you've identified a new category of tool, the full stack UI, perhaps?
[+] [-] lars_francke|4 years ago|reply
I know it's not GA yet so I don't want to complain and I'm happy to wait for the final release. The documentation is severly lacking (e.g. routing) and best practices are missing. I found the same as you: Most articles about SvelteKit don't talk about the backend/storage part at all. There is the template example app which has a bit of structure but that doesn't go very far, there are a few articles here and there but they mostly mock interactions with any further services.
So my verdict was: Fullstack, maybe-ish, but not for newcomers (which they also don't advertise for). You need to know what your're doing and which additional tools to use. And, as you point out, that's different in Django et. al.
[+] [-] l-lousy|4 years ago|reply
[+] [-] besil|4 years ago|reply
The two worlds can live together: I use Django and it’s features (including templating) along with Svelte, served from Django itself.
I wrote a post, if you are interested https://dev.to/besil/my-django-svelte-setup-for-fullstack-de...
[+] [-] duxup|4 years ago|reply
Everything else is a question of what else is involved, but that’s always what you want to know anyway right? Layers and complexity are a whole other topic IMO.
[+] [-] unknown|4 years ago|reply
[deleted]
[+] [-] Glench|4 years ago|reply
Right here! https://www.sveltesaas.com/ :)
I love using SvelteKit for full-stack apps so much that I decided to package up and release a template with all the stuff that most apps these days typically need.
[+] [-] rk06|4 years ago|reply
really? I remember webpack and co bringing 200mbs in node modules. while vite and esbuild bring around 40mb.
> Even after a good bit of docs searching and code diving, I really couldn't figure out what library was actually performing that transpilation or how to configure it.
Esbuild is doing it.
[+] [-] Glench|4 years ago|reply
Svelte components run super fast (no virtual DOM), have tiny build sizes, stellar interactive documentation, and the developer experience is fire. Svelte was also just voted the #1 most loved web framework in the 2021 Stack Overflow developer survey (it beat out React, Rails, Django, Spring, Laravel, etc ): https://insights.stackoverflow.com/survey/2021#section-most-...
I've also really been loving SvelteKit which isn't even out of beta yet.
Things I like about SvelteKit:
I love it so much I decided to package up and release a template with all the stuff most apps these days typically need: user auth, admin dashboards, etc: https://www.sveltesaas.com/Can't wait till SvelteKit hits 1.0!
[+] [-] throwaway675309|4 years ago|reply
[+] [-] stepbeek|4 years ago|reply
[+] [-] Ameo|4 years ago|reply
It may not be a fully-loaded solution like rails, but minimalism can have its own benefits.
[1] https://kit.svelte.dev/docs#routing-endpoints
[+] [-] midrus|4 years ago|reply
That gives you an idea of how deep the backend knowledge is some times. Scary.
[+] [-] qbasic_forever|4 years ago|reply
[+] [-] square_usual|4 years ago|reply
[+] [-] l-lousy|4 years ago|reply
[+] [-] fruit2020|4 years ago|reply
[+] [-] samuelstros|4 years ago|reply
Other than that, Svelte + SvelteKit is awesome. I would not choose React or Vue for small(er) projects.
[+] [-] zapt02|4 years ago|reply
* https://github.com/crownframework/svelte-error-boundary * https://github.com/denisstasyev/svelte-error-boundary
They only protect from component initialization errors but it's better than nothing. I think Svelte v4 will have more coherent error handling.
[+] [-] tarjei_huse|4 years ago|reply
The only thing I react to is the part about "It feels much like Rust vs. C++. Rather than adding layers upon layers to existing infinitely backwards-compatible software, it takes the best patterns and features and builds them from the ground up.".
Svelte bungled this in one place and that is in the html coding. For example Svelte has different syntax for if ({#if}, else ({:else}) and endif ({/if}. I end up looking this up in the documentation way too often - especially when not doing Svelte fulltime.
[+] [-] licyeus|4 years ago|reply
Re: `:else` syntax, I also made mistakes (`#` and `/` were familiar having worked with Handlebars/Mustache) until I internalized that `:` meant block continuation (also used with await/then/catch).
[+] [-] tumblen|4 years ago|reply
I sometimes miss the brevity of the React way (which can also be good and bad) for handling conditional code-blocks {visible && <Component>} or {visible ? <Component1 /> : <Component2 />}
[+] [-] pier25|4 years ago|reply
[+] [-] jraph|4 years ago|reply
And then:
> Even after a good bit of docs searching and code diving, I really couldn't figure out what library was actually performing that transpilation or how to configure it.
I smiled reading that and then this. Here you go, it's esbuild, which replaces babel. :-)
It was nice to follow the exploration while reading this article. As someone who is a future-ex React developer who uses Svelte in a personal project, I fully agree with the author on how Svelte feels.
[+] [-] sandreas|4 years ago|reply
I still love the fact that svelte is "compile time" and not "runtime" JavaScript.
What I'm missing a bit on all these reviews unfortunately automatic component testing (e.g. with Jest[2] or Jasmine)...
[1] https://pilabor.com/blog/2021/07/svelte-spa-with-typescript-... [2] https://koenvg.medium.com/setting-up-jest-with-sveltekit-4f0...
[+] [-] Zababa|4 years ago|reply
I've used Svelte a lot for personal projects, but this quote right here is why I'm still waiting to use it in more professional contexts. I like that they are not rushing an incomplete 1.0, but I'm not sure about using beta software in production.
[+] [-] wccrawford|4 years ago|reply
It used to be unthinkable that you'd use beta software in production. I think that change says a lot about the state of things, and why people are always complaining about framework churn in the industry.
[+] [-] canyonero|4 years ago|reply
I do think building a meta-framework is the right call for adoption, though. The only way to survive and thrive in the frontend-framework landscape in 2022 is to provide first class support for batteries-included full-stack offerings. The community seems to be in a return to server-side rendering approaches and client-only SPA is moving out of fashion.
[+] [-] pier25|4 years ago|reply
It has many advantages but the main reason for me is that it simplifies your front end code. It's not perfect by any means, but overall its cons are worth it IMO.
[+] [-] newsbinator|4 years ago|reply
What takes 10 seconds and 20 chars in Vuetify takes 10~100 minutes and multiple components/sub-components written by hand in Tailwind in Svelte.
Of course talking about Tailwind isn't Svelte/SvelteKit specific: I just couldn't find a remotely comparable UI library for Svelte so I gave up and stuck with Tailwind to get the project done.
[+] [-] newlisp|4 years ago|reply
[+] [-] FL33TW00D|4 years ago|reply
[+] [-] square_usual|4 years ago|reply
[+] [-] coretx|4 years ago|reply
[+] [-] powerlogic31|4 years ago|reply
[deleted]