Live data from Hacker News

Thoughts on Svelte

tyhopp.com

161–170 of 194 posts

Re: Thoughts on Svelte

#161

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! `

the inconsistency comes from the fact that this reactivity, triggered from inside a function, is not taken into account to build the dependency graph and ultimately decide in which order to process the statements

Re: Thoughts on Svelte

#162
post #127

Earlier 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.

You mean you like your templates to be explicitly defined as a JS/TS render function.

JSX is a templating language.

Re: Thoughts on Svelte

#163
post #123

Earlier 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.

Right, because it has very poor component-level isolation for styling. React basically punted on CSS, and that's truly not a blessing in its favor.

Re: Thoughts on Svelte

#164
I agree with pretty much everything the author said. I'll also add that one of my biggest complaints is that you can't use typescript inside the "markup section" (eg. for type casts or null assertions).

I 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

#165

I 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

Whoops. Too late to edit, but redwood is react on the frontend also. It's more of a "full-stack" framework too, but a "serverless" full-stack framework.

I'm sure I missed one or two actual front-end frameworks though

Re: Thoughts on Svelte

#166
post #162

Earlier 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.

> 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

Re: Thoughts on Svelte

#167
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

Re: Thoughts on Svelte

#168
post #162

Earlier 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

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

#StockholmSyndrome

Do you put onclick handlers on your divs to go to other URLs too?

Re: Thoughts on Svelte

#169
I've been using Svelte at the day job for almost 3 years (coming from a React background). We're using it for a pretty large application that's probably going to end up being at least 400K lines of code. I love how you can leverage CSS to visually indicate state changes:

  
    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

#170
post #18
post #16

I'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

I love Svelte but I've found myself disappointed by SvelteKit. Yeah it helps with rendering Svelte in the server and client but that's it.

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:

https://github.com/PierBover/fastify-vite-svelte-template

Post reply on HN