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

131–140 of 338 posts

Re: Comparing Svelte and React

#131

Post by alfonsodev »

dan-robertson wrote: post #111
alfonsodev wrote: post #75

Earlier quoted context omitted.

I think many people adopted React because Facebook was behind it, and using it in production, the ecosystem is huge, there is a react- package for everything you can image, there is also react-native, I don't like it, but there it is, you can reuse the knowledge to build native mobile apps. Now Svelte, I haven't been following, but I think the creators are working in what's going to be next and even better framework[…

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…

> that it was the first (widely known) framework with those merits

Yep, and my interpretation is that, that (the widely known part) happened because it was backed by Instagram first (if I recall correctly) and then Facebook.

And not to invalidate your point but to add another speculation on why React became more popular...

Yes, Angular was backed by Google, but not used in production in massively successful product as Facebook, or Instagram, and I remember also about writing Directives, Services and it wasn't very inviting for third party packages.

When react came out, I remember the selling point was "it's not a framework, it's a library", "it's the V of MVC" and I think that strategy also helped to let the community create all the other pieces, and long term have a richer ecosystem.

Re: Comparing Svelte and React

#132

Post by lhorie »

nsonha wrote: post #128
lhorie wrote: post #124

Earlier quoted context omitted.

You can't get away from mutable state. Redux, for example, just hides the big `state = newState` mutation but it's still very much there. When a library/framework uses mutable state, it's not that they're saying immutability is an anti-feature. They're just being pragmatic in the sense that mutation has to happen anyways and they consider explicit to be better than implicit. (With that said, some people do argue that…

you're arguing based on a very mechanical understanding of why immutable state is important. Immutability is just a solution to the actual goal which is controlled side effect as someone put in the other comment. Given a side effect (a piece of data is mutated), I need to know what code caused it and when. When you casually throw assign statements everywhere that question becomes really hard to answer.

Not necessarily. Discoverability is a function of colocation, not of immutability. One can write convoluted Redux monstrosities spanning a multitude of files where it's difficult to mentally follow how a dispatched action translates into state deltas (potentially because of too much higher-order abstractions, but also because one action may affect multiple reducers, and that in turn may affect a multitude of React tree nodes because Context or whatever). Svelte reactivity generally only staying within a single file (with some exceptions) is one approach to align system limitations with "pit of success" in a way that happens to use explicit mutation idioms.

Re: Comparing Svelte and React

#133

Post by nsonha »

darksaints wrote: post #130
k__ wrote: post #118

Earlier quoted context omitted.

Yes. To be fair, after looking how the whole Redux story went, I think the mainstream simply wasn't ready for immutable state.

Redux was shit. It made apps less comprehensible and less performant. Immutable state isn't really a great idea for stateful applications, and UI development is an almost purely stateful activity. It can easily be said that any UI is fundamentally a state machine...the state of your UI defines the set of actions that are available to it, and the actions taken define the future state of the UI. This is not just true f…

> you're far more likely to have to change state than you'll have to change how that state is rendered. This puts redux-style solutions squarely on the wrong side of the expression problem

Could you please elaborate this?

Re: Comparing Svelte and React

#134

Post by nsonha »

lhorie wrote: post #132
nsonha wrote: post #128

Earlier quoted context omitted.

you're arguing based on a very mechanical understanding of why immutable state is important. Immutability is just a solution to the actual goal which is controlled side effect as someone put in the other comment. Given a side effect (a piece of data is mutated), I need to know what code caused it and when. When you casually throw assign statements everywhere that question becomes really hard to answer.

Not necessarily. Discoverability is a function of colocation, not of immutability. One can write convoluted Redux monstrosities spanning a multitude of files where it's difficult to mentally follow how a dispatched action translates into state deltas (potentially because of too much higher-order abstractions, but also because one action may affect multiple reducers, and that in turn may affect a multitude of React tr…

could you stop saying redux, in my other comment I said the solution could be anything from react's setState to old-style encapsulation.

The point is, it's kind of odd that someone'd put mutating states in their tutorial proudly as a "feature". It's a thing that you do very conservatively at best.

Re: Comparing Svelte and React

#135

Post by nsonha »

lhorie wrote: post #132
nsonha wrote: post #128

Earlier quoted context omitted.

you're arguing based on a very mechanical understanding of why immutable state is important. Immutability is just a solution to the actual goal which is controlled side effect as someone put in the other comment. Given a side effect (a piece of data is mutated), I need to know what code caused it and when. When you casually throw assign statements everywhere that question becomes really hard to answer.

Not necessarily. Discoverability is a function of colocation, not of immutability. One can write convoluted Redux monstrosities spanning a multitude of files where it's difficult to mentally follow how a dispatched action translates into state deltas (potentially because of too much higher-order abstractions, but also because one action may affect multiple reducers, and that in turn may affect a multitude of React tr…

> Discoverability is a function of colocation, not of immutability

That's one way to do it, tying discoverability to coding convention (which is usually how collocation is enforced), as opposed to being an inherent property of the code.

Re: Comparing Svelte and React

#136

Post by dwohnitmok »

darksaints wrote: post #130
k__ wrote: post #118

Earlier quoted context omitted.

Yes. To be fair, after looking how the whole Redux story went, I think the mainstream simply wasn't ready for immutable state.

Redux was shit. It made apps less comprehensible and less performant. Immutable state isn't really a great idea for stateful applications, and UI development is an almost purely stateful activity. It can easily be said that any UI is fundamentally a state machine...the state of your UI defines the set of actions that are available to it, and the actions taken define the future state of the UI. This is not just true f…

> 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 any architecture. The fact that a UI is just a giant state machine is the whole reason these architectures were created in the first place.

Redux is tricky and boilerplate-y because of some interactions with React, because it doesn't come with a built-in mechanism for handling interactions with the world "outside" the UI (e.g. interactions with the backend), and because JS doesn't have facilities for immutability out of the box and rather you must bolt on post-hoc solutions.

Re: Comparing Svelte and React

#137

Post by bsid »

dopeboy wrote: post #108
Greek0 wrote: post #5

The author praises Firebase Auth for its ease-of-integration, but I'm leery of depending on Google products due to its support horror stories. Can anyone recommend good, easy-to-integrate alternatives?

Check out https://www.clerk.dev/

Can promise good support over at Clerk ;) We are new, and are trying to provide an easier, more comprehensive authN/authZ/user management solution. We're also taking requests for individual use cases as we're ramping up!

Happy to answer any questions.

Re: Comparing Svelte and React

#138

Post by lhorie »

nsonha wrote: post #134
lhorie wrote: post #132

Earlier quoted context omitted.

Not necessarily. Discoverability is a function of colocation, not of immutability. One can write convoluted Redux monstrosities spanning a multitude of files where it's difficult to mentally follow how a dispatched action translates into state deltas (potentially because of too much higher-order abstractions, but also because one action may affect multiple reducers, and that in turn may affect a multitude of React tr…

could you stop saying redux, in my other comment I said the solution could be anything from react's setState to old-style encapsulation. The point is, it's kind of odd that someone'd put mutating states in their tutorial proudly as a "feature". It's a thing that you do very conservatively at best.

> it's kind of odd that someone'd put mutating states in their tutorial proudly as a "feature"

Mutating state is actually the de-facto standard across most of the industry. Look at Vue or iOS or Android or Unity or Rails or J2EE... People literally use ORMs to make things more mutable than SQL.

Yes, you can use React setState, but surely it's not lost on you that this is wrapping over a lot of mutable operations too? Worth mentioning as well that setState semantics have some amount of complexity that is attributable to mutability leaking out of the immutability abstraction (e.g. the callback argument, what happens when things like multiple calls to setState occur synchronously, etc). This is the "curse of abstraction" that comes when you are trying to implement semantics that don't exist natively and the abstraction themselves have semantic weaknesses due to the chicken-and-egg problem of the required semantics not existing natively.

Re: Comparing Svelte and React

#139

Post by darksaints »

nsonha wrote: post #133
darksaints wrote: post #130

Earlier quoted context omitted.

Redux was shit. It made apps less comprehensible and less performant. Immutable state isn't really a great idea for stateful applications, and UI development is an almost purely stateful activity. It can easily be said that any UI is fundamentally a state machine...the state of your UI defines the set of actions that are available to it, and the actions taken define the future state of the UI. This is not just true f…

> you're far more likely to have to change state than you'll have to change how that state is rendered. This puts redux-style solutions squarely on the wrong side of the expression problem Could you please elaborate this?

Maybe, it's a bit hard for me to describe succinctly.

Your UI as an application likely has dozens, if not hundreds or thousands of potential states. And the more you develop the feature set of your UI, the more states you will introduce to it. The data that represents these various states is going to constantly evolve to be able to represent them: you'll have evolving business state, evolving widget states, evolving URL states, etc.

The expression problem can be summarized as a practical comparison of two types of extensibility: writing functions, which extend through composition, and writing classes, which extend through inheritance. The choice of which one is better starts with asking what is more likely to change: your data or your computation over that data.

If you have a problem where your data types are relatively static, but the computations you do on that data are constantly changing, pure functional programming is where it is at. You just write different functions to do different things, and then compose them together to do what you want. This sort of processing is perfect for a ton of usecases...things like data pipelines and etl, machine learning, web services, etc.

If you have a problem where your data types are constantly changing but your computation is relatively static, you're going to have a very bad time with a pure functional approach. You'll end up having to edit multiple functions just to change a single data type. When you decide that you no longer want to represent your state with an Array and instead want to represent it with a Set, you're gonna have to refactor every single function that the original version passed through. And with a massive global state object like Redux, that means not just refactoring the component that renders it, but potentially every single component above it in the HTML tree, modifying them so that they can pass it through to its final destination. That is the sort of burden that happens when you fall on the wrong side of the expression problem.

For reference:

https://wiki.c2.com/?ExpressionProblem

Re: Comparing Svelte and React

#140

Post by acemarke »

yepthatsreality wrote: post #106
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…

React, Redux, Jest, and it’s ilk always came off to me as a way for Facebook to remain relevant through tech-debt and lock-in.

FWIW, Redux has _never_ been a Facebook project.

Yes, both of the creators now work on the React team (Dan Abramov and Andrew Clark), but it's always been an independent OSS project, and is currently maintained by myself and Tim Dorr.

As far as I know, FB barely even uses Redux at all internally, and that only in isolated particular teams that chose it themselves. My understanding is that they mostly use Relay for the new FB.com, and still have a lot of old-school Flux in there as well.

Post reply on HN