Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Comparing Svelte and React

jackfranklin.co.uk

Post reply on HN
Print view View original

151–160 of 338 posts

Re: Comparing Svelte and React

#151

Post by jeswin »

deckard1 wrote: post #69

I'm a big fan of Svelte. I've raved about their documentation before, but it bears repeating: this should be the gold standard. You can read it all in a day. There are examples to follow right next to the documentation. Svelte is both succinct and powerful. I find this in contrast to React which is often baffling and incoherent. I say this as someone that has used React professionally for 6 years. They've changed the…

But I wish new frameworks stayed away from inventing new language syntax. Not only is it a cognitive burden on programmers, it throws all the tooling off.

From Svelte: {#each cats as { id, name }, i}

JavaScript already has facility for loops and mapping, and relying on that will automatically get you tooling/IDE support. React handles this aspect quite well, and to me that's a point in favor of React.

I do agree with your post - especially on hooks being a step backward.

Re: Comparing Svelte and React

#152

Post by thomaslord »

brailsafe wrote: post #146
deckard1 wrote: post #69

I'm a big fan of Svelte. I've raved about their documentation before, but it bears repeating: this should be the gold standard. You can read it all in a day. There are examples to follow right next to the documentation. Svelte is both succinct and powerful. I find this in contrast to React which is often baffling and incoherent. I say this as someone that has used React professionally for 6 years. They've changed the…

Sounds like you're describing Vue. Is their any substantial advantage over Vue that you're aware of? I think a lot of people, including myself, are just uninterested in arbitrarily and subtley different solutions to the same problem. I've used react, and it's just not as compelling as anyone made it out to be. Neither is Vue compared to React for that matter, but it appeals to me a little more.

So I'm a Vue developer who hasn't ever actually built anything in Svelte, but Svelte uses a really cool model that's completely different from Vue and React. Where Vue/React use a virtual DOM, Svelte is compiled to essentially vanilla JS. Instead of having render functions that fully replace a component, Svelte updates just the parts of the DOM that need to be updated. Because of the dramatically reduced overhead, pretty much any UI should run more efficiently under Svelte.

I'm still a big fan of the developer experience Vue provides and I'm locked into a framework for my work projects so I won't be switching those over any time soon, but I've been meaning to try out Svelte for a personal project some time.

Re: Comparing Svelte and React

#153

Post by dwohnitmok »

darksaints wrote: post #147
dwohnitmok wrote: post #136

Earlier quoted context omitted.

> It can easily be said that any UI is fundamentally a state machine This doesn't make sense to me as a criticism of Redux. Redux is a giant state machine. That's all it is. Actions are transitions and the store is the current state. The state transition table is the reducer. The Redux architecture (and the Elm architecture that inspired it) is about the purest expression of a state machine you're likely to find in a…

The problem with Redux is two fold: 1. The datastore is a massive global. This already brings to it many of the pitfalls that have caused programmers everywhere to avoid global variables like the plague. But in addition to that, for incredibly complex apps, it is a massive burden to maintain all of your state in one place, without any ability to encapsulate or localize trivial local states. Why do I need a global sta…

> The datastore is a massive global.

A single global state machine and a bunch of small state machines can be losslessly transformed from one to the other. And indeed Redux offers tooling to transform from one to the other depending on preference (this is the Redux Toolkit).

And indeed in that world they don't have to be bundled together. You can have separate state machines for different parts of the page.

> Robbed of the concept of benign localized state, all state transitions must be weaved through the entire complex functional tree that renders it.

As you say, this is really just a specialization of 1 right rather than a separate problem?

> They're called classes.

Classes of course can model state machines since any Turing complete style of programming can model state machines. However, they are significantly different from the classic representation of state machines in that the important part of representing state machines is that you can inspect their state. Classes are meant to be opaque; as you say their encapsulation is a feature.

But their opaqueness prevents the usual state machine composition, which is to link different state machines together based on the states they are currently in. Whether or not that's a good thing depends on the circumstances, but they make it painful when you really do want to represent things as a state machine proper, and not simply as a stateful component. And to the extent that you want a UI to be a state machine, that's a bad thing.

Of course not all parts of your UI should be a state machine, especially things that involve continuous states rather than discrete ones. For truly mind-numbingly benign stateful details (such as which frame a button should be in while performing an animated transition from one color to another) you can just put it directly in the React component and ignore the store altogether, and that's definitely where you really don't want explicit state machines, but rather encapsulated black boxes that are stateless from the perspective of the overall system (which is effectively what a component-based/class-based system looks like when interacting with a state machine).

Re: Comparing Svelte and React

#154

Post by nsonha »

IshKebab wrote: post #65

No mention of Typescript. You'd be mad to consider writing a significant app without it, and React has really great Typescript support - even templates are type checked properly thanks to JSX/TSX, and basically all tools support JSX these days. Vue doesn't come close to that, but it does look like Svelte is at least a bit better: https://svelte.dev/blog/svelte-and-typescript I'd still be wary that there are big cavea…

> React was designed for Typescript

this isn't true but JSX was made to be "just js" (obviously isn't true either) which contributes to it.

Re: Comparing Svelte and React

#155

Post by lhorie »

jeswin wrote: post #151
deckard1 wrote: post #69

I'm a big fan of Svelte. I've raved about their documentation before, but it bears repeating: this should be the gold standard. You can read it all in a day. There are examples to follow right next to the documentation. Svelte is both succinct and powerful. I find this in contrast to React which is often baffling and incoherent. I say this as someone that has used React professionally for 6 years. They've changed the…

But I wish new frameworks stayed away from inventing new language syntax. Not only is it a cognitive burden on programmers, it throws all the tooling off. From Svelte: {#each cats as { id, name }, i} JavaScript already has facility for loops and mapping, and relying on that will automatically get you tooling/IDE support. React handles this aspect quite well, and to me that's a point in favor of React. I do agree with…

I agree that gratuitous syntax differences are tiring, but in this case, there's actually a very good reason why it's not just using JS. When it comes to reactive systems, you need to be able to statically analyze control flow structures in order to compile to efficient code. In JS, a for loop is a loop, but so is array.map, Object.keys and someLib.each. The loop could be hidden three layers deep in a higher-order function composition from some third party library, it could be tail call recursion, etc. Dealing with this sort of complexity when writing optimizing compilers is very very hard, compared to coming up with dedicated loop syntax, because at any point it's possible there's a value of polymorphic type, a Proxy, a getter/setter side effect or some other crazy JS shenanigan going on.

This is why, for example, Solid.js does control flow through and components instead of map/ternaries even though it uses JSX.

Re: Comparing Svelte and React

#156

Post by rubatuga »

andy-dev wrote: post #102
KaoruAoiShiho wrote: post #99

Earlier quoted context omitted.

Is animations just as easy in svelte?

Svelte has animations and transitions already built into it, do yeah, it's real easy

I found animations a bit of a struggle, especially when combining multiple of them. There were performance bugs with some of the combined animations, and the Svelte documentation didn’t make it clear how animations could affect things like the focus on a text box.

Re: Comparing Svelte and React

#157

Post by axguscbklp »

nawgz wrote: post #127
dan-robertson wrote: post #111

Earlier quoted context omitted.

I don’t think any of your arguments in favour of react are sufficient. JQuery had a huge number of libraries and could be used to make websites that worked. Angular was backed by Google who generally have more clout than Facebook. I think most comparisons would find that jQuery does not solve the same problems and that angular resembles the kind of steaming brown thing one might find behind a cow—and that’s before yo…

Your counter points don’t check out too much though? > jQuery Just not possible to compose, which makes full applications difficult. No answers for state management or such either, completely a different scope than frameworks > Google more clout than FB In some domains sure, but I’ve never understood how people don’t think FB are masters of UI. There is probably no org with more UI clout than FB, they built their own…

Oddly, despite the immense resources that Facebook has available, Facebook in a browser is slow and glitchy, especially after the most recent redesign.

Re: Comparing Svelte and React

#158

Post by jeswin »

lhorie wrote: post #155
jeswin wrote: post #151

Earlier quoted context omitted.

But I wish new frameworks stayed away from inventing new language syntax. Not only is it a cognitive burden on programmers, it throws all the tooling off. From Svelte: {#each cats as { id, name }, i} JavaScript already has facility for loops and mapping, and relying on that will automatically get you tooling/IDE support. React handles this aspect quite well, and to me that's a point in favor of React. I do agree with…

I agree that gratuitous syntax differences are tiring, but in this case, there's actually a very good reason why it's not just using JS. When it comes to reactive systems, you need to be able to statically analyze control flow structures in order to compile to efficient code. In JS, a for loop is a loop, but so is array.map, Object.keys and someLib.each. The loop could be hidden three layers deep in a higher-order fu…

I understand why they did it, but there are alternatives.

Such as:

   import * from "svelte";

   // ...omitted for brevity.
   {
     svelte.each(cats, ({ id, name }) => 
Hello {name}
)
   }
   // ...omitted
This is easy to parse and transform, while being fully within JS.

Re: Comparing Svelte and React

#159

Post by acemarke »

darksaints wrote: post #147
dwohnitmok wrote: post #136

Earlier quoted context omitted.

> It can easily be said that any UI is fundamentally a state machine This doesn't make sense to me as a criticism of Redux. Redux is a giant state machine. That's all it is. Actions are transitions and the store is the current state. The state transition table is the reducer. The Redux architecture (and the Elm architecture that inspired it) is about the purest expression of a state machine you're likely to find in a…

The problem with Redux is two fold: 1. The datastore is a massive global. This already brings to it many of the pitfalls that have caused programmers everywhere to avoid global variables like the plague. But in addition to that, for incredibly complex apps, it is a massive burden to maintain all of your state in one place, without any ability to encapsulate or localize trivial local states. Why do I need a global sta…

Note that we have _always_ advised that you should avoid putting literally every piece of state into the Redux store, and we do _strongly_ encourage keeping local state in components:

- https://redux.js.org/faq/organizing-state#do-i-have-to-put-a...

- https://redux.js.org/style-guide/style-guide#evaluate-where-...

- https://redux.js.org/tutorials/essentials/part-2-app-structu...

Re: Comparing Svelte and React

#160

Post by lhorie »

jeswin wrote: post #158
lhorie wrote: post #155

Earlier quoted context omitted.

I agree that gratuitous syntax differences are tiring, but in this case, there's actually a very good reason why it's not just using JS. When it comes to reactive systems, you need to be able to statically analyze control flow structures in order to compile to efficient code. In JS, a for loop is a loop, but so is array.map, Object.keys and someLib.each. The loop could be hidden three layers deep in a higher-order fu…

I understand why they did it, but there are alternatives. Such as: import * from "svelte"; // ...omitted for brevity. { svelte.each(cats, ({ id, name }) => Hello {name} ) } // ...omitted This is easy to parse and transform, while being fully within JS.

FWIW, I did a mini-study a while back about the different possible syntaxes. It turns out there's more than meets the eye wrt what control flow structures need to do, and there are also DX reasons why the dedicated syntax might be more desirable: when you consider all permutations of loop flavors - w/ else clauses, keyed, exposing index, etc - the DSL consistently came out on top in terms of succinctness and readability (for an average developer familiar w/ algol-like syntax).

There are also technical reasons why `svelte.each` would be problematic, namely the fact that it is a compile-time concept which does not necessarily compile correctly if you move the call into a library, unless you have an extremely sophisticated compiler (aka: a slow compiler)

Post reply on HN