Earlier quoted context omitted.
Interesting, my memory of reading about the Svelte magic reactivity was that it was pretty well explained that the only things 'reactive' would be things which were assigned to in the reactive statement. So if you want to update y on some changes to x, you do $: y = x And if you need something more complicated, a transformation perhaps, you put the logic in a function and assign y to the result of that function parse…
top level variables are reactive even when updated inside a function, just give it a try: https://svelte.dev/repl/44e3aece18294ddb834bcdfb4394af48?ver... ` let name = 'world'; const flip = () => name = name === name.toUpperCase() ? name.toLowerCase() : name.toUpperCase() $: console.log({ name }) Hello {name}! flip! `
Thoughts on Svelte
161–170 of 194 posts
Re: Thoughts on Svelte
#162Earlier quoted context omitted.
Or… y'know… just stop worrying about niggling details like this and just use Svelte. Svelte out of the box is much faster than React. You have to be well down the road of optimization before you hit parity, and optimized is almost never easier to understand. Computers don't care about code. They're satisfied with 1s and 0s. Code is for humans. The cleaner, the simpler, and the less of it, the better. More code = more…
I won't use Svelte for the simple reason that I don't like templating languages. Same reason I switched from Vue to React.
JSX is a templating language.
Re: Thoughts on Svelte
#163Earlier quoted context omitted.
It's what you consider central in a framework. For React, JS/TS is king. All markup and all CSS is subsumed in JS/TS. In Svelte, HTML/CSS is king, with the bare minimum of JS/TS necessary for any given task. With that in mind, of course React tends toward type definitions. Also explains why Svelte tends toward markup-oriented definitions.
React doesn’t care where or how you have your CSS.
Re: Thoughts on Svelte
#164I still don't fully understand reactivity, or how to handle complex reactivity use cases, but it's not like the story in react is much better.
Overall it was a joy to work with even though I don't think it's a perfect framework and may not have what it takes to unseat react as king.
Re: Thoughts on Svelte
#165I wonder how many JS/TS fronted frameworks are there.
Really only 10 or so (well "families" of JS frontend frameworks anyway) being actively used for new projects. I mean if you consider React/Next/Gatsby separate frameworks then there are more, but generally it's Angular, React, Vue, Svelte, Solid, Qwik, Ember, Redwood, HTMX. If you include other programming languages (Elm, elixir ?) then there are definitely many more
I'm sure I missed one or two actual front-end frameworks though
Re: Thoughts on Svelte
#166Earlier quoted context omitted.
I won't use Svelte for the simple reason that I don't like templating languages. Same reason I switched from Vue to React.
You mean you like your templates to be explicitly defined as a JS/TS render function. JSX is a templating language.
That's the difference. I don't want to relearn how to do for and if-statements.
Re: Thoughts on Svelte
#167I 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…
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.
Re: Thoughts on Svelte
#168Earlier quoted context omitted.
You mean you like your templates to be explicitly defined as a JS/TS render function. JSX is a templating language.
> 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
…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.
#StockholmSyndrome
Do you put onclick handlers on your divs to go to other URLs too?
Re: Thoughts on Svelte
#169
export let selected;
[aria-selected] {
background-color: blue;
}
Click Me
You can't do that with React. The lack of a VDOM is incredibly refreshing and I don't notice any performance issues.I occasionally come across articles expressing concern that it won't scale up for large applications and I find that confusing. React has considerably more footguns than Svelte. I've ported over several personal projects from React to Svelte and it always shaves quite a bit off the line count and makes the code less confusing (at least in my opinion). Granted, it's not perfect. Forwarding props is kind of a pain in the butt and the docs advise against using `$$restProps`. There's also some trickiness when it comes to overriding styles. The only way to override a certain style in a custom `` component is via a `style` prop, using CSS Modules, or a CSS-in-JS library like Emotion. I've been using Vite's built-in CSS Modules and it's working pretty well.
The scoped styles are really nice. If you structure your components right, make sure you're adhering to accessibility guidelines, and use semantic HTML, you can usually get away with styling the markup based on the element type or attribute without having to define classes on the elements.
Re: Thoughts on Svelte
#170I've been using Svelte and Sveltekit daily for a few years (back when it was Sapper!). I consider myself a product designer and not an engineer. With the new direction of Sveltekit, the absolutely worst thing is the documentation. The new server-side endpoints have confusingly similar nuances (certain things like fetch can be used on certain server-side files, but another kind of fetch can only be used on another). T…
Ah the good old days of Sapper :'), the changes to the filesystem based routing to +page.ts +page.svelte +page.server.ts was really annoying to figure out initially, and +hooks as well, where to use what, what's the best way to do protected routes, took some re-learning, but it is what it is, would take the plunge to avoid React xd
And there are many weird architectural decisions forced on you such as file-based routing which IMO are a deal breaker for anything but trivial projects. Even as a SSG, SvelteKit still lacks fundamental features such as easy to configure permalinks at the page level (which Jekyll had almost 15 years ago).
I've started experimenting with integrating Svelte with Fastify using Vite to get a good backend framework instead of using SvelteKit. It's still a bit ugly but it works: