My Evaluation of SvelteKit for Full-Stack Web App Development
cprimozic.net
cprimozic.net
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.
[1]https://dev.to/this-is-learning/javascript-framework-todomvc...
https://twitter.com/sveltesociety/status/1301168598988107776...
https://svelte-scaling.acmion.com/
https://github.com/halfnelson/svelte-it-will-scale
sveltekit has further opportunities for whole-app optimization but honestly given this research i lost interest bc its more than good enough
[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/
(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"!)
> 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...
In that thread, you can see some of the ugly workarounds people have to go through to make purely client-side apps: https://github.com/sveltejs/kit/issues/1650#issuecomment-984...
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...
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.
Just to learn new things or because Phoenix is lacking? Have you tried LiveView?
And can't you use React with Phoenix?
You can use React. I recommend it in my GP comment.
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.
Words mean things.
To create a full-stack web app you need a frontend and a backend. That's it. You can build a full-stack web app with just NodeJS and HTML files if you so wish (or even write HTML templates in your http handlers from the backend). Nothing in "full-stack" requires having a validation library in order for it to be full-stack, that would more be leaning towards the "batteries included" approach to a framework instead of strictly being about "full-stack".
When you frame your argument in a way that implies "it's not a real framework/tool for real life applications unless it has X" is almost exactly how I'd write an example of gatekeeping if I had to.
Point being (again), definitions seem to differ, and what you call "full stack" is what I call "batteries-included framework". Full stack simply means (for me) that it gives you a way of building frontend and backend code, but implies nothing about what functionality is included in either part.
The only thing is that Sveltekit isn't force feeding any particular library down your throat. When I moved over from Express, I pretty much just continued using the libraries I was already using.
If you look at how a lot of people actually use Sveltekit, it seems like they're outsourcing a lot of things like data storage and authentication to third party services. What benefit is provided to those users by baking in functions they don't need?
A full-stack experience...
Which clearly doesn't have the same meaning to all people.
Evidently :)
To maybe be able to consolidate the definition, I created a Poll: https://news.ycombinator.com/item?id=29811603
There are plenty of examples of full-stack apps out there. SveltKit has almost none of the features you need to build a full app.
It should be noted in my limited experience I found SveltKit to be really great, but it's barely 1.0 yet, let alone "full stack".
And as the reaction here shows, for lots of people "Full-Stack Web App development" means "spanning frontend and backend", not "frontend and backend and everything you could need for a complex product". And that seems to be shared by many other sources.
That being said, I am in the "this is full stack" camp due to prior art in the JS community. RoR/Django and their language communities have always been more about including all the parts (one could call it a "complete stack" style) and the JS community has always been about modularity. EmberJS strikes me as the last bastion of complete stack framework in JS (curious if there are others that are lesser known)
The problem we have in this industry, is that somebody reads these blog posts, and the next day at work they ditch the "legacy rails" and starts rewriting the monolith in sveltekit/nextjs/whatever because that's what he/she has been told is the modern way to do full stack.
No need to say those engineers will quit 1 year later after they realize the mess they've created with their lightweight and simple modern framework.
I've seen this too many times already.
It is not about gatekeeping. It is about engineers being humble and assume it is very likely that their code is very unlikely to be better tested, documented, cohesive and maintained than what you're given in the real full stack frameworks.
Of course you can build anything even in assembler if you want. The question is if that's the most useful thing to do with your company's money.
I wouldn't call it full stack without a database.
Once completed, we have our answer :)
That being said, the more I keep thinking about it, the less useful the term full-stack even feels. Why is front-end + back-end + database (+ other?) the full-stack? Why not also require third-party integrations? What about the hardware? Should the definition of full-stack expand as the options do, or should it stay static at whatever it's original usage was?
There's enough virtualization that 'hardware' itself is a somewhat elastic term. However, I've had to deal with 4 different devs in the last few months, all trying to get set up with one of two projects. Both are docker-based. But... "well, I'm on windows... I'm on WSL... I'm on Mac, but M1... I'm on Mac, but Mojave, and this doesn't work..., oh, I can't have 2 things running on the same port?" Unless every single person is on the exact same hardware/OS combinations, having some understanding of 'hardware and OS diffs' and how they may impact you may still be necessary.
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.
Imagine that react is like an airplane dashboard. Next.js is like adding a faceplate to the dashboard, jumbling up the buttons, then hiding some buttons because "best practice" and "optimization".
If you don't agree with the choices it makes, don't use it.
Its actually just interesting to observe.
I am a complete newbie but curious what are the seniors here think about this trend overall.
Meteor had to be sold in the end since they didn't get the adoption. But the "JAM-stack-ish" frameworks do get that adoption recently at least based on the funding rounds (kind of half serious here).
A lot of developers say that it's because the customer demands more, the interactions need to be better. None of that is the case in reality. The customer doesn't really care and at the end of the day most of these frontend framework users produce a worse experience unfortunately. High CPU, uncaught errors, poor messages, optimistic update bugginess, etc.
It doesn't use express, but something named polka [1], which is much less mature. Bugs in polka have caused downtime and remote DOS vulnerabilities in my sveltekit app multiple times.
They even show you how to set up an express server
- their twitter following is used to boost newly released packages
- they were released as alternatives to existing packages/libs with the flashy promise of being smaller, less complicated, faster
- negative feedback is rebuffed as "an attack"
- they're all very green
- they lack features and stability of the more mature packages they aim to supplant
- once released and popular, they cease getting frequent updates
Now, yes this is a generalization. It doesn't apply to all of their packages, and not at the same point in time. But there is a pattern there. Some quick diving into the author's Github account, and their more popular repos shows the pattern. It's also clear that this was a choice made by a Svelte contributor to use their own package for "official" support in Svelte Kit.
When it comes to polka itself, I just don't get why a maturing framework like Svelte would choose something whose only real advantage lies in micro-benchmarking porn [1]. Speculation aside, I'm surprised the Svelte team didn't look at that choice through a lens of higher scrutiny. Koa would have been an infinitely better choice in my personal opinion, and there are several community-driven setups [2][3] for it.
[1] https://github.com/lukeed/polka#benchmarks
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.
That's because a lot of Sveltekit users appear to prefer serverless and don't use the back end.
Personally, I like that Sveltekit's back end doesn't have batteries included.
Coming from Express, I was able to pick up Sveltekit pretty easily (although I have some quibbles with the documentation). I would have preferred that Sveltekit's back end use Express' Request and Response, but the Sveltekit devs have their reasons for not doing that.
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 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.
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.
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.
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...
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.
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
Can't wait till SvelteKit hits 1.0!
It may not be a fully-loaded solution like rails, but minimalism can have its own benefits.
How do you hold a websocket channel with the client to push real-time updates?
IMHO, "Full stack" means a lot more than "can talk to the database".
In the other hand, I don't see how you could use it as a primary backend, it just does not support anything beyond routing. Which is nice, not every tool should do everything (on the contrary) but it is important that the developers are not mistaken with regards to what SvelteKit is fit for as a backend.
That gives you an idea of how deep the backend knowledge is some times. Scary.
I prefer to compose libraries that carry exactly the functionality I need, and pipe them together myself. But I'd be a fool if I didn't realize that most people start projects today via some sort of framework that promises (and probably does) a "battery-included" sort of solution, where most of the pieces you'll use have already been put together for you, and you just need to write models, controllers and views (but your framework might call them something else).
The most obvious is SEO and being able to send HTML without any JavaScript.
Doing SSR is also simpler than a well made SPA, generally speaking. Your api can be reduced to post requests, or removed entirely. The routing and navigation is much simpler. Etc.
Other than that, Svelte + SvelteKit is awesome. I would not choose React or Vue for small(er) projects.
* 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.
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 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 />}
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).
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.
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...
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.
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.
I don't think it does. It could mean that people ship broken things all the time, or that beta software is way more stable than it used to be, or that deploying things is cheap, or that people really need new features
> why people are always complaining about framework churn in the industry.
Because they are parroting opinions based on a reality that doesn't exist anymore. For frontend frameworks, the state hasn't changed in the last 5 years at least. React is dominant, Angular is used by legacy/more conservative people. That's already most of the market. Add Vue in the mix (usually for smaller shops) and you're basically done. Svelte is still very small, SvelteKit even more. The situation is the same with backend. Java? Spring. Python? Django, Flask. Ruby? Rails. PHP? Laravel, Symfony. JS? Express.
People are complaining about churn because they're exposed to the bleeding edge of what's made. A lot of it will not stick and be forgotten. We're on a website called "Hacker News". The "News" means that it will be biased for new and shiny things. You want to do compile-time DI in Java and deploy it on k8s? That's bleeding edge, there are choices to make, and they're not obvious. In a few years the choice will probably be as obvious as Spring is today as these things become more and more popular. But not for now. Right now you're trying to predict the future, which is very hard. Especially since at the same time you're running a business, writing code, solving problems.
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.
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 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.
Personally I'm happy using Bulma with Svelte. I find most UI libraries tend to add too much bloat so I'd rather have something that only adds configurable CSS and just add as much JS as I need/want.
I used Vue+Vuetify some years ago. I wasn't very happy with it, but I agree Svelte needs something similar.
There are a couple of projects out there that add Svelte components for Bootstrap, Material, or IBM Carbon you could check.
https://github.com/bestguy/sveltestrap
https://github.com/carbon-design-system/carbon-components-sv...
There are also a couple of projects about headless (no CSS) components for Svelte although I only seem to be able to find this one (not public yet)
I guess something like Tailwind Headless (only available for React and Vue):
As a side note, Tailwind UI does include some components that require JS--that's what the Headless UI library is for. But it's also true that it's not a comprehensive component library; still missing things like a combobox or a date picker.
Other than greatly simplifying components, Svelte includes reactive primitives to build your models/stores with. No need for MobX, Redux, etc. It also includes animation tools which again would require third-party deps.