Svelte

"But newcomers won't need to learn all those things — it'll just be in a section of the docs titled 'old stuff'."

I was re-reading the original runes blog, hoping that I misunderstood it the first time I read it back in September.

But, it made me just as sad as it did last time.

I've gone from (over many years):

jQuery -> Angular -> React -> Vue -> Svelte

Always in search of the easiest framework to write in that gets out of my way and requires the least amount of code for the same outcome. So far, Svelte 4 has been the best, by a large margin, and React has been the worst.

It saddens me that Svelte 5 is going a React direction, and worse, is going to be "hiding" everything that made Svelte the best option in some dusty docs section called old stuff.

It moves developer experience to secondary, in the same way react does, and puts granular ability to control reactivity in its place.

A few examples:

export let is superior to $props. In typescript each prop is definable inline making it cleaner to read and less boilerplate to write as you don't have to write the types and then wrap it in a type to specify on the props import. Instead devs are going to inline it in the $props definition and make the code this long and superfluous type definition, as they do in react. I also believe export is closer to JavaScript itself, meaning you're not introducing new concepts, but teaching the language.

$effect is just useEffect without the dependency array, and is a source of constant confusion, questions, and pain for react developers. I know there are problems with the $: syntax, but it's rare I bump up against them, or can't fix them easily. For most everyone it'll require writing 13 more characters for every effect you write, bloat surrounding it, and separates derived and effects into two distinct things to learn for newcomers instead of one as it was before. (I've never liked the $: syntax tbh, it's weird, but it is def better than $effect and $derived imo)

$state is just useState and although I'm happy to have better support for arrays and objects, that could have been done without the unnecessary function that bloats the code. One of the reasons that React is so hard to maintain as it grows is that it grows not only with logical code, but boilerplate. And all of the hooks are the biggest culprit.

So, my biggest gripe is that it's requiring writing more code, to do the same thing, for the majority of developers. It feels like runes were created for the minority who needed that control, which is great that they have a solution, but then thrusted down the throats of every new and existing developer by hiding the "old" stuff that made Svelte, in my opinion, the best framework choice for going lightning fast.

It feels like a design choice intended to help migrate react devs to svelte, instead of make good choices for the developer experience of svelte, which is what svelte really excels at. I came to svelte because it was the closest to pure html, css, and JavaScript that I could find which also supported modern concepts.

I don't know why I wrote this. I guess I'm just hurt, because I love Svelte, and I'm sad to see it mimic frameworks that I've been trying to run from for poor DX, and I needed to tell people who might actually understand, cause my wife wouldn't 😅

Edit: Okay wow this got lots of comments. Loving the discussion, thanks all (on both sides, really enjoying it). Gonna have to take a break for a while to get some things done, will be back later.

I love using Svelte, but I find SvelteKit less intuitive. Do any of you use other back-end frameworks and architectures with Svelte as your front-end? If so what are your thoughts, pro's and cons on different approaches?

(I am pretty new to Svelte so take this with a grain of salt)

I have gone through a few threads and videos and everybody seems to be saying that you should almost always use SvelteKit and picturing Svelte as almost unusable which really confuses me.

I was able to very easily build a simple app only using Svelte and FastAPI that has authentication and stores user data and just works. When I tried to do the same in SvelteKit I was so lost and it felt so much harder to configure than Svelte where all I had to do was a single `routes.js` where I import all the pages and then a <Router {routes} /> in App.svelte and I was good to go. (And transitioning to Vite seemed very easy as well)

My question is am I missing something or is Svelte just perfectly usable on its own if you have an API developed (I am a back-end developer and always want a separate API that handles everything)?

Which backend do you guys use for svelte?

I'm Justin, and for the last year, I've been solo running Okupter (), a Svelte / SvelteKit focused development agency. Initially alongside my full time job, but now full time for about 4 months.

This post is a bit of sharing my journey, how I reached a monthly revenue of 6k USD for the second month in a row, and what I've learned along the way.

Okupter started as a blog on frontend development best practices (performance, accessibility, etc...), and then focused on Svelte and SvelteKit. I have a background in React.js, Next.js, etc... but immediately got hooked on Svelte and SvelteKit. I started writing about it, and then started getting requests for consulting and development work.

Up to a couple of months ago, my main services (those that were bringing in the most revenue) were Svelte / SvelteKit consulting (both in real time and asynchronous). I used to charge 150 USD / hour for a real-time consulting and 150 USD / month for asynchronous consulting (basically, I'd be available on Slack / Discord for a month to answer questions, review code, etc...).

At that time, I was turning around 2 to 3k USD / month, which was already great, but I was also working a full time job, so I didn't have much time to work on Okupter.

I also had a bunch of other services like web application, landing page, MVP development, etc... all focused on Svelte / SvelteKit, but I wasn't really pushing them, and they weren't bringing in much revenue; if not none.

The turning point

About two or three months ago, I came across a tweet by Brett from Designjoy, about how he would build a productized web development service. He was already doing great with his productized design service, so I decided to give his approach a try.

PS: I'm not affiliated with Brett in any way, I haven't bought any of his courses (yet), and I'm not getting any commission from him. I just really liked his approach, and it seemed to be working for me.

Brett's approach is to build the service around two weeks sprint, with a fixed price, and a fixed scope. The idea is to have a clear deliverable, and a clear price, so that the client knows exactly what they're getting, and how much it will cost them.

The process

I pretty much replicated exactly what Brett said in the tweet, with a few tweaks here and there on the technology stack (I'm focusing on Svelte / SvelteKit).

I put together this page , removed all other services from the website (except for the consulting services), and started linking to it from my blog posts.

From this point, things went organically. My website gets around 15k visitors per month (mostly organic searches to the blog), so I use it as my main marketing channel.

I started having a few requests for the sprint based development service, and started working on them. The first sprints were a bit rough, as I was still figuring out the process of scoping the sprints, communicating with the clients, etc... but I quickly got the hang of it.

Right now, I get about 2 paid sprint clients months, and the rest of the revenue comes from consulting services (both real-time and asynchronous).

What I've learned

The first and most important thing I've learned is that I should keep trying things. I can't remember the number of different experiments, services, etc... I've tried on the website, and most of them didn't work. But I kept trying, and eventually found something that seems to be working.

Another important thing in my journey was Okupter's blog. I've been writing consistently (3 to 4 blog posts per month) for more than a year now. It took me more than 5 months to get my first paid client from the blog, but it was worth it.

Plus, the fact that I write exclusively around Svelte and SvelteKit has helped me position myself as an expert in the field. I have many times started talking to a lead, and they already knew me from the blog, which made the sales process much easier.

Giving something for free can also be a great way to get clients. Up to a couple of weeks ago, I was offering free 15 minutes consulting calls about Svelte and SvelteKit. During these calls, I tried to provide as much value as possible, and I think it helped me get a few clients.

Finally, I think it's also important to build things on the side, free tools, SaaS projects, open source libraries, etc... At least at the beginning. Some of the clients I'm working with today came from either my SvelteKit SaaS boilerplate (), or my SST starter ().

What's next

At this point, I want to refine as much as possible the sprint based service, improve the process in order to provide the best possible experience to my clients.

The next step after that would be to scale up a little bit the number of clients I can take on the sprint service. I'm currently taking on 2 clients per month, but I'd like to be able to take on 4 or 5.

My plan is to reach a monthly revenue of 10k USD, and then, eventually, hire a Svelte / SvelteKit specialist to help me with the sprint service.

This text refers to Svelte v5 Next and currently it is not yet finished and therefore you should be lenient.

My Library

I have a private component library that I call "Blackbox". It is finely granulated, which means that almost every element is implemented as a separate Svelte component. And blackbox because it is based on anonymous classes. The design of the library is not very changeable. I use props to change something and not CSS. And the number of props was kept as low as possible.

Files & size

The project has a total of 232 files, whereby there are 147 Svelte components in real terms (not including tests and demos). The migration from v4 to v5 has reduced the size of files from 135kb to 126kb. The demo build file (JS) was with v4: 382kb - and with v5: 171kb (55% smaller)! But I think this will only be small if you use the new Runes mode.

I used the new strict runes mode and had to change 207 files (90%), which took 1 week. I didn't have to change a single line of CSS code.

Bugs

Almost all components work, although I still have 1 component (menu) that is not running smoothly. Some components that use CSS animations do not work. animate:flip does not work. Many errors are reported and corrected - and they exist. But I was able to get 99% of my library up and running. To my surprise, some components run better in v5 that were buggy in v4 (bugs also exist in v4).

VS Code

The VS Code Editor with Svelte 5 (I don't use TypeScript) is currently a nightmare. The syntax check is not good and every file shows errors. There is still some work to be done. It's not fun like this.

Runes

I was a bit skeptical about Runes - but overall they are OK. I only used $state, $derived, $effect, $props. The runes require more thinking than before: do I need $derived or $effect? Sometimes it was easier, sometimes harder. Sometimes I forgot $state. That's a bit more inconvenient - but somehow it makes it easier to understand. Thanks to $state, I could remove store from code. It's much better with $state.

Props

Svelte up to v4 has a design flaw in Props. The default values there are initial values (like in a class constructor) - and not default values if the values are undefined. This is widely unknown and can cause problems. In v5 this has FINALLY been corrected.

I didn't like in v5 that props that are bound can't have default values. I think that's a pity - that can be useful, but would get a bit more complicated with all the runes (haven't currently done that to escape $effect hell).

$effect HELL

I got on well with $: - but not with $effect!

I don't like $effect and that seems to be the biggest minus point at the moment. It triggered circular dependencies for me that ended up in endless updates that Svelte then stopped with an error. It was very difficult to understand and fix. For some components I had to make use of untrack even though it made no sense - for others it didn't.

One function in a component was so hard to fix that I'd better delete all the JS code and replace it with CSS - just to escape the darn $effect. I probably should have used untrack many times - but I don't get it. $effect disappoints me and reminds me of React hell. Hopefully it will get better later.

Snippets

I think snippets are good. Compared to slots (obsolete in v5!), it sometimes looks more complicated at first. However, if you think about it, Snippet is exactly what Svelte was missing - it allows you to pass templates to components (as props) or use them multiple times in templates. Good idea.

Only the {@render snippet()} is more annoying than <slot/>

Events

Finally, those darn createEventDispatchers will soon be history. I didn't like them before. Instead, you do what React does and pass the functions down instead of events up.

And this is already possible in v4. I recommend everyone to drop createEventDispatcher in v4 as well.

Events Mods

I have almost always used stopPropagation in my library. I removed it almost everywhere - except where it made sense. In v5 you have to do it manually. I think it's somehow better this way.

Summary

To summarize, Svelte 5 is an improvement overall and should have been like this from day one. But a lot is a matter of taste.

Compared to other frameworks, Svelte makes many things easier and better.

Libraries v4/v5

I don't know if it was worth it to start such a change. If Runes runs super-perfectly and v4 is compatible with v5, then it can succeed. But then there will be a split: old and new Runes code. Similar to how it was with Vue and how it was with React. Those who rely on the strict Runes mode will not be able to use an old library and will have to look for a v5 library.

I don't understand the difference between svelte and sveltekit. Let's assume i create a backend with rust that does some heavy calculations. It's exposed via a REST API.

What is the difference when using the API in svelte or in sveltekit?

Are the requests to the API routed through the sveltekit backend like that: Client->SvelteKit->REST API?

I've been a dev for a while now and had to use React for most of my day job though everything on the side I had built using Svelte. I quit my job last August to start my own company and decided screw it everything is Svelte.

I built the Chrome extension using Svelte + Crxjs + Rollup and our dashboard using Sveltekit. I've onboarded a dev who's only done React and he had no problem switching.

I swear I feel 20% more productive and 30% happier (lol) that I get to use Svelte instead of React tho the FOMO still hits everytime a cool new library comes out just for React.

Self-promoting: In case you're curious, this is the extension.

Personal and work?

Hey ,

I've been working on a design app called using Svelte 4. It's got around 60,000 lines of code and it's just me coding it. After watching all the talks on Svelte 5, I noticed something: none of the problems Svelte 5 is fixing have hit me. Svelte 4 works just fine for what I need.

Svelte 4 is simple and that's why I like it. It's perfect for smaller projects or if you're working alone like me. But I know Svelte 4 won't get updates forever. Eventually, it might not work well with new versions of Vite and other tools. That's a bit worrying.

I've seen people here talk about how they also like Svelte 4's simplicity. So, I had an idea: What if we keep Svelte 4 going as a sort of "Svelte Lite"? It could be for those of us who don't need all the fancy stuff in Svelte 5 and just want to keep things simple. Svelte 5 will be there pursuing to be the best solution for all, for bigger teams or more complex apps.

Does anyone else think a "Svelte Lite" version is a good idea? Or should we just move on with Svelte 5 and adapt to whatever it brings?

Would love to hear what you guys think.

Cheers!

Everyday I'm here just reading some posts about Svelte 5 is more verbose than Svelte 4, and etc etc etc. I'll not lie, this was making me sad to the point that I didn't even want to take a look at what the changes were.

Today, after a comment that shared the link below I decided take a look:

I thought that I'd need to abandon Svelte, maybe back to Thymeleaf and forget all existing JS/TS Frankenstein frameworks, once and for all, but, I ended up being surprised.

I found Svelte 5 became easier to read, code, understand, and support. Let me give you an example.

When I see onMount the only thing that come in my mind is the shell mount command. That name never made sense to me.

Check this out:

Svelte 4:

<script>
  let count = 10;
  $: doubleCount = count * 2;
</script>

<div>{doubleCount}</div>

Svelte 5:

<script>
  let count = $state(10);
  const doubleCount = $derived(count * 2);
</script>

<div>{doubleCount}</div>

I would much rather use the Svelte 5 $derived than this $: from Svelte 4. I don't program in Assembly (with all due respect to colleagues who program in Assembly), why would I want to keep using these symbols that don't make any sense?! Look that, Svelte is even easier to read and understand, much more Vanilla an improved so to speak.

I also liked the way Svelte 5 is fetching data too. Honestly, I think the code is much better, now. For me, this framework is starting to take on an air of maturity that I honestly didn't expect, positively speaking, and I hope they continue to improve things without losing their roots.

Sorry but, I'm loving seeing all these changes they're making ...

I just published a simple and quick cheat sheet for Svelte. Mainly for myself and my peers, but maybe someone will find it as useful as I did.

Although there is sometimes something wrong with the syntax highlighting, I hope it is readable. I tried to use the expressions that I use most often.

Let me know if you would add/remove anything.