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

171–180 of 194 posts

Re: Thoughts on Svelte

#171

Post by dimmke »

ttfkam wrote: post #142
dimmke wrote: post #39

Earlier quoted context omitted.

Svelte doesn't use a virtual DOM and when it compiles, it only targets what you are specifically using it for. The thing with Svelte is that for a big project (like an SPA) you're going to end up using SvelteKit, because that's where all the development focus is for things like routing etc... and SvelteKit isn't nearly as settled. As in, there aren't developed "patterns" for doing a lot of things yet so it's a lot of…

Honestly, SvelteKit is pretty solid. They took their time trying to make consistent decisions rather than rushing 1.0 out the door and trying to backtrack later. All design decisions were out in the open on GitHub issues, and they spent a really long time looking at other frameworks and what they got right and wrong. The lack of navel gazing was refreshing.

I wasn't dissing SvelteKit. But I've been using it for about 6 months now. It's not perfect. There are currently some things that are very hard to do in SvelteKit that are not hard in other frameworks. It is what it is. That will change over time.

Re: Thoughts on Svelte

#172

Post by satvikpendem »

ttfkam wrote: post #168
satvikpendem wrote: post #166

Earlier quoted context omitted.

> JSX may remind you of a template language, but it comes with the full power of JavaScript. [0] That's the difference. I don't want to relearn how to do for and if-statements. [0] https://legacy.reactjs.org/docs/introducing-jsx.html

> I don't want to relearn how to do for and if-statements. …so you'll learn the weird details of render(…), learn how to manage updating a whole extra DOM on top of the existing browser DOM, learn to deal with the abstraction leaks of shouldComponentUpdate, React.PureComponent, useMemo, useCallback, and concurrent mode… …just so you can avoid learning {#if}{/if} and {#each}{/each}. Got it. TOTALLY makes sense. #Stock…

Do you understand that JSX is not React-specific? Vue and Solid both have it. Solid for example does not use a VDOM, and I'm quite happy with React as it conforms to a functional style unlike the vast majority of JS frameworks out there that have some random version of reactivity thrown in that makes it hard to manage local state, so yes, it TOTALLY makes sense. If you like Svelte, good for you, but again, I won't learn yet another templating language and have to go through yet another way of working out how `map`s and `fold`s work in this new DSL. Perhaps you should lay off the snark, but it looks like you have some specific fascination with JSX, as listed in your profile, so I don't think this will be a fruitful conversation.

Re: Thoughts on Svelte

#173

Post by naansequitur »

fenomas wrote: post #26

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…

Author here, this is a great point.

Added an update to the end of the article linking to this comment - https://tyhopp.com/notes/thoughts-on-svelte#update-2023-03-2...

Re: Thoughts on Svelte

#174

Post by naansequitur »

illiarian wrote: post #43

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

Author here, thanks for the context.

Added an update to the end of the article linking to this comment - https://tyhopp.com/notes/thoughts-on-svelte#update-2023-03-2...

Re: Thoughts on Svelte

#175

Post by pier25 »

pier25 wrote: post #167
pavish wrote: post #152

I agree with most of what the author says, except the part about reactivity. I attribute that sentiment to the author being less familiar with Svelte. I do think that people new to Svelte find it hard. It takes a while to understand how the `$` reactive statements work, and when and when-not to use it. When I first started working with Svelte, I tried to do things the React way and shared similar frustrations. Now th…

> One example is being able to pass templates around. Yeah I agree. It's not a big deal but I kinda miss this from JSX. There was some discussion about adding templates or even components inside other components but it all feels very inelegant and not very Svelty. https://github.com/sveltejs/svelte/issues/2940

Also this:

https://github.com/sveltejs/rfcs/pull/34

Re: Thoughts on Svelte

#176

Post by naansequitur »

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…

Author here, those are fair points.

For the part about increasing potential for bugs at scale, my mind was on scaling one or more teams and projects. Might have been better to use some other word than scale since it's so overloaded.

I find it difficult to think of patterns to introduce that would help teams align on when and how to use reactive `$` statements.

It's not a Svelte-specific problem by any means, but I do think Svelte's reactive statements would cause more pain than it would help ease as teams and projects get larger.

Re: Thoughts on Svelte

#177

Post by WuxiFingerHold »

After having used all of the big libs/framesworks I honestly only care about DX. They all get the job done, are fast enough and have some major or minor gotchas.

Svelte/Sveltekit has the best DX by far and only some minor gotchas, esp. reactive expressions as described in the article. Once you get how it works, Sveltekit is such an empowering experience, I can't imagine being more productive with anything else.

BTW, I'm using Sveltekit for an SPA, which is well documented, and skeleton.dev, a young but promising UI Tookit. Integration with native libs like echarts or three without any issues.

Re: Thoughts on Svelte

#178

Post by PlkMarudny »

I use Svelte for all the project under my supervision and the biggest problem I encountered is that functions defined in a component section are all executed when the component is created. This is painful sometimes, especially for new team members. Never used ``` {#await} ``` SvelteKit works. Reactivity is not a problem, but we use stores a lot, however (means global variables of a kind?).

Re: Thoughts on Svelte

#179

Post by tobr »

naansequitur wrote: post #176
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…

Author here, those are fair points. For the part about increasing potential for bugs at scale, my mind was on scaling one or more teams and projects. Might have been better to use some other word than scale since it's so overloaded. I find it difficult to think of patterns to introduce that would help teams align on when and how to use reactive `$` statements. It's not a Svelte-specific problem by any means, but I do…

I thought about it some more after writing my reply. I think a first approximation is that $: gets confusing almost as soon as you bring in more than one level of branching control flow. It’s better to do that with stores or encapsulate the logic in plain old functions.

But if you mostly have some values that need to be recomputed when other values change, or an effect that needs to re-run, it’s a convenient tool to use.

Post reply on HN