Live data from Hacker News

Comparing Svelte and React

jackfranklin.co.uk

211–220 of 338 posts

Re: Comparing Svelte and React

#211

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…

For me Svelte is between React and Elm. It has some of its own syntax and operator for some benefits. It is better than React in some sense (obviously not in maturity) yet it is worse than Elm (no ML features). If I need to learn some new syntax it is better worth it (no run time exceptions). I am not sure what is the long term plan for Svelte. Is there any plan to address the shortcomings of JS (for example: undefined is a not a function)?

Re: Comparing Svelte and React

#212

Earlier quoted context omitted.

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.

You think that it‘s just reassignment in svelte? I don‘t think so.

Counter in this example is likely a proxy object that knows when it‘s changed and tells svelte to re-render.

It‘s also not immutable, which can cause very confusing interactions in global state.

Re: Comparing Svelte and React

#213

Earlier quoted context omitted.

I can agree on redux hooks being a better alternative to the whole mapToState cycle. But if you go into the new tutorials, they quickly devolve into the same old: https://redux.js.org/tutorials/fundamentals/part-8-modern-re... Oh, look, slices, and thunks, and asyncThunks, and extraReducers, and adapters, and fifteen files to tie all this together for every small piece of api or data that you want to send around. Mos…

I'm not sure how you're looking at that docs page and saying that it "devolves into the same old". That page explicitly shows how RTK simplifies existing Redux patterns. Yes, concepts like "thunks" and "reducers" still exist. Yes, there are new APIs like `createSlice` and `createEntityAdapter`, which have their own options. That's because we've seen how people are using Redux, and have built those APIs to help solve…

> That page explicitly shows how RTK simplifies existing Redux patterns.

The page is a tutorial for a TODO list with only the simplest and the happiest paths. It's not a forum just because you called it a forum, by the way.

OT: I wish the JS world would stop doing TODO lists. A TODO list is a glorified `Array.push`. If it takes your library/framework 10 000 words to explain how to do Array.push, it doesn't mean that a TODO list is a good example on which to base a tutorial. It means your library sucks. If you want to show how great you library is, implement this: https://tonsky.me/blog/datascript-chat/ (demo: http://tonsky.me/datascript-chat/) and manage to describe it in as many words as on that page.

Back to the topic at hand.

The problem with Redux is: it's concept is very simple. The implementation is a poorly specified DSL with isolated parts that barely fit each other, if at all. And even with all the simplifications it can barely manage to make a TODO list with happy paths.

Here's where it all falls apart:

- It looks like I can't use async functions in `createSlice`. I must use a separate `createAsyncThunk`. Because reasons. Because in a world where every single app needs async data fetching "if you want to have async logic interact with the store by dispatching or checking the current store state? That's where Redux middleware come in.": https://redux.js.org/tutorials/essentials/part-5-async-logic

So, suddenly, it's not "we've simplified everything", it's the same old: we need thunks, and middlewares, and whatnot to do data fetching.

Note in that page how `createSlice` (which is an action creator with reducers and stuff) and `createAsyncThunk` (which is an action creator for which you have to provide a store separately, and reducers to that store separately) don't ever fit with each other except through additional boilerplate code. This is especially visible in `features/posts/postsSlice.js` towards the end of the page

And why does everything need a dispatch anyway? Can't everything already be wrapped in a dispatch so that you just call a function?

- There's almost nothing about errors that will inevitably pop up.

Almost no part of the tutorial ever shows how to deal with errors except the "ah, it will magically dispatch an error message to the store, we store the message on the store".

What happens if I run into an error in a "reducer" (which is reducer-slash-action-creator) in `createSlice` and want to dispatch some action? Oh, wait, you can't dispatch actions from a reducer.

What happens if I run into an error in an action created with `createAsyncThunk` and I need to not only return an error, but dispatch some other actions?

- All this is just so, so badly specified. Everything is hidden behind "detailed explanations" that actually try to explain what's going on

For example, the fact that createAsyncThunk magically creates `.pending`, `.fulfilled` and `.rejected` on an action is not explained except sort of in passing.

And there's suddenly a magical `unwrapResult` function that's not even mentioned anywhere. What is the result of an action? It's not in Part 1 or Redux Concepts and not in Part 1 of Redux Fundamentals. I very quickly scanned the rest of the War and Peace novel, and I can't say I found it.

And there's more. I just can't quickly read and grok the 20 volumes of dense prose just to figure out how to push data into an array.

"Async logic and data fetching are always a complex topic." Nope. It's not. Redux makes it a complex topic.

---

So yeah, it all very quickly devolves into the very same "15 different files for every small action". You may collocate some of them in a single file, but that doesn't make them even closely related to each other in any meaningful way.

That's why I said, "I don't know where the sweet spot of Redux it: it's an overkill for small apps, it's unmanageable in big apps."

And it's not all bad. The biggest step towards simplifying Redux have been hooks. `useDispatch` and `useSelector` are really good. Even though we have to admit that they are solving the issues that Redux introduced in the first place :)

Re: Comparing Svelte and React

#214

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…

>No mention of Typescript. You'd be mad to consider writing a significant app without it,

Thanks for calling me mad :)

Re: Comparing Svelte and React

#216
I never got the appeal of state management in React. People now seem to rave about Svelte, because you can just do 'count += 1'. But you could do exactly this already in Angularjs (which, just like Svelte, had a template language).

Ok, Angularjs worked different under-the-hood than Svelte. It was a dirty checking loop instead of compiler-generated change indicators, which didn't scale as well. But other than this scaling issue, the ergonomics were very similar.

But in the meanwhile the React folks started this whole idea that this mutable state was a bad idea and people seemed to blindly believe the React way was going to be the silver bullet. The widely acclaimed Dan Abramov launched Redux, one of the most cumbersome, boiler-plate-heavy state management systems I've ever had the displeasure of using. And with react hooks there are more performance pitfalls than there ever were with Angularjs. So now everyone seems to realize that they lost quite some convenience with React. React had a good run, but it's time to move on.

Re: Comparing Svelte and React

#217
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?

Supabase is in beta but it’s even easier and more performant (and open source) https://supabase.io

Re: Comparing Svelte and React

#218
post #132
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…

These giant monstrosities are really easy to avoid. Redux Actions make locating a state change a breeze. I have worked on giant applications that did not use a redux-like approach to state and it was a horrendous mess.

Re: Comparing Svelte and React

#219
post #216

I never got the appeal of state management in React. People now seem to rave about Svelte, because you can just do 'count += 1'. But you could do exactly this already in Angularjs (which, just like Svelte, had a template language). Ok, Angularjs worked different under-the-hood than Svelte. It was a dirty checking loop instead of compiler-generated change indicators, which didn't scale as well. But other than this sca…

What perf issue have you spotted with hooks? My biggest bugbear with them is just the sheer cognitive exhaustion that comes with figuring out "when" stuff is happening -- especially if you're implementing a bunch of your own useEffects. I remember just sitting there bemused by the complexity -- and the difficulty of debugging ostensibly simple state changes. I (truly!) miss the good old days of intuitely doing count+=1 in a mess of procedural DHTML... so for that reason alone Svelte is a breath of fresh air.

Re: Comparing Svelte and React

#220
post #151

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 was with you on this topic, and I have rants about this elsewhere.

But with Svelte 3 I actually agree with their choice now:

1. The extra templating syntax is rather small and concise. And explicit.

- There are very few directives, and they follow the same rules: `{# start block }{: alternative branch}{/end block}`

- external data that comes from Javascript is always `{data}`

- properties of html components that can be bound are always `prop:name|modifiers={data}`

This is in contrast to, say, Vue, where the syntax can never decide where it's going.

And compared to React, this isn't Javascript either if we think about it:

   {
     svelte.each(cats, ({ id, name }) => 

Hello {name}

) }
That's a specific extension that compiles to Javascript

2. Your work becomes MVC-ish

Your template/html becomes "I have some data, let's display it". And since the template syntax doesn't allow arbitrary logic, you end up collocating transformations of your data with the code that's fetching it. Instead of doing some weird logic inside the template like `data.map.filter.map`

3. But to each their own :)

What really turned me towards Svelte is going through the tutorial and then trying it. It really is good :)

Post reply on HN