Readit News logoReadit News
infecto · a year ago
I love love love Svelte/Sveltekit. I am an experienced backend engineer and this is the first time I have worked in a FE framework that just clicked.

What I like:

- Not a whole lot of magic syntax.

- The structure of files feels like I am building a backend app, its quite logical and easy to parse through.

- Easy to get up and running, I am sure the decisions exist but I struggle historically with all the sidecar products that can be added into the frontend framework.

- It combines the beauty of native JS/TS with svelte. I can hydrate a store with my own hand rolled api calls.

- There is not a whole lot going on from a API/user perspective. I have stores and routes which are built into the folder structure. I am sure there is more but that gets me to a useful MVP.

husarcik · a year ago
I agree with everything you highlighted!

I'll add that my career isn't programming. However, Svelte let's me come back to my code base and understand everything, even after months. There is minimal framework related syntax to retain in my memory. Just have to know typescript well and that's it. Additionally, I don't need to retain all the rendering gotchas that other frameworks (eg, react) have. This has changed slightly with runes but I find them pretty easy to refresh on if I find im confused.

For me, this trade-off is well worth the limited availability of third party libraries. I wish someone would create a Laravel-like extension for Sveltekit. If I could just pull in user login flows, hashing, mail, etc all from organized Laravel-like docs, Sveltekit would be perfect for full-stack.

sureglymop · a year ago
I love Svelte, Kit not necessarily. It's nice but a bit too magic for me. I wrote about this before but I find it weird to write a load function that gets transpiled into a server and a client version and having to use `browser` to check if running in a browser context. Well it's not necessarily weird but it is too magic for me, e.g. an if statement checking this would get compiled away iirc.

On the other hand, I've been trying out astro with svelte and it's been super nice, especially with the ability to have runes in other typescript files.

benmccann · a year ago
Vite does statically replace the `browser` variable with `true` or `false` based on whether you're on the client or server, but this shouldn't affect the correctness of your code. It does allow Vite to remove any unused code, however. E.g. `if (browser)` turns into `if (false)` on the server and any code within that block can be removed. This can avoid shipping unused code to the client.

Astro is also built in top of Vite and the same thing happens there. If you reference `import.meta.env.SSR` it is statically replaced during build and unused code is tree-shaken out: https://vite.dev/guide/env-and-mode#env-variables

snapetom · a year ago
I’ve been a backend and data engineer who got my start in full stack. I’m working on a project and selected Svelte for the front end after trying to learn React. I agree 100%. Svelte is great. Even 5 with its warts isn’t as bad as react.

Kit on the other hand has been a major pain. You won’t need a webserver oh wait you do! You have to make drastic tradeoffs when choosing between full SPA and SSR render only. Server side pre-rendering seems like middle ground nightmare that I just I don’t think I can tackle sufficiently right now. I need to get an MVP.

The (browser) issue is a symptom of this greater problem - it’s just not clear what runs on the server side and what doesn’t. The documentation is very poor on this and blogs are flat out wrong.

miohtama · a year ago
- No useHook() spaghetti
ChocolateGod · a year ago
The only "magic syntax" I wish Svelte would borrow from other frameworks is a <template> tag to surround the component, in similar to how it already has <script> and <style>. You can do this with preprocessors but having it built in would be golden.

I like doing

<script lang="ts"> blah </script>

<style> blah blah </style>

<template> blah blah </template>

Sateeshm · a year ago
Isn't <template> an HTML element?
setheron · a year ago
Same

I just wrote about my experience here on a project https://fzakaria.com/2025/01/28/bazel-build-event-protocol-v...

Deleted Comment

Deleted Comment

nhumrich · a year ago
I loved svelte. But svelte5 seems to be a bit of turn off. It's not even the runes. Slots was hands down the best feature of svelte. And they deprecated it I still can't for the life of me figure out how the new way is supposed to work. The migration docs are very limited. And it's super weird that the parent has to intentionally render children instead of a slots? Also, why deprecate the on:event syntax?
jerojero · a year ago
You have a child and a parent component. The snippet is declared on the parent and rendered on the child.

So, you will have the snippet where you want it to be rendered on the child:

```child.svelte

<script> let { myFirstSnippet, mySecondSnipper } = $props(); </script>

<div id="Your first snippet goes here"> {@render myFirstSnippet()} </div>

<div id="Your second snippet goes here"> {@render mySecondSnippet()} </div> ```

Here we are declaring that this child takes 2 snippets called `myFirstSnippet` and `mySecondSnippet` and we place them wherever they might go.

And then on the parent we need to actually build those snippets:

```parent.svelte

<script> import Child from ... </script>

{#snippet myFirstSnippet()} <span>Hello from firstSnippet!</span> {/snippet}

<Child {myFirstSnippet}>

{#snippet mySecondSnippet()} <span>Hello from secondSnippet!</span> {/snippet}

</Child> ```

Here we are taking that `Child` component and rendering the two snippets that will go into it, as you see, you can either pass the snippet as a named prop or you can declare it inside the child component with the same name as the prop the child gets.

The end result of this will be a `Child` component that's rendered on the `Parent` with the two snippets inside this child component.

I hope that clears things up.

RadiozRadioz · a year ago
https://svelte.dev/docs/svelte/v5-migration-guide#Event-chan...

Yes, what a completely frivolous change that will only cause headaches.

Changes like this are why I dislike the mentality in the JS ecosystem. It was just cosmetic, and creates unnecessary churn. They seem to be addicted to changing things. They didn't like the old syntax? Though. What's done is done.

Don't make frivolous changes in frameworks damn it.

arichardsmith · a year ago
As someone who is in the midst of migrating from Svelte 4 to Svelte 5, I definitely feel the pain of syntax changes. However, I'd argue that `on:change` -> `onchange` isn't frivolous.

A real world example: in Svelte 4, I had a custom input component that wrapped an <input> element. To be able to do `<MyInput on:change={callback} />` took a bunch of event forwarding boiler plate (or magic `on:change` syntax to forward that one event). When I wanted to also forward blur events I had to go through the same process. Now in Svelte 5 I can just use `const { foo, ...rest } = $props()` then spread with `<input {..rest}>` and I get all events forwarded for free.

They could have kept the original `on:change` syntax, but that would have made property access more painful (who wants to call `rest['on:change']`?) and would have broken all my other components that I haven't migrated yet.

The same goes for slots to snippets. Being able to pass snippets around like props has allowed me to simplify tons of components where slots were limiting.

As a solo dev working part time on a Javascript project, I definitely hate some of the ecosystem churn, but this is one refactor I'm happy to do, and I'd say the same about most of the Svelte 5 changes.

benmccann · a year ago
Snippets are far more powerful than slots and so the change is not merely cosmetic. Snippets give you a way to create reusable HTML fragments within a component.
danielscrubs · a year ago
Had the same feeling. Because of that I moved on to no-build Preact. I’ve been happy with it so far, and I hope that it will get me closer to ”work for the customers, not for the vims of framework developers”.
gedy · a year ago
I'm in agreement, really loved Svelte 1, 2, and 3, but the v5 changes feel like a needle scratch unfortunately.

I love Rich Harris' work and appreciate what he gives to the community, but man he loves to rethink things.

tobr · a year ago
I’ve been using Svelte for several years, but haven’t had much time to dive into the many changes in 5.

Maybe someone here can shed light on something about runes that feels very off to me. The rune is on the wrong side of the equal sign? Like:

  let counter = $state(0);
Looks like a reactive value assigned to a variable, but that’s not at all what’s going on. It’s actually a reactive variable initialized to 0. So, for example, despite what you’d expect you can’t even move the $state call into a utility function if you’d have some reason to. Very counterintuitive to me, and not really touched upon in the docs as far as I’ve seen, but I have to assume there’s some practical reason why they did it this way.

I remember Svelte 2 (or 1? Can’t remember) had some weird things like this as well, where you’d think you could do something based on your experience from JavaScript but it just wasn’t supported. The label syntax in Svelte 3 was pretty brilliant because it was a clear indication that you shouldn’t expect normal JS rules to apply. It did have other problems that they appear to have fixed though.

jakelazaroff · a year ago
Have you tried it out? You can definitely move that $state call into a utility function (or a class field, or another file, etc).
tobr · a year ago
I can’t do this:

  const createCounter = () => $state(0);
  let counter = createCounter();
> $state(...) can only be used as a variable declaration initializer or a class field https://svelte.dev/e/state_invalid_placement (state_invalid_placement)

It has to be part of a variable initialization even though it looks like it’s creating a value.

ribadeo · a year ago
I fell in love with Svelte at v3.

The Svelte 5 rollout feels like a frogmarch. The v3 docs and repls and tutorials are gone, not api versioned. The new docs are bad, IMO, conpared to the clear documentation 3 and 4 had for years, with constant blurring with SvelteKit, which is a server framework, no thanks. The new docs font appears designed to make one cease reading. The new syntax is ugly and verbose and vague, IMO, but admittedly i am having difficulty with the documentation, which may be the real issue. If there were a translation guide from how one does things in Svelte 3 to Svelte 5 it might feel less like learning a new framework. Well, nothing lasts forever.

benmccann · a year ago
The v3/v4 docs can be found at https://v4.svelte.dev/

There is a migration guide as well as a migration tool that will migrate most of your code for you. You can also see what an individual file looks like when migrated in the playground.

yencabulator · a year ago
That link should be a bit more prominent, until the community has upgraded. Right now I think it's only at the very end of https://svelte.dev/docs/svelte/legacy-overview and I for sure was not aware of it, cursing the new docs layout when maintaining existing code.

Dead Comment

ggregoire · a year ago
I've yet to find a problem with React that would justify learning one of those new frameworks. I know it's popular to say React is bad on the internet, but have been using it for 10 years now and it's still going strong in my opinion.

(For some background, I used to code SPAs from scratch with vanilla JS and jQuery in the 2000s, then switched to backbone.js then Angular, before picking up React that solved all the design issues of Angular)

xrd · a year ago
The problems aren't with React itself. The problems are external to React. But, that's a huge problem.

You need to use a separate library for CSS with React. Svelte has the best way to deal with CSS built in. Which CSS library do you choose for your React project? There are so many libraries to consider, and so many bugs in each of those libraries.

You need to use a separate state management library with React. Svelte has state management built in. Which state management library do you choose for your React project? There are so many to consider, and so many bugs.

People think they want to use React because of the "ecosystem." But, they don't realize that React coerces you to use an ecosystem, an ecosystem that is full of buggy software and those bugs create impossible permutations of configuration issues and bugs (see Create React App). Bugs are not specific to React at all, all software has bugs. But, React forces you to use an ecosystem, and that's a bad thing. I write a lot of Svelte code with very few external libraries.

React does give you job security fixing all those bugs. I'll give you that. It is a wise career choice.

Svelte 5 is a big change. But, today, I refactored a bit of reactive code (which talks to a server and uses async code) inside a single template into an external shared component. That component has reactive code that can be shared across Svelte UI components. I could do that before with stores, but I had to be careful about how to use the reactivity. This new component isolates the reactivity in the right way and shares it in the right way. And, that share component is testable. It is an incredible experience when you get it.

snapetom · a year ago
I was trying to learn React shortly after hooks came out. Some in the community claimed you can drop Redux, which totally baffled me. Redux was far simpler.

Then it became “wait just don’t use hooks till we work out the issues.”

crab_galaxy · a year ago
> You need to use a separate library for CSS with React

I mean you can just use CSS. Personally I use css modules. Not very buggy or react specific.

> a separate state management library

Yeah I do use tanstack query to manage server state. Does Svelte include something similar out of the box? Otherwise it’s 1) url/query param for app state 2) tanstack query for server state 3) hooks for reusable state or local component state. Not many library bugs with that approach and tbh I’ve never needed something like redux or zustand.

esafak · a year ago
It's only job security if you are fixing another person's bug, otherwise management will rightly ask why you introduced the bug.
rk06 · a year ago
UseEffect(), dependency tracking, too much re-renders??

Problems galore in react, you should try out new js frameworks. Atleast vue and solid, to see what else is on the table

codinhood · a year ago
There are definitely problems with react, but I think his point was that they're not big enough to justify a change.

Though I agree trying other frameworks is a good practice. See what you're missing, or understand your preferred framework better.

mcv · a year ago
Every framework has its shortcomings, and React just as much so as any other. Learning other frameworks is always worthwhile. I've done Angular, Vue, React, and am currently looking into Svelte.
qudat · a year ago
https://bower.sh/react-is-bad-because-its-great

If you are building an SPA there is no reason to choose something other than React. Many of these other frameworks focus on apps that aren't full-blown SPAs. Htmx, deno fresh, astro, remix, next.js, these are all designed for users that don't want SPAs.

I think that's great, but often we conflate these use cases which cause mass confusion. Htmx is not great for highly dynamic "desktop class" web apps and the same goes for next.js.

lenkite · a year ago
React has kept changing its design approach and best practices every two years - probably to keep the bootcamps always running and churning the change industry.
Tadpole9181 · a year ago
Why write this comment? All you're doing is showing you don't actually use React? React absolutely does not change paradigm every two years.
croes · a year ago
Using it as a developer or as a user?
jerojero · a year ago
I really like svelte 5, personally I find the rune system to be much more explicit about what the code is doing and I prefer that.

I always felt that reading svelte code (prior to svelte 5) required to understand a sort of "magic syntax" very well, which was off putting.

I don't really mind having to declare reactive variables as `$state()`, it makes it very explicit that we want the variable to be reactive. It seems this change has also allowed for a lot more powerful and reusable code so I'm all for it. I guess that people who were already in the ecosystem might have found that they had to learn a lot of new stuff but imo this is very much a case of "might be a bit painful for our current users but it'll make life easier for everyone else in the future".

There's a few things I am a bit conflicted with but it's probably due to myself not really knowing how to solve a determinate problem rather than a problem with the framework itself. It's a bit difficult to get help sometimes.

rykuno · a year ago
Svelte(kit) renewed my love for web development. It gets out of the way when i want it to, is build on web standards so i'm not stuck on annoying "gotchas", and has all the tools I need to build something without pulling in 20 dependencies just to build a basic app.

After being a skeptic of svelte 5, its fully captured me.

pickle-wizard · a year ago
I recently started on a frontend project using Svelte, knowing nothing about frontend development. I've found it very easy to use. I had a few failed attempts at this project in the past using React, but I found it quickly overwhelming.

The tutorials on the website are excellent and that was all I needed to get started.