Live data from Hacker News

Comparing Svelte and React

jackfranklin.co.uk

51–60 of 338 posts

Re: Comparing Svelte and React

#51

Earlier quoted context omitted.

In some ways JS is an excellent first language- beyond its broad applicability, it has an extremely "average of all the others" set of features and primary syntaxes. An experienced JS programmer will be conceptually comfortable with Python and Ruby, syntactically comfortable with Java and C, etc. But in terms of the industry-standard practices/ecosystem, it is a terrible first language if you want to gain a generaliz…

> even the difference between passing by reference vs value You can only pass by value in JS so maybe that's why. It is a bit confusing because of how objects work that it feels like you are passing by reference. You are passing reference as the value.

When it comes to primitives you can only pass by value, but with objects and arrays you can only pass by reference. And this applies to comparisons too: when comparing objects or arrays you are comparing by reference, not deeply by their inner values. If you want to compare them deeply you have to take some additional steps to make that possible, and all of the different strategies for doing so have different trade-offs.

I once talked to someone with >5 years front-end experience, including some team-lead experience, who thought the difference between == and === was that === compares objects deeply. That is very, dangerously wrong. The only way I can imagine he got by for so long with that misconception is that he'd always used ImmutableJS.

Re: Comparing Svelte and React

#52
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…

Novel - not, in my opinion. How to do GUI is known from 1970-ties. Today's single page apolication frameworks slowly re-discover the wheel. It is funny to observe.

Re: Comparing Svelte and React

#53
How's unit testing in Svelte today? That's the main worry I have with template-based systems (well, that and TypeScript support, but I hear that that's quite OK now).

Re: Comparing Svelte and React

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

Do you need social logins? If not (and you just want email/password login) then implement it yourself. Auth isn't hard, and Firebase Auth doesn't provide you much in terms of managing roles/permissions or anything like that.

> Auth isn't hard

... :-|

Authentication/Authorisation (AuthZ) is hard, brother. Implementing what you think looks like AuthZ is easy, but making sure you've got all possible avenues covered is hard.

Getting AuthZ correct and having everything covered is hard.

Security is hard.

Source: see the entire field of security and all the companies, products and services that have been invented to try and solve this problem.

Re: Comparing Svelte and React

#55
post #17

Javascript n00b question... is there any difference between onMount(() => { return listenForAuthChanges() }) and onMount(() => listenForAuthChanges()) ?

They are the same. It's a matter of style. For that matter, you could also write: onMount(listenForAuthChanges) which is technically simpler -- you're not constructing a new anonymous function. But if you wanted to extend the code (to say, add a console.log), you'd need to do the top version, which already has the braces. It's up to your judgment of what's clearer and likely to be more maintainable.

That should work in the provided example, but in general `fn(cb)` is different: you lose the implied `this` binding unless you do `cb.bind(something)` beforehand.

There's also some unexpected trouble due to potential extra parameters. Consider the output of

  ['1', '2', '3'].map(parseInt)

gives:

  [1, NaN, NaN]
So yea, fn(() => cb()) is the same as fn(() => {return cb()}) – just syntactic sugar when the anonymous function has just one statement. but fn(cb) is semantically different.

Re: Comparing Svelte and React

#56

Earlier quoted context omitted.

> even the difference between passing by reference vs value You can only pass by value in JS so maybe that's why. It is a bit confusing because of how objects work that it feels like you are passing by reference. You are passing reference as the value.

When it comes to primitives you can only pass by value, but with objects and arrays you can only pass by reference . And this applies to comparisons too: when comparing objects or arrays you are comparing by reference , not deeply by their inner values. If you want to compare them deeply you have to take some additional steps to make that possible, and all of the different strategies for doing so have different trade…

but with objects and arrays you can only pass by reference.

It's still pass by value, you are passing the reference of the object as a value.

Re: Comparing Svelte and React

#57

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

Yeah this is the problem with the React ecosystem. I'm intimately familiar with this stack and used to use redux with "duck" modules professionally, complete with sagas and epics, and rxjs and the whole kitten, so it's not that I don't understand all the terms and am just overwhelmed. It's just that once you stop using Redux, it becomes so much easier to build and manage your app, and you don't even realize how much…

> Svelte has 2 primitives that replace all of this: readable and writable. You can create a writable store and you call `.update` or `.set` like react setState. Want to separate your update logic from your component logic like in redux? Easy, just export functions to update the store instead of calling `.update` in your components.

This sounds very similar to the experience of using MobX. I evangelize it as an alternative to Redux every chance I get; it's incredible how practical and pleasant it is to work with.

Re: Comparing Svelte and React

#59

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

Yeah this is the problem with the React ecosystem. I'm intimately familiar with this stack and used to use redux with "duck" modules professionally, complete with sagas and epics, and rxjs and the whole kitten, so it's not that I don't understand all the terms and am just overwhelmed. It's just that once you stop using Redux, it becomes so much easier to build and manage your app, and you don't even realize how much…

To be fair, you're criticizing Redux more than React. And even then, you're criticizing a specific pattern of using Redux: redux-toolkit melts away all the boilerplate you're talking about, and you could use something else than Redux if you wanted.

I agree that React folks (me included) tend to reach out to Redux much too soon, though.

Re: Comparing Svelte and React

#60
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.
Post reply on HN