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

41–50 of 194 posts

Re: Thoughts on Svelte

#41

Post by achtung82 »

seanwilson wrote: post #32

What's a good frontend setup right now if you want strong static typing? I know Vue 3 supports TypeScript for example but it doesn't look like that's their core audience? I don't get the appeal of frameworks introducing template tags like `{#if showFoo}` vs JSX personally. You have the learn new syntax for things you already know how to do in JavaScript but with less expressibility, and JSX can at least be type check…

For Vue 3(at least for the composition api) ts support is very good and handles typing in templates and between components in a way that was a bit lacking in Vue 2.

As for the other ones React seems to be pretty good with TS and obviously Angular is TS only.

As for using templating logic over JSX, that is of course a matter of taste, but i find code becomes much cleaner when there is a clear separation of templates and logic, and with jsx its a bit too easy to blur that line.

Re: Thoughts on Svelte

#42

Post by lexhart »

cooperadymas wrote: post #40
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…

Missed opportunity... {#if showFall} Fools! {/if}

I have no idea what this guy is Tolkien about.

Re: Thoughts on Svelte

#43

Post by illiarian »

> 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 workarounds to make them work.

Re: Thoughts on Svelte

#44

Post by illiarian »

ko27 wrote: post #14
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/

That is a Javascrpt API, not pure CSS

Re: Thoughts on Svelte

#45

Post by azangru »

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.

> 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 discouraging the very natural, and often inevitable, concept of side effects, as well as by removing the concept of component's lifecycle (there is no idiomatic way of telling react to please run certain logic only once when the component mounts)[0].

0 - https://react.dev/learn/reusing-logic-with-custom-hooks#keep...

Re: Thoughts on Svelte

#46

Post by chrismorgan »

wildrhythms wrote: post #11
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.

It’s still explicit, just at the language level rather than the library level. (Svelte components aren’t written with JavaScript, but a language that extends JavaScript, repurposing $ labels and $-prefixed identifiers. Not appreciating that Svelte is a language and not just a library is a common cause for discomfort at the Svelte approach.)

The only part that is less explicit than some reactivity libraries is which variables’ changes will trigger re-evaluation.

Some libraries go full-explicit with the likes of foo.observe(foo => …) or computed(([foo]) => …, ["foo"]), requiring that you enumerate the properties to depend on. This is easy to get wrong, leading to bad reactivity.

Some libraries go full-implicit, tracking which properties were accessed during the call. This can be functionally perfect (provided you only use observable objects or primitive values—no Array, for example, leading to the amusing situation of some common patterns being syntactically heavier), but harder to reason about, and makes static analysis impossible in the general case, since property access can be non-local.

Svelte lies between the two extremes, needing no special syntax for it, but just noting which local variables are touched inside the block. This makes bad reactivity quite possible (non-local effects aren’t observed, including object nesting), but the language semantics of $ blocks are easy to learn, which mitigates this (though it’s still the most common sort of beginner error, when people try just using it rather than learning it). Static analysis and reasoning aren’t quite as simple as full-explicit, but are still straightforward in sanely-written code.

Re: Thoughts on Svelte

#47

Post by spikey_sanju »

I switched from Next.js to Svelte over a year ago. Since then, I have built medium-sized business products, and I can confidently say that Svelte is a joy to use. Their developer experience is on point. I agree with all the points made in the blog above, especially when it comes to working with forms. Svelte makes it easy with its inbuilt store, form actions, pageload, serverload, animations, and all of this results in a blazingly fast app. I even made an open-source version of my blog with SvelteKit.

Portfolio - https://www.spikeysanju.com

Source code - https://www.github.com/spikeysanju/spikeysanju.com

Re: Thoughts on Svelte

#49

Post by ianpurton »

seanwilson wrote: post #32

What's a good frontend setup right now if you want strong static typing? I know Vue 3 supports TypeScript for example but it doesn't look like that's their core audience? I don't get the appeal of frameworks introducing template tags like `{#if showFoo}` vs JSX personally. You have the learn new syntax for things you already know how to do in JavaScript but with less expressibility, and JSX can at least be type check…

You could look at Rust and Dioxus https://dioxuslabs.com/

Re: Thoughts on Svelte

#50

Post by marcelr »

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 wouldnt say this is a problem unique to svelte

Ive designed svg based editor systems in svelte & the crucial piece was xstate.

I had editors with 7+ states, that is copy line, edit point of line, split line, draw line, etc.. and with xstate, no matter how much i added features each file would be 25-50 lines with some outliers at 80.

Id highly recommend it.

Post reply on HN