Live data from Hacker News

Thoughts on Svelte

tyhopp.com

121–130 of 194 posts

Re: Thoughts on Svelte

#121
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…

I've never used it. My first thought is that $ label looks like callback hell, but without being able to step through the code easily to see where handlers are getting executed.

Syntax wise I don't like it because it makes the whole thing look like a simple variable assignment. Something that might be an expensive call looks like something that's usually a cheap operation.

Maybe I just think in terms of Java too much because it's the first language I learned, but I find all of the frameworks that use conventions like that hard to read. You need a ton of knowledge about how the internals work to understand what's happening in those scenarios. With Java, I always found the cost of writing boilerplate and declaring everything was paid back by how easy it was to read and follow existing code.

Re: Thoughts on Svelte

#122
post #107
post #65

Earlier quoted context omitted.

Co-opting my comment to add another thought. For me, Svelte's big superpower is that it does a great job of looking like plain JS sitting next to templated HTML, and the two just magically react to each other. The reason this is huge is because 90% of my coding is not Svelte. Usually I'm working on app logic, so I might go weeks or occasionally months without touching any UI code. With Vue I used to dread making UI c…

Vue 3 with seems to be much closer to straight JS than Vue 2's boilerplate structure, which sounds more like Svelte. https://vuejs.org/api/sfc-script-setup.html Re: magic in Svelte, I haven't used it but that sounds like something I'd be wary of. I like how Vue 3 takes a functional and explicit approach to defining reactivity. It's no longer grouped into buckets ala Vue 2 (data vs computed vs methods etc) but rather…

Oh neat, I hadn't seen Vue3/script-setup, it looks very similar to Svelte. The magic I referred to was basically just wrapping reactive logic around variable assignments, so if you're familiar with Vue3 then you it sounds like you may not consider Svelte magical at all.

Re: Thoughts on Svelte

#123

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 fu…

It's what you consider central in a framework. For React, JS/TS is king. All markup and all CSS is subsumed in JS/TS.

In Svelte, HTML/CSS is king, with the bare minimum of JS/TS necessary for any given task.

With that in mind, of course React tends toward type definitions. Also explains why Svelte tends toward markup-oriented definitions.

Re: Thoughts on Svelte

#124

I used Vue in the past and decided to use Svelte early this year, I do not need SEO or anything SSR, just the original SPA with CSR. then I found out Sveltekit is really a SSR-first design, and Svelte itself has no client side routing etc. While Vercel sells Sveltekit(and Next.js) to be CSR ready, I don't buy it, I don't need the complexity of SSR in the code when I just need a clean CSR, however you paint the SSR-is…

+page.js: export const ssr = false;

https://kit.svelte.dev/docs/page-options#ssr

I don't get why so many people seem to think SvelteKit is SSR-only or that it's some kind of Rubik's Cube of configuration to disable.

FYI: There's also export const prerender = true;

https://kit.svelte.dev/docs/page-options#prerender

Re: Thoughts on Svelte

#125
post #29

Earlier quoted context omitted.

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

In my opinion, this is yet another area where SolidJS is clearly the better option. The dev tools give you a full visual reactive graph. I like Svelte, but people like to pretend that it's easier than it is.

> full visual reactive graph

Is there actually a graph view? Or is it only the graph as a tree? I couldn't see it in the demo.

Re: Thoughts on Svelte

#126
post #45

Earlier quoted context omitted.

> what exactly is so hard about using hooks Oh, this I can tell. For one thing, it's very easy to get stale closures if one isn't careful. For another, hooks are a reactivity mechanism that is tied to the re-rendering of the whole component (what if you don't want to re-render the component? what if you only want to perform a side effect when a particular value changes?). Third, the docs are sowing confusion by disco…

> what if you only want to perform a side effect when a particular value changes? https://react.dev/reference/react/useEffect That is literally what useEffect is for! Describe your side effect, provide a list of values that you want the hook to watch for when they change. `useEffect(someEffect, [value1, value2, value3])` > the very natural, and often inevitable, concept of side effects React uses a functional program…

useEffect is an abstraction leak. You're defending boilerplate that a compiler can identify and eliminate for you.

Let computers do what they're good at so that we devs can concentrate on the actual problems being solved.

Re: Thoughts on Svelte

#127
post #27

Earlier quoted context omitted.

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

Or… y'know… just stop worrying about niggling details like this and just use Svelte.

Svelte out of the box is much faster than React. You have to be well down the road of optimization before you hit parity, and optimized is almost never easier to understand.

Computers don't care about code. They're satisfied with 1s and 0s. Code is for humans. The cleaner, the simpler, and the less of it, the better. More code = more bugs.

Re: Thoughts on Svelte

#128
post #105

I've been using Svelte exclusively for the past 3 years or so. I love it and will keep using it as my main solution for interactivity. It's fast to use and execute, produces small apps, and it's extremely economical in how you express components. The confusion the author expresses with $: reactive statements and store auto subscription with the $ are unwarranted IMO. It's really just a lack of familiarity but this ki…

Totally agree. I fully expect Svelte to start adding things like Nuxt 3's not requiring import statements for components. Hell, I could see in a couple years the script block allowing Rust with WebAssembly seamlessly generated but attribute binding logic looking exactly the same.

Compilers open up more avenues for productivity than most people in the web dev community realize.

Re: Thoughts on Svelte

#130

I wonder how many JS/TS fronted frameworks are there.

Really only 10 or so (well "families" of JS frontend frameworks anyway) being actively used for new projects.

I mean if you consider React/Next/Gatsby separate frameworks then there are more, but generally it's Angular, React, Vue, Svelte, Solid, Qwik, Ember, Redwood, HTMX. If you include other programming languages (Elm, elixir ?) then there are definitely many more

Post reply on HN