Live data from Hacker News

Comparing Svelte and React

jackfranklin.co.uk

191–200 of 338 posts

Re: Comparing Svelte and React

#191
post #2

Half-OT: Svelte seems to be the pinnacle of the "bundling era" of frontend frameworks. What do you think comes next? XYZ-to-WASM? Back the roots with (non-)bundlers like Skypack? Anyone heard of next-gen experiments in that directions?

We are actually going the other direction. Currently I am experimenting with making a Blazor/Liveview (HTML over wire) runtime that can support many programming languages. And a GUI builder.

This sounds fascinating. Anywhere I can read about it?

Re: Comparing Svelte and React

#192
post #190

Earlier quoted context omitted.

> I'm sure there are patterns that could help with this. Indeed there are. Again any Turing complete language can do anything another language can with a sufficient dose of design patterns (in the limit design patterns just recreate another language). So everything I say about "classes" and "state machines" needs to be taken as talking about level of effort not possible vs. impossible, since the former, being Turing…

let's back off a bit. I agree with the other commenter's point, which is the really important thing: > Redux's bad ideas do not come from the fact that it models a state machine, it comes from the fact that it models it poorly So to me it doesn't really matter whether class is the best tool to implement state machine. If the argument is " you can do it with class/function/language feature x, however it's a lot of wor…

But that's precisely where I strongly disagree. Redux's problems do not come from a poor implementation of a state machine, but rather the interactions between state machines and stateful, non-state machine representations.

Again, Redux is the purest expression of a state machine possible in a general-purpose programming language (as opposed to a specialized one like TLA+). It maps one-to-one with the usual textbook definition (technically textbooks don't have a rigorous definition for state machines, but rather finite state machines, but usually by "state machine" we just mean you take a normal FSM and just relax the finite bit by introducing some infinite component into the overall state such as an arbitrarily long list). The store is the state, the actions are transitions, and the reducer is the state transition table.

Redux's infelicities come precisely from the fact that it needs to interact with things that are not modeled as state machines! Namely, interacting with black box children and the outside world (mostly sending stuff to the outside world, Redux comes with stuff out of the box to deal with just one-way inputs from the world). And Redux doesn't come with ways out of the box to deal with those so you need to layer more stuff to make it all play nicely together. But you need at some point to interact with them to work with the JS ecosystem so you need that stuff.

If you had state machines all the way down you don't need any particular patterns other than the fundamental state machine description! Especially with Typescript's structural types, everything just works (you just pull out chunks of your store into little stores and pull chunks of your big reducer out into little reducers, it's literally just cut-and-pasting chunks of your code and giving it a new name and making new state machines all the way down).

The friction comes from interacting with React, dealing with the outside world, and figuring out various decisions of what to do about data structures that the JS stdlib doesn't decide for you out of the box (e.g. what immutable library should one use). Even the choice of mutable vs immutable is something that is decoupled from Redux proper (it turns out for incidental reasons it's easier for type systems to properly scope local effects with immutable data structures than mutable ones, but that's more an artifact of Typescript than Redux, see e.g. Rust's type system for a counterexample).

If all of that was just more state machines (and the stdlib issues were taken care of) then Redux would be absolutely lovely.

And that's not just a pie-in-the-sky hypothetical. E.g. Elm is basically what Redux would be if everything was state machines and works great in all the places Redux doesn't (Elm's infelicities in turn are of a different variety that stem from some limitations of its type system to properly express some of the structural types you'd like state machines to have, in particular a lack of structural union types that often requires duplicating the state transition table in certain ways as you break a larger state machine down into smaller state machines).

Re: Comparing Svelte and React

#193

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…

How is Svelte "just JavaScript" when it uses custom templates and file types?

It's "just javascript" because if you want to modify anything and have it re-render, it's `let counter = 0; counter++`, not `const [counter, setCounter] = useState(0); setCounter(counter + 1); `. Of course there's template and all, but for regular logic, you don't have to fiddle around abstractions.

Re: Comparing Svelte and React

#195
Svelte gives us a host of possibilities because of it being compile time. Its the perfect UI language.

Think about it. You can write anything in the script part. Lets say you have a Go UI framework. Write Go code inside script tag and use the template to produce UI elements for TUI apps, for desktop apps without even working hard to manage state, manage UI element paradigms. The simple reactive style of programming can be used. Of course a different compiler can be used. But the possibilities are open. With React and stuff that's kind of difficult. You will eventually end up writing original Go code.

And currently you can compile Svelte components into React/Preact etc. Its not production quality. But its possible. (Svelte2TSX makes it possible)

Re: Comparing Svelte and React

#196

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

It's so boringly cynical to suggest that people use something because they're lemmings rather than any of the great reasons to use something. Go watch the original React debut talk and ask yourself if React had/has anything going for it beyond Facebook's backing. I know I, and most developers I know, dropped Backbone/Knockout/whatever instantly to use React because it was so obviously better. Now that unidirectional…

> I know I, and most developers I know, dropped Backbone/Knockout/whatever instantly to use React because it was so obviously better.

You skipped a huge step. There was angular before react. Which was horribly bloated and over complicated. People wanted something simpler. React, with it's facebook clout won in the end.

Re: Comparing Svelte and React

#197
post #25

> writing complex React components feels more like admin; a constant worry that I'll miss a dependency in my useEffect call and end up crashing my browser session. I don't understand this worry, but I guess that happens when you try to do everything with hooks, the way I settled in my approach is to use React components just for the view without hooks, nor lifecycle logic, just dumb components with ocasional local st…

This sounds really interesting, don't get me wrong, but it also shows just how insanely novel and complicated modern frontend dev is. Let's break down the terminology: - hooks - useEffect - useHistory - useSelector - dispatch - action - useDispatch - ducks - Actions - Epics (Observables) - Sagas (generators) - Reducers Most of those terminologies don't come from a general programming paradigm, but are the domain lang…

You are talking about React here, not Frontend in general. Angular has different concepts. Steep at the beginning, but in my point of view easier in the long term with a stable API.

I agree. Frontend is tough, but so is development. ;)

Re: Comparing Svelte and React

#198
post #172

Earlier quoted context omitted.

> the important part of representing state machines is that you can inspect their state Why? Is that because you need to know if a transition is valid for a given state? Do you have a citation for this? > Classes are meant to be opaque; as you say their encapsulation is a feature. This is true, but in practice, people do expose things in classes. I regularly implement state machines in classes as immutable builders.…

> I'm sure there are patterns that could help with this. Indeed there are. Again any Turing complete language can do anything another language can with a sufficient dose of design patterns (in the limit design patterns just recreate another language). So everything I say about "classes" and "state machines" needs to be taken as talking about level of effort not possible vs. impossible, since the former, being Turing…

> Redux is the purest expression of a state machine possible

Are you sure "pure" is the right word? Last I checked redux very proudly incorporates a certain event-sourcing something idea in it. It's definitely not a "just state machine" library. More like in KFC when you order something, they always make sure that you get their sugar water as well.

Re: Comparing Svelte and React

#199

The svelte approach of implementing better paradigms using compilation rather than using abstractions just seems infinitely better, and a better way to scale up a program in general. I do wonder why this idea never caught on; I think Alan Kay was investigating building a programming platform based on this idea but that's just academic.

Because these tools were made in a time where people were using libraries like jquery. People were building js apps by including libraries directly in the header. Before webpack, and even gulp, when having a build process was a novel thing in web dev.
Post reply on HN