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

71–80 of 194 posts

Re: Thoughts on Svelte

#71

Post by rubenfiszel »

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 an easy mistake to make. It should be the default imho. That's because svelte is updating the whole DOM instead of that specific component without it, and it waits for the animation to be observably over to re-render the DOM .

For reactivity, it works surprisingly well but for big state updates, and a redux style of having one big state to update, we ended up splitting the state subparts that were independent in reactivity because otherwise you end up very easily into a reactivity hell (reactivity, calling other reactivity). We also have a lot of pattern to keep in check the reactivity on nested objects such as using object comparison checks (using fastEquals) to make sure the input object actually changed and it was not a leaf node unrelated to this component that triggered the change.

Overall, with the small team that we are, we could NOT have build such a complex and blazing fast superapp without svelte. On the other hand, we had to become expert at knowing how svelte would actually compile to otherwise we would have been stuck early at using the reactivity bindings after a certain scale.

[1]: https://github.com/windmill-labs/windmill/tree/main/frontend

Re: Thoughts on Svelte

#72

Post by nailer »

spikey_sanju wrote: post #47

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…

[deleted]

I confused vercel with nextjs.

Re: Thoughts on Svelte

#73

Post by mjtlittle »

nailer wrote: post #72
spikey_sanju wrote: post #47

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…

[deleted] I confused vercel with nextjs.

Wait where do you see this? I haven't heard of this and cant find any reference in the docs. Are you referring to the Vercel support?

Re: Thoughts on Svelte

#74

Post by muyuu »

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…

given that Svelte aims to be mainly pre-processed, how hard is it to combine it with more real-time solutions like Vue for instance? (you mention that you migrated from Vue2)

is it possible to use Svelte more for client-only or client-mainly views, and use other solutions for stuff that communicates more with the back-end? or do they get into each other's way?

Re: Thoughts on Svelte

#75

Post by fenomas »

runarberg wrote: post #62
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…

It is actually not that hard in CSS plus vanilla JS using stuff like the `animationend` event ( https://developer.mozilla.org/en-US/docs/Web/API/Element/ani... ). Of course svelte provides a much easier interface, then having to have to deal with event listeners.

Yes, great point - I meant to say that using CSS animations is hairy if one is using Svelte, not that they're hairy generally.

Re: Thoughts on Svelte

#76

Post by KronisLV »

fenomas wrote: post #65
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…

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…

> Usually I'm working on app logic, so I might go weeks or occasionally months without touching any UI code.

This is a very interesting point, because my experience is quite the opposite.

Most of the time changes to the apps that I typically worked on (ERP/CRM platforms) involved both DB migrations, as well as back end and front end work. And with the front end, changes to the logic almost always resulted in changes to the template, even if only within a single component. The only exceptions to this were validation changes (changed logic only) or visual bugs (changed template only).

I wonder what qualities of the system design this points towards, apart from coupling.

Re: Thoughts on Svelte

#77

Post by jazzypants »

vaughan wrote: post #29
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 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.

Re: Thoughts on Svelte

#78

Post by lionls »

shreedx wrote: post #68
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…

May I ask you how did you find the process of programming a Shopify app using Svelte? I have some experience with Svelte and am currently in process of starting development of a new Shopify app, but I basically decided to go with React as they have a lot of documentation and libraries (Polaris, AppBridge) available for it, while on Svelte I would have to do everything from scratch (or at least that's how I understood…

We are using next.js for the admin interface of the app. Works great with Polaris and AppBridge. Svelte is only used for the widget we are providing to the merchants.

Re: Thoughts on Svelte

#79

Post by dceddia »

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…

I don’t know if there was an implicit “besides Svelte” in there, but if you’re open to it, Svelte works well with TypeScript. The types flow into the HTML expressions too. I also like how little boilerplate there is compared to e.g. adding types to React component props. With Svelte, the prop typing is as simple as:

export let name: string;

export let age: number;

FWIW I kinda agree with you about the #if syntax. I like that you can still use a ternary with plain JS values like {Math.random() < 0.5 ‘heads’ : ‘tails’} though, and I would say I very much don’t miss having to use nested ternaries in React.

Re: Thoughts on Svelte

#80

Post by pkalinowski »

I picked up Svelte to build my first non-trivial app, which is flying navigation aid for hot air balloon pilots[1].

Svelte is much, much easier to grasp than React or Vue, especially when it comes to state management. I like that it’s super lean and it never confuses me what’s native Javascript and what’s the framework (pretty important for a non-developer me). And I love not having to write huge amounts of boilerplate code.

Reactivity sometimes gets more complicated than advertised on docs. For example, I have a bunch of functions where I manipulate an object and need to reassign it to itself (feature = feature) to trigger refresh on reactivity block. Sometimes it’s easy to miss and not know why reactive statements are not being updated.

Also, docs are pretty barebones. For comparison, I think Vue docs are explaining details in better and clearer way.

[1]: https://balloonnavigator.com

Post reply on HN