> 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.
yes am aware, but also in any realistic scenario, code splitting comes in well before the crossover point where that even remotely comes into question. this has been independently verified twice now:
[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/
The major difference seems to be that preact uses native browser events, unlike react which implements "synthetic events" - so preact may have issues in old browsers like IE8 (https://preactjs.com/about/project-goals/)
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 needed a lot more interactivity, especially with things like client side animations. LiveView is great if your usecase is sending fresh data - but if you want more interactivity, you have to use JS, and frameworkless JS is setting yourself up for pain for all but the simplest projects. The usual solution is ot use Alpine to add to LiveView but it didn't do enough for me. I'm a big fan of using static rendering as far as possible - I was "raised" on SSR Rails - but I know when I need an SPA.
You can use React. I recommend it in my GP comment.
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, precisely because I've been involved in maintaining codebases built without real full stack frameworks is why I say what I said.
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’m 100% with you on this. I’ve worked with many people who thought they’re full-stack developers just because they use these “full-stack” frameworks. Some of the guys didn’t know what a foreign key is but wanted to use reactive programming. Some of them didn’t know what’s a REST API but bashed the pattern and praised GraphQL. You get what I mean.
You're arguing about configuration vs convention. You can prefer batteries-included frameworks (convention). Other people can prefer a barebones approach (configuration). Either way, it's full stack if you can write code that runs on the server and code that runs on the client.
While I all generally think of a database being a part of full-stack, I'm not so sure that it makes sense to be a prerequisite. A database is just a tool for storing data. If all you need is in-memory data, flat file, or even no long-term data at all, I see no reason the requirement of long-lasting data to be a requirement for full-stack.
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?
"Why not also require third-party integrations" - it almost has to include that anyway, but.. the skill set required to understand and work with third-party integrations is almost certainly going to be a subset of 'front-end' or 'back-end' anyway. Mastery of client side and mastery of server side are distinct enough that those sort of 'what abouts' you raised seem to fall under the broad 'front/back' domains already, no?
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.
Clearly, we're not gonna reach any conclusion in this debate of what it means. So what's more fun than stop arguing over definitions? Polls, of course! Here is one: https://news.ycombinator.com/item?id=29811603
Convention is what you have in rails. Configuration is what you have in Django. What you have when you need to take 1k decisions per second and tie things together to kind of reproduce something usable as a whole is something totally different.
This word play isn't worth the time or effort. Shall we try to apply the meaning of full stack based on my own entry into web development in 1998 when N-Tier development was all the rage? I think not.
I really don't think it's fair to call it gatekeeping. The blog title is about using "Sveltekit for full-stack web app development" but if you want to make a full-stack web app, you need more than Sveltekit.
> but if you want to make a full-stack web app, you need more than Sveltekit.
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.
No it's not just it. That's small part of it. If you need to pull 30 other packages to your backend or frontend, then your "full stack framework" is not full stack. Check .NET, SpringBoot or even Laravel to some degree to see how "full stack" really looks like. It's entire ecosystem. You rarely go outside of that.
Can you develop modern app (with db access, caching, queues, messaging etc.) with just SvelteKit or just Next.js (and their official packages) as dependency? No, you can't. Not without pulling 20 other 3rd party packages. Thus, those are not full stack frameworks. They are nice and convinient opinionated frameworks, that speed up development, but you always relay on other packages to complete the stack.
Yeah, I guess we have different definitions for them. What you're talking about is what I'd call a "batteries-included" framework, which exists both as frontend, backend and full-stack frameworks. Full-stack just means that you can write your frontend and backend with it, not the amount of functionality it has within.
But backend means precisely these things. ORM, DB migrations, caching, etc. You need that for a solid backend. Of course not everybody needs messaging queues for example , but some frameworks support this out of the box and/or have years of integration with popular queues like rabbitmq to look back onto.
Imagine how many integration bugs were already solved in that time, which this new framework still has to iron out.
Time and experience mean something.
You make it sound like none of these things exist. Sveltekit is part of the NodeJS ecosystem, and there are mature libraries that do many of those things.
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?
Well, for you, apparently, it does mean those things. But for plenty of us, it doesn't. Why would I need an ORM/DB migrations if everything lives on disk? Why'd I need caching when I already run Varnish in front of the backend?
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.
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.
Interesting note: the Sveltekit home page never says "full stack" and describes itself as "framework for building web applications of all sizes, with a beautiful development experience and flexible filesystem-based routing". Almost like the SvelteKit folks are aware of the potential gotcha from calling it a "full stack" frameworks.
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)
Language does not matter. What matters are frameworks, tools, ecosystem, libraries and developers availability. All langues are good enough and shit at different things.
Yes, and we have a responsibly to guide that evolution. midrus said he was "surprised" that the meaning of full stack is changing to mean all the frontend and a few bits of the backend. I'm also surprised, and disappointed. To me, Django is full-stack. Meteor was full-stack. SvelteKit is not.
I disagree, I think it is a fair argument here. Sure, "full stack" as a pure definition would probably only mean at least one part display layer, one part backend layer... but in a framework sense, it's fair to include all these other important capabilities (translation, background jobs, etc.).
By the same standard, you are "cancelling" capableweb because you accuse them of doing something you find unacceptable (in a worse way, since most people would consider "cancelling" to be a worse accusation than "gate-keeping"). Not really a useful level for the word.
> Shunning an individual by accusing them of acting in an unacceptable manner is "cancelling" them isn't it?
Yes. But replying to an individual and telling them why they are incorrect and what you believe correct to be isn't shunning and isn't canceling. It's dialog. Reading interesting discussions is the reason I come here and participate. Echo chambers aren't interesting.
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.
> sveltekit provides some kind of thin layer on top of express
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.
lukeed has several extremely popular npm packages/libs which share a lot in common:
- 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.
Well actually SvelteKit has a concept of “adapters” which can bundle your app for different targets (ex: netlify, vercel, or node). If you target running your app on a node server, polka might be the default but it is trivial to replace with express
The issue lies more with the fact that most users will use what's shipped as default. You see that habit in every large framework out there. And that's why it's important to ship reliable, stable defaults.
If the Svelte subreddit is any indicator, a lot of Sveltekit devs don't use the Sveltekit back end. Most like to use serverless and 3rd party services for things like authentication and data storage.
I just want to take a second to share that Next.js is the worst thing I've ever used in my life. I am a react dev. They somehow managed to make Next.js harder for me to use than Django, which is in Python, which I've barely ever touched!
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".
Whitelists for network requests. Config files. Favoring a server even for a simple SPA. Hidden documentation pages: "Theres some stuff that no one ever uses but I guess click here if you want to see it."
There must be a reason though why a lot of companies are actually using this stack these days with SPAs and it seems like front-end is kind of merging with back-end by using the server-side rendering and server-less DBs with Prisma for instance?
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).
I just take that as a difference in the times. Meteor was from another era in development. We mainly did server side stuff and used backbone, knockout etc to do more complex interactions. Or just used javascript/jquery. Why would I use Meteor when I had Rails, Django, etc that was much more mature. It's different now because developers like more pain these days.
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.
IIRC Meteor also shot itself in the foot by using MongoDB as the default storage, at a time when there was deep (deserved) scepticism about the reliability of MongoDB.
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.
> Most articles about SvelteKit don't talk about the backend/storage part at all.
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.
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.
Not sure why you made this same comment twice, but yep, it's not quite ready yet. Put in your email if you want to be notified when it's out — I promise I won't spam you :)
> 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.
SvelteKit enables the BFF (backend for frontend) pattern nicely, meaning it can proxy and stitch together your actual API, exposing SPA-specific endpoints.
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.
Perhaps it means something different to the Ruby community. But I've most commonly seen "full stack" used to simply mean "both frontend and backend". So if it's running code on the server and the client then it's full-stack.
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.
Same reasons some people like their frontend or backend frameworks to have everything in one place, to have everything in one place.
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).
Because SSR has a couple of advantages depending on the use case.
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.
Technically true but in practice many SPAs will suffer form lower lighthouse scores which will affect page rank. Of course, this is not the case for SPAs that were optimized from the start, but that is rarely the case in the real world.
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.
> I think that change says a lot about the state of things
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.
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.
That's one of the issues with Svelte. It's a newcomer so the ecosystem is minuscule.
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.
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.
Pretty much everything except that the ecosystem is very young.
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.
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.
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.