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

11–20 of 194 posts

Re: Thoughts on Svelte

#11

Post by wildrhythms »

codeptualize wrote: post #8

Great article, it's good to read a nuanced take on a hot topic. I think the $ shows the tradeoff of reactivity. It makes updates sort of automatic which is great, until it's not. React on the other hand is a bit more explicit and cumbersome, until it's not. Rules of hooks vs rules of reactivity, it's all about managing triggers and dependencies, which easily gets complex. I think there might be a possibility for a mi…

Every time I go back and try Svelte I get put off by the $ paradigm for this reason: it's less explicit than React or Angular (rxjs). The Svelte 'state' kind of stands in as an observable, but simply managing a UI plus reactive state is already difficult, so I find the hand-wavey "reactive code block" to only add to the confusion and side effects.

Re: Thoughts on Svelte

#12

Post by h4ch1 »

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, the dependency graph can get really deep really quickly and it's very important to maintain a sort of heading, and plan ahead, because you can really lose yourself building with Svelte because of how little boilerplate there is.

Even then, 100% recommend it, documentation, and existing issues are sometimes lacking and information is hard to come by, but the Discord is helpful, even though it takes a lot of searching their "forums". Have great hopes for its' future, and it's really fun to build tools in Svelte, I remember giving all my Network Security assignments (transposition cipher, DES/AES, KDC) a nice, clean reactive front-end showing intermediate states of the data being passed around even though a simple cpp file would've sufficed, just because of how fun it's to use Svelte.

Re: Thoughts on Svelte

#13

Post by azangru »

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

Re: Thoughts on Svelte

#14

Post by ko27 »

jFriedensreich wrote: post #5

the problem that the transition api solves is that if you want to animate a dom node on removal you have to delay the actual removal until its animations are done. you even need this feature if you do all animations with pure css.

Not if you are using view transitions https://developer.chrome.com/blog/spa-view-transitions-land/

Re: Thoughts on Svelte

#15

Post by mhaberl »

> I'd use it again for personal projects, maybe not for large company projects if I was the architect.

Questions about large projects always arise when talking about Svelte. Did you / would you use it and why not?

I would certainly NOT suggest using Svelte on enterprise projects. Why not?

Because other people don’t do it, and that means that it is very likely that there are no (not many anyway ) experienced Svelte devs that are willing to work at/for some large company. React and Angular are safe bets in THAT space.

On the other hand, would I use it for personal projects or in a startup - absolutely. It's simple, it is fast and it is fun to work with.

Re: Thoughts on Svelte

#16

Post by yawnxyz »

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). The documentation style makes these nuances next to impossible to find, and I find myself having to Google or ask Chat GPT to help me figure those problems.

Otherwise, it's been a breeze to build with!

Re: Thoughts on Svelte

#18

Post by h4ch1 »

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

Re: Thoughts on Svelte

#19

Post by jamincan »

> I like the idea, but in practice I always ended up refactoring it out. There was always something else I needed to do after the Promise resolved or rejected prior to rendering, and I didn't want to run that logic every time I used the service.

> The logic also didn't belong inline in the rendering code, though. So where does it go?

I think the idea would normally be that you would handle loading the data in +page.ts and do any transformations there, and only deal with rendering and ui elements in the +page.svelte file.

Re: Thoughts on Svelte

#20

Post by pictur »

TechBro8615 wrote: post #10
lionls wrote: post #4

I share your view that Svelte is a great framework for small projects. It is also really useful if you want to build small standalone javascript widgets. I've used it at work to build a fast video testimonial slider for Shopify [1]. I really liked the component format as we could quickly integrate our code in the existing HTML layout. The Svelte built-in store has also been useful for us to manage the current state o…

What makes something good for small projects? Does that mean it's not good for big projects? What's the difference between big and small projects that makes Svelte good for one and bad for the other?

I think experimentation is one of them. being able to easily break backwards APIs to try new things in each version may not be nice for large scale projects. It's nice to try new things, but it can be a maintenance effort in terms of sustainability. and such projects are usually used for a large project so core development can go a certain line. (like google products for angular, facebook products for react). it doesn't seem to apply to this svelte. It is debatable, of course, that it is a negative thing. But I think it's a shortcoming.
Post reply on HN