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

101–110 of 194 posts

Re: Thoughts on Svelte

#101

Post by bananapub »

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…

Eh? Svelte supports TS and integrates it throughout, even type checking your request locals etc.

Re: Thoughts on Svelte

#102

Post by phpnode »

dsego wrote: post #58
marcelr wrote: post #50

Earlier quoted context omitted.

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.

Is xstate something like redux or mobx?

it's like a much more structured, and observable version of redux. observable in the sense that not only can you tell what has happened, you can also tell (and visualise) what can happen next

Re: Thoughts on Svelte

#104

Post by sonicgear1 »

synergy20 wrote: post #90

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.

Re: Thoughts on Svelte

#105

Post by pier25 »

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 kind of stuff becomes intuitive very quickly.

My criticism of Svelte is rather that they haven't gone deep enough into the compiler-based approach.

Would be great if there were something like .svelteStore files where you had all the automatic reactivity tracking without having to use a component. Or some kind of improvements into writing styles. With a compiler you can do anything you want and I think Svelte has been a bit timid, maybe to not scare people away.

For example Imba[1] also bet on a compiler-based approach (years before Svelte existed) and created their own language/framework/compiler. They have come up with amazing solutions to many problems. It's a shame they bet on Ruby aesthetics though and also that they aren't investing into marketing/docs.

Of course, one might argue that using a compiler is a bad idea for a number of reasons. And yeah of course there are objective issues to any approach, but you have to pick your poison. All in all, Svelte has made me tremendously productive compared to using other solutions for years (React, Vue, Mithril, Inferno, etc).

I will say though that I would rather use a solution that doesn't have any reactivity at all. Mithril and Imba have this concept of just "redrawing the whole thing" like a game GUI without having to worry about reactivity. Cognitively speaking, no reactivity is the best mental model IMO. With any reactive solution, it's very easy to fall into complex reactive dependencies which can be hard to track. The author of Imba has a video from 2018 where he talks about this[2].

[1] https://imba.io/

[2] https://www.youtube.com/watch?v=jwoApTLvRdQ

Re: Thoughts on Svelte

#106

Post by dceddia »

seanwilson wrote: post #95
dceddia wrote: post #79

Earlier quoted context omitted.

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

In Svlete (which doesn't use JSX?), are your templates type checked? Non-JSX approaches have to reinvent not only JavaScript loops and control-flow, but also the type checking that TypeScript gives? This feels like a big downside to me.

Yep, templates are type-checked, even though it's not JSX. Svelte is already running a compiler on the components anyway, to figure out the reactive stuff and to generate the minimal code required to update those specific spots in the HTML, so it can pass that code through TypeScript's checks. I'm almost certain they haven't reinvented their own TypeScript compiler here; I believe it's just passing off the type checking work to the existing TS checker.

One thing to mention or clarify maybe, is that Svelte's special syntax for {#if}'s and {#each}'s have real JS in the meat of them. Doing something like {#if a === 5}, the `a === 5` is parsed as actual JS. I really appreciated this after having used AngularJS (the 1.x versions) back in the day where it had its own half-baked flavor of JS for those embedded expressions and I was never sure if what I was writing would actually work.

I would say, if you've got a handful of minutes to spare, give the first few steps of the Svelte tutorial a try if you haven't (https://svelte.dev/tutorial). I think it does a good job of giving a feel for how it works.

It's written as a series of interactive examples where they teach a concept and you can try it in the editor on the page. I had a lot of aha moments when I initially went through it, having started off skeptical about the whole idea of going backwards to templates after React. There are just a lot of little things that worked "as they should", and moments that made me go "ohhh of course that just works, it's plain JS, I see."

Re: Thoughts on Svelte

#107

Post by dmix »

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…

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 you write normal non-reactive JS by default and wrap values in reactive() or computed() when you need reactivity.

The only syntactic downside is reactive values always need to use foo.value to access foo's data which causes occasional bugs when you forget it (and it tends to fail quietly) but it makes sense why it is that way. Maybe better LSP/IDE integration can detect that.

It's good to hear Svelte has .svelte files like .vue SFC. That would be the biggest thing I'd miss with React.

Re: Thoughts on Svelte

#109

Post by dunham »

dimmke wrote: post #39
TechBro8615 wrote: post #10

Earlier quoted context omitted.

What makes something good for small projects? Does that mean it's not good for big projects? What's the difference between big and small projects that makes Svelte good for one and bad for the other?

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…

I also noticed that facebook's Lexical, the successor to Draft.JS, is framework agnostic.

Re: Thoughts on Svelte

#110

Post by dmix »

h4ch1 wrote: post #83
jazzypants wrote: post #77

Earlier quoted context omitted.

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.

I think this is what you're talking about ? https://chrome.google.com/webstore/detail/solid-devtools/kmc...

Is there something similar for Vue?
Post reply on HN