Live data from Hacker News

Thoughts on Svelte

tyhopp.com

111–120 of 194 posts

Re: Thoughts on Svelte

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

> That is literally what useEffect is for!

No, sorry; for useEffect to fire, a prop or a state needs to change; which means that the component is going to re-render. My point is that sometimes we want to observe properties passed to the component for side-effect purposes without re-rendering the component.

> Functional programmers believe in minimizing side effects.

In order to do something — anything — in the real world, we need side effects. Even Haskellers know this :-)

Re: Thoughts on Svelte

#112

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…

We had the same problem. Svelte would have been perfect if it only had a true SPA router. SvelteKit is too complicated for a simple SPA.

I used https://github.com/EmilTholin/svelte-routing with great success, though it looks like the maintainer has recently stopped maintaining it, and recommending sveltekit.

Still, I'd give try, it looks like people are still using it, and perhaps someone else will pick up the burden of maintenance, since there's clearly a ton of demand: https://github.com/EmilTholin/svelte-routing/issues/236

Re: Thoughts on Svelte

#113

> Svelte gives you an elegant way to use CSS in your components with tags, why not implement transitions and animations in CSS there? Because CSS has no hooks into HTML lifecycle. If you want to nimate something that appears in the DOM, or disappears from the DOM elegantly, CSS ain't it. That's why almost every single framework outside Svelte struggles with animations and employs increasingly bizarre and brittle work…

Vue handles it just fine with doing the hard work behind the scenes and just passing you some CSS classes to connect your animations to (and there are JS events to use as well if you need a JS animation). Main difference is Svelte gets the benefit of being able to do some fancier stuff like items changing order or doing more than just entering/exiting. Vue has this as well, but not as easy to use.

That being said I overall prefer the Vue CSS approach to animation, it inspired my brother and I to make https://animxyz.com which has been my most successful side project yet. We wanted to make it work for Svelte as well but they don't have the CSS classes so we can't hook into their events the same.

Re: Thoughts on Svelte

#114

We have a pretty huge codebase [1] in svelte for Windmill, probably one of the biggest SPA on it. We are an open-source n8n/temporal + retool alternative so we are building both an advanced flow builder and an advanced app builder. The article is on point. There is 1 caveat to animations that I'd like to add. Everytime we ended up using animation without the `|local` specifier, it broke completely our app, and that's…

What are your build times like? On a broader note, does anybody know of any build time comparisons for UI frameworks? Whenever I search for build time speed comparisons, I only find runtime speed comparisons...

When we dev, svelte uses vite which has instant hot-module-reloading. You edit your code and see the change live.

The build itself takes around 2 minutes, but that's mostly due to monaco and tailwind taking the majority of the time to be bundled.

Re: Thoughts on Svelte

#115

Earlier quoted context omitted.

What are your build times like? On a broader note, does anybody know of any build time comparisons for UI frameworks? Whenever I search for build time speed comparisons, I only find runtime speed comparisons...

When we dev, svelte uses vite which has instant hot-module-reloading. You edit your code and see the change live. The build itself takes around 2 minutes, but that's mostly due to monaco and tailwind taking the majority of the time to be bundled.

Thanks!

Re: Thoughts on Svelte

#116

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…

You can totally use SvelteKit without SSR.

https://kit.svelte.dev/docs/single-page-apps

Re: Thoughts on Svelte

#117

> 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.t…

For performance reasons, you might not want to wait for promises to resolve in your load function, though. My app got way faster once I switched to streaming promises.

Re: Thoughts on Svelte

#118

> 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.t…

For performance reasons, you might not want to wait for promises to resolve in your load function, though. My app got way faster once I switched to streaming promises.

I'm admittedly a JS/TS and Svelte novice, but I think you can still do the transformations within your load function, just making sure they're part of a promise you return.

Re: Thoughts on Svelte

#119
The author had a completely different experience from mine.

I adored the $: reactive variables, I liked the await blocks, and I found built in stores difficult.

This was as of a year ago, but still interesting.

Post reply on HN