Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Thoughts on Svelte

tyhopp.com

Post reply on HN
Print view View original

21–30 of 194 posts

Re: Thoughts on Svelte

#21

Post by Tade0 »

h4ch1 wrote: post #18
yawnxyz wrote: post #16

I've been using Svelte and Sveltekit daily for a few years (back when it was Sapper!). I consider myself a product designer and not an engineer. With the new direction of Sveltekit, the absolutely worst thing is the documentation. The new server-side endpoints have confusingly similar nuances (certain things like fetch can be used on certain server-side files, but another kind of fetch can only be used on another). T…

Ah the good old days of Sapper :'), the changes to the filesystem based routing to +page.ts +page.svelte +page.server.ts was really annoying to figure out initially, and +hooks as well, where to use what, what's the best way to do protected routes, took some re-learning, but it is what it is, would take the plunge to avoid React xd

I was also confused when migrating from Sapper 0.27 to SvelteKit 1.0.

The syntax changes were straightforward enough, but it left me with a project that didn't compile.

I started a new project and copied the source files there and it worked.

Re: Thoughts on Svelte

#22

Post by akaike »

azangru wrote: post #13
shanehoban wrote: post #6

I work with React (NextJS) and from working on things in Vue, and Nuxt - the one thing I absolutely hate about React is state management. If you have never used Pinia[0] (Vuex) with Vue, it's just so, so, so much easier. I'm using Zustand[1] with React as it is as similar as I can find to Pinia, but the whole hook system is just painful to work with... OK rant over. I haven't built anything substantial with Svelte, b…

I don't get it. From the example on Stackblitz[0], Pinia looks pretty much like redux, only with multiple stores instead of a single one. As far as I recall, Zustand is similar. What are the advantages of these libraries over redux (especially, the modern and opinionated redux-toolkit)? 0 - https://stackblitz.com/github/piniajs/example-vue-3-vite

I don't get it either. Plus, what exactly is so hard about using hooks? Hooks are awesome.

Re: Thoughts on Svelte

#23

Post by shanehoban »

azangru wrote: post #13
shanehoban wrote: post #6

I work with React (NextJS) and from working on things in Vue, and Nuxt - the one thing I absolutely hate about React is state management. If you have never used Pinia[0] (Vuex) with Vue, it's just so, so, so much easier. I'm using Zustand[1] with React as it is as similar as I can find to Pinia, but the whole hook system is just painful to work with... OK rant over. I haven't built anything substantial with Svelte, b…

I don't get it. From the example on Stackblitz[0], Pinia looks pretty much like redux, only with multiple stores instead of a single one. As far as I recall, Zustand is similar. What are the advantages of these libraries over redux (especially, the modern and opinionated redux-toolkit)? 0 - https://stackblitz.com/github/piniajs/example-vue-3-vite

I guess my main gripes are not with the libraries for state management themselves, but how managing rendering after state mutations occur. Pinia and Vue/Nuxt just do this effortlessly. Having to deal with hooks and useEffect in React is just a pain... in my opinion.

Re: Thoughts on Svelte

#24

Post by shanehoban »

akaike wrote: post #22
azangru wrote: post #13

Earlier quoted context omitted.

I don't get it. From the example on Stackblitz[0], Pinia looks pretty much like redux, only with multiple stores instead of a single one. As far as I recall, Zustand is similar. What are the advantages of these libraries over redux (especially, the modern and opinionated redux-toolkit)? 0 - https://stackblitz.com/github/piniajs/example-vue-3-vite

I don't get it either. Plus, what exactly is so hard about using hooks? Hooks are awesome.

I think that when you work with a framework like Vue/Nuxt where hooks aren't needed, they are not so awesome when you transition to working with React/Next. Everything just works as expected (with Vue/Nuxt).

Re: Thoughts on Svelte

#26

Post by fenomas »

I switched my game's UI from Vue2 to Svelte maybe a year ago, and I agree with almost all of the article.

One thing I think the author overlooks: the appeal of Svelte's built-in animations and transitions is that they work correctly when the element's lifecycle is being managed by Svelte. E.g. with code like this:

    {#if showFoo}
       Foo! 
    {/if}
When `showFoo` changes to false, Svelte will first play a flyout transition and then remove the element from the DOM, and it will correctly handle things if `showFoo` toggles back to true again before the flyout finishes, etc. You could do the same thing with CSS animations, but it would be hairy and you'd need to learn more about svelte internals than you probably want to.

Re: Thoughts on Svelte

#27

Post by lozenge »

shanehoban wrote: post #23
azangru wrote: post #13

Earlier quoted context omitted.

I don't get it. From the example on Stackblitz[0], Pinia looks pretty much like redux, only with multiple stores instead of a single one. As far as I recall, Zustand is similar. What are the advantages of these libraries over redux (especially, the modern and opinionated redux-toolkit)? 0 - https://stackblitz.com/github/piniajs/example-vue-3-vite

I guess my main gripes are not with the libraries for state management themselves, but how managing rendering after state mutations occur. Pinia and Vue/Nuxt just do this effortlessly. Having to deal with hooks and useEffect in React is just a pain... in my opinion.

You shouldn't use useEffect just to bring state mutations from the store into the component or to calculate "view model" from your state. Have a look at the new react docs.

https://react.dev/learn/you-might-not-need-an-effect

Re: Thoughts on Svelte

#28

Post by draw_down »

thegeomaster wrote: post #9
tobr wrote: post #3

> The $ label is one technical reason why I would be hesitant to adopt Svelte for larger projects. It's a core part of Svelte that you can't always avoid, and I think the potential for introducing bugs through it is high to start and very high at scale. I agree that it can quickly cause confusion, but I can’t really think of a situation where it can’t be avoided. I find it useful for simple things but try to avoid it…

This mirrors my experience too: use it for simple, component-local things and state, avoid it if things start looking spaghetti-like. Although it was very hard as a newcomer to untangle how exactly '$' works and how it differs from the reactive store API.

[dead]

Re: Thoughts on Svelte

#29

Post by vaughan »

h4ch1 wrote: post #12

I've been building a medium-scale web application that works as a configurator for 3D models (swapping objects/changing materials) and parsing/storing/syncing those configurations in real-time along with images, and a lot of metadata that needs real-time updates. To be honest, it's a breeze until it's not, my single file gets very long, lots of declarations, $: reactive = another reactive variable, derived stores, th…

I wonder if this is a visualization problem. Imagine if you could see the dependency graph visually.

Re: Thoughts on Svelte

#30

Post by davidjfelix »

I think Svelte/sveltekit (especially) has really pushed a lot of the ecosystem forward and I love the effort made to exposing platform primatives more explicitly while attempting to make the framework disappear. I think the store mechanism is really great but I have noticed a few usability complaints coming from react land.

The main one for me is typing props for a component feels extremely wack. In react I have a function, that function takes a type, I export that type and can import that type. In svelte I'm exporting the props individually? It's annoying to get the type declarations in one spot and make that easy to import for other components to use as intermediate typing. This is one of those things that I didn't even think twice about until my project reached a medium size and had multiple developers building out different portions -- it's inconvenient to scale and none of the workarounds feel good.

Post reply on HN