8 ms·

I am a big fan of Svelte - as a backend dev who is also responsible for writing frontend code, I saw a massive productivity jump when we moved our website from

by spuz 3y ago

I am a big fan of Svelte - as a backend dev who is also responsible for writing frontend code, I saw a massive productivity jump when we moved our website from React to Svelte. But the premise of the article is just not true - you do need to fundamentally understand how Svelte manages the state of your pages. You need to understand how and when an update to the state in one location gets reflected elsewhere. Most of my time is spent trying to work out why state is or is not updating as I expect. Not helping this, it's not particularly well documented. For example, recently I had to learn about the onDestroy function which accepts as an argument a lambda. The docs [1] state that the lambda is run when the component is "unmounted", but offers no further information about exactly how or when this occurs. There is no official documentation on all the various lifecycle stages of a component and how or when each transition occurs. I find myself simply relying on a lot of trial and error or asking in the Discord forum. [1] https://svelte.dev/docs/svelte#ondestroy https://svelte.dev/docs/svelte#ondestroy

sesm 3y ago
I'm curious now, what disadvantages of React could outweight the entanglement of reactive state management and undocumented lifecycle. I could understand that you could have the same issues with state management if you were using MobX with React, but undocumented component lifecycle sounds crazy.
- adamnemecek 3y ago
  Out of the box, React provides much less than Svelte. Also the mental model of Svelte is one tenth of React. I was able to start building stuff after like 3 hours of reading Svelte tutorial. I have done the same with React several time and every time I left with “I kind of see how to do things but I’m unsure how to build larger things with this”.
  - fullstackchris 3y ago
    but there are literally libraries on top of libraries to immediately provide in react what svelte might provide "out of the box". the best thing too is that these hooks are all open source - so you can either install a package directly, or pick and choose and install whatever hook you need. idk, i'm dying on the hill that react is unopinionated for a reason, i think it can be morphed and molded to so many use cases
    - mschild 3y ago
      I agree, but what that freedom in reality often means, at least from what I've seen, is a patchwork of dozen libraries and dependencies that make large scale projects more complex than they need to be. That's not the fault of React, but it is a consequence of it.
      - fullstackchris 3y ago
        and when you run into something svelte simply cannot do?
        adamnemecek 3y ago
        Like what?
    - adamnemecek 3y ago
      That’s the point. I don’t want libraries on libraries. I want an integrated approach. How are the use cases for these libraries different?
      - satvikpendem 3y ago
        Then why not Angular?
        adamnemecek 3y ago
        Because it’s terrible.
        satvikpendem 3y ago
        But it's the integrated approach you're talking about, what is terrible about Angular?
        adamnemecek 3y ago
- spuz 3y ago
  I said there was a reactive state model that you have to get your head around in Svelte, but this is still much easier and simpler to do than it is in React in my experience. I'm not trying to pursuade anyone either way but I do want to dispell the notion that the mental model of Svelte is so straightforward that there is nothing to "learn" as the article claims because that will eventually lead to disappointment. Like I said, I think Svelte as a technology is great, so I'd rather people had the right expectations if they are going to give it a go.
ilrwbwrkhv 3y ago
You should check out Imba. It is the sanest of the lot. The only issue is they have very few updates and the development is not transparent so it didn't spark much of a community.
- azeirah 3y ago
  I wrote some Imba code for fun a while ago. Nothing special, just an HTML clock or something. It was quite nice to work with, really simple. Though I was just not convinced by its ecosystem, who's gonna use this?
fullstackchris 3y ago
I kinda find this a weird comment... you say productivity is way better than React but then go on to say you still sometimes need to resort to the Discord forum to figure out what is going on (!) To be fair, React used to have a documentation problem as well, but at this point I think anything and everything under the sun is documented excruciatingly well. Of course people will comment I'm shilling React, but, reading the top comment, its kind of like trying to shill Svelte but immediately coming up short.
- spuz 3y ago
  My comment is mainly to criticise the article and specifically the original title (You Don't Need to "Learn" Svelte), not to advocate for either Svelte or React. Yes there is a state model that you need to get your head around to work in Svelte just as there is in React and unfortunately, that task isn't made easy by the official documentation. But like I said, I still much prefer Svelte and would choose it over react 99 times out of 100.
dimmke 3y ago
>But the premise of the article is just not true - you do need to fundamentally understand how Svelte manages the state of your pages. I agree with this. Like the example in the linked article about reactive blocks: "Svelte automatically tracks dependencies, and you only need to label a code block as reactive ($:). It'll run the code any time those dependencies change." There's a huge caveat to that, it only does that with primitives. Which might seem obvious if you've been a developer for a while, but not at all obvious if you are a new developer. React has always taken the approach of asking you to explicitly declare state and use special methods to update it (either with setState or useState when hooks became popular) for exactly this reason, whereas in Svelte sometimes you need to actually reassign a mutated piece of state to itself so it gets picked up by this system like `foo = foo` I think it's a reasonable tradeoff, because most state can be stored in simple primitives like strings and booleans. Regarding lifecycle methods and Svelte, it's literally based on the DOM. Is the component leaving the DOM for whatever reason? Then onDestroy will fire. The same as you can treat onMount as a callback that fires as soon as the component is added to the DOM. https://svelte.dev/repl/b946424a56d84a63a09856bc3df5803e?version=4.2.0 https://svelte.dev/repl/b946424a56d84a63a09856bc3df5803e?ver... I think part of where things get tricky is that Svelte and SvelteKit are so melded together, unless you're 1. only using Svelte and not SvelteKit or 2. Are doing something really advanced and complex, you probably don't need lifecycle methods. And even then, you probably only need onMount. A custom onDestroy can be used to manually remove something from memory, but it's mostly not needed. I agree though the docs should be better.

by spuz 3y ago

sesm 3y ago

I'm curious now, what disadvantages of React could outweight the entanglement of reactive state management and undocumented lifecycle. I could understand that you could have the same issues with state management if you were using MobX with React, but undocumented component lifecycle sounds crazy.

adamnemecek 3y ago
Out of the box, React provides much less than Svelte. Also the mental model of Svelte is one tenth of React. I was able to start building stuff after like 3 hours of reading Svelte tutorial. I have done the same with React several time and every time I left with “I kind of see how to do things but I’m unsure how to build larger things with this”.
- fullstackchris 3y ago
  but there are literally libraries on top of libraries to immediately provide in react what svelte might provide "out of the box". the best thing too is that these hooks are all open source - so you can either install a package directly, or pick and choose and install whatever hook you need. idk, i'm dying on the hill that react is unopinionated for a reason, i think it can be morphed and molded to so many use cases
  - mschild 3y ago
    I agree, but what that freedom in reality often means, at least from what I've seen, is a patchwork of dozen libraries and dependencies that make large scale projects more complex than they need to be. That's not the fault of React, but it is a consequence of it.
    - fullstackchris 3y ago
      and when you run into something svelte simply cannot do?
      - adamnemecek 3y ago
        Like what?
  - adamnemecek 3y ago
    That’s the point. I don’t want libraries on libraries. I want an integrated approach. How are the use cases for these libraries different?
    - satvikpendem 3y ago
      Then why not Angular?
      - adamnemecek 3y ago
        Because it’s terrible.
        satvikpendem 3y ago
        But it's the integrated approach you're talking about, what is terrible about Angular?
        adamnemecek 3y ago
spuz 3y ago
I said there was a reactive state model that you have to get your head around in Svelte, but this is still much easier and simpler to do than it is in React in my experience. I'm not trying to pursuade anyone either way but I do want to dispell the notion that the mental model of Svelte is so straightforward that there is nothing to "learn" as the article claims because that will eventually lead to disappointment. Like I said, I think Svelte as a technology is great, so I'd rather people had the right expectations if they are going to give it a go.

ilrwbwrkhv 3y ago

You should check out Imba. It is the sanest of the lot. The only issue is they have very few updates and the development is not transparent so it didn't spark much of a community.

azeirah 3y ago
I wrote some Imba code for fun a while ago. Nothing special, just an HTML clock or something. It was quite nice to work with, really simple. Though I was just not convinced by its ecosystem, who's gonna use this?

fullstackchris 3y ago

I kinda find this a weird comment... you say productivity is way better than React but then go on to say you still sometimes need to resort to the Discord forum to figure out what is going on (!) To be fair, React used to have a documentation problem as well, but at this point I think anything and everything under the sun is documented excruciatingly well. Of course people will comment I'm shilling React, but, reading the top comment, its kind of like trying to shill Svelte but immediately coming up short.

spuz 3y ago
My comment is mainly to criticise the article and specifically the original title (You Don't Need to "Learn" Svelte), not to advocate for either Svelte or React. Yes there is a state model that you need to get your head around to work in Svelte just as there is in React and unfortunately, that task isn't made easy by the official documentation. But like I said, I still much prefer Svelte and would choose it over react 99 times out of 100.

dimmke 3y ago

>But the premise of the article is just not true - you do need to fundamentally understand how Svelte manages the state of your pages. I agree with this. Like the example in the linked article about reactive blocks: "Svelte automatically tracks dependencies, and you only need to label a code block as reactive ($:). It'll run the code any time those dependencies change." There's a huge caveat to that, it only does that with primitives. Which might seem obvious if you've been a developer for a while, but not at all obvious if you are a new developer. React has always taken the approach of asking you to explicitly declare state and use special methods to update it (either with setState or useState when hooks became popular) for exactly this reason, whereas in Svelte sometimes you need to actually reassign a mutated piece of state to itself so it gets picked up by this system like `foo = foo` I think it's a reasonable tradeoff, because most state can be stored in simple primitives like strings and booleans. Regarding lifecycle methods and Svelte, it's literally based on the DOM. Is the component leaving the DOM for whatever reason? Then onDestroy will fire. The same as you can treat onMount as a callback that fires as soon as the component is added to the DOM. https://svelte.dev/repl/b946424a56d84a63a09856bc3df5803e?version=4.2.0 https://svelte.dev/repl/b946424a56d84a63a09856bc3df5803e?ver... I think part of where things get tricky is that Svelte and SvelteKit are so melded together, unless you're 1. only using Svelte and not SvelteKit or 2. Are doing something really advanced and complex, you probably don't need lifecycle methods. And even then, you probably only need onMount. A custom onDestroy can be used to manually remove something from memory, but it's mostly not needed. I agree though the docs should be better.