My Evaluation of SvelteKit for Full-Stack Web App Development

https://cprimozic.net/blog/trying-out-sveltekit/

by todsacerdoti • 5 years ago

194 118 5 years ago

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"!)

Ameo2• 5 years ago

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.

[1] https://www.npmjs.com/package/@sveltejs/adapter-static/v/nex...

square_usual5• 5 years ago

I tried the static adpater, but it still has issues as acknowledged here: https://github.com/sveltejs/kit/issues/1650

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...

hdra• 5 years ago

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...

whiddershins• 5 years ago

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.

slantyyz6• 5 years ago

Sounds like SvelteJS is a better option for you than Sveltekit.

djKianoosh• 5 years ago

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.

[1] https://github.com/ItalyPaleAle/svelte-spa-router

turtlebits• 5 years ago

svelte-spa-router is a hash based router and will work with any web server. Routify requires a rewrite rule for it to work.

uxcolumbo• 5 years ago

Why did you want to rewrite your Phoenix app as a SPA?

Just to learn new things or because Phoenix is lacking? Have you tried LiveView?

And can't you use React with Phoenix?

square_usual5• 5 years ago

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.

stepbeek• 5 years ago

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.

Ameo2• 5 years ago

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.

[1] https://kit.svelte.dev/docs#routing-endpoints

mathnmusic• 5 years ago

How do you run background jobs (either schedule-based or one-off like sending emails)?

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".

xcambar• 5 years ago

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.

square_usual5• 5 years ago

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.

qbasic_forever• 5 years ago

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.

midrus5• 5 years ago

Because for some folks being able to execute JavaScript in the backend is enough to consider it a backend framework.

That gives you an idea of how deep the backend knowledge is some times. Scary.

l-lousy2• 5 years ago

He mentions using Rust/Rocket and SQLite in the article, I think it was just focusing on the front end library

rk06• 5 years ago

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.

Esbuild is doing it.

fruit2020• 5 years ago

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.

capableweb7• 5 years ago

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).

newlisp5• 5 years ago

SSR. It turns out most devs can write reliable SPAs so you need some sort of hybrid.

pier256• 5 years ago

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.

FL33TW00D• 5 years ago

I've been looking at doing a Desktop GUI POC with something like Tauri and Svelte - has anyone had any success?

square_usual5• 5 years ago

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.

swyx2• 5 years ago

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.

kirso2• 5 years ago

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.

richeyryan• 5 years ago

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.

[1]https://dev.to/this-is-learning/javascript-framework-todomvc...

swyx2• 5 years ago

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:

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

metta2uall2• 5 years ago

If a React developer is concerned about code size they can use Preact which is about 5kB: 3kB for Preact core [1], and 2kB for preact-compat [2].

[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/

newlisp5• 5 years ago

What's the catch of preact? how can it be so small and provide the features/compability?

midrus5• 5 years ago

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.

capableweb7• 5 years ago

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.

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.

adamors• 5 years ago

Some gatekeeping is necessary because soon JS frameworks will have redefined everything making it impossible to converse.

davedx2• 5 years ago

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.

Words mean things.

midrus5• 5 years ago

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.

fullstackchris• 5 years ago

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.).

aeze• 5 years ago

I don't consider what he said gatekeeping, they were valid questions IMO.

davedx2• 5 years ago

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.

nefitty3• 5 years ago

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".

kirso2• 5 years ago

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).

lovasoa3• 5 years ago

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.

[1] https://github.com/lukeed/polka

lars_francke• 5 years ago

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.

slantyyz6• 5 years ago

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.

l-lousy2• 5 years ago

Did nobody read he was using rust/rocket and SQlite for the backend?

cpfohl• 5 years ago

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?

mgkimsal2• 5 years ago

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.

duxup• 5 years ago

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.

Glench4• 5 years ago

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?

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.

bufferoverflow3• 5 years ago

When I go to your link, it just says "coming soon".

besil• 5 years ago

I really feel your point. Django is my favourite framework but, as for Rails or Laravel, sometimes you need more reactivity to build an app.

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...

samuelstros• 5 years ago

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.

zapt02• 5 years ago

I agree with you error boundaries are a huge omission. You can do basic error boundaries using one of these two packages:

* 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.

Zababa2• 5 years ago

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.

wccrawford• 5 years ago

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.

Zababa2• 5 years ago

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.

sandreas• 5 years ago

Some time ago I created a svelte app with routify and scss[1] and it felt great, looks like sveltekit is the official successor of this stack.

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...

coretx• 5 years ago

Stop feeding the "full stack" trolls

tarjei_huse• 5 years ago

I love Svelte and find it refreshing.

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.

tumblen• 5 years ago

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 />}

licyeus• 5 years ago

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).

pier256• 5 years ago

Why not use a snippet that will write it for you?

Glench4• 5 years ago

Man, Svelte / SvelteKit is amazing.

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/

Can't wait till SvelteKit hits 1.0!

bufferoverflow3• 5 years ago

When I go to your link, it just says "coming soon".

Glench4• 5 years ago

Yep, it's not quite ready yet. Put in your email if you want to know when it's out — I won't spam you :)

throwaway675309• 5 years ago

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.

jraph• 5 years ago

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.

pier256• 5 years ago

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.

newsbinator• 5 years ago

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.

pier256• 5 years ago

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.

https://sveltematerialui.com/

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)

https://svelteui.com/

newlisp5• 5 years ago

Wouldn't https://tailwindui.com/ solve your problem?

newlisp5• 5 years ago

What does it simplifies in contrast to React?

pier256• 5 years ago

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.

canyonero• 5 years ago

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.

My Evaluation of SvelteKit for Full-Stack Web App Development

Related Stories