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

61–70 of 338 posts

Re: Comparing Svelte and React

#61

Post by brundolf »

Scarbutt wrote: post #56
brundolf wrote: post #51

Earlier quoted context omitted.

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.

I'm not sure I agree with your framing of the precise terminology ("passing a reference to an object, by value" vs "passing an object by reference"), but it also isn't important. What's important is this:

  let a = { foo: "bar" }
  let b = { foo: "bar" }

  console.log(a === b)  // false
and this:

  let a = { foo: "bar" }
  let b = a

  b.foo = "blah"

  console.log(a.foo)  // "blah"
This is the kind of misunderstanding that causes insidious bugs.

Re: Comparing Svelte and React

#62

Post by alfonsodev »

mistersys wrote: post #44
alfonsodev wrote: post #18

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

I also don't like having all those constants like LOADING_PRODUCTS ...

And I don't have them, instead this is how you create a type safes actions with typesafe-actions package.

  export const signIn = {
    request: createAction("auth/signin/request")(),
    success: createAction("auth/signin/success")(),
    error: createAction("auth/signin/error")(),
  };
getType is a function from typesafe-actions as well.

Not trying to sell you on Redux, just to address your point about the constants.

About having to write many Epics, well, end of the day, all the Epics have this shape.

  export const signInEpic = (action$: Observable) =>
    action$.pipe(
      filter(isActionOf(signIn.request)),
      switchMap(() =>
        from(signInLogic()).pipe(
          map((user: User) => {
            return signIn.success({ user });
          }),
          catchError((error) => of(signIn.error(error)))
        )
      )
    );
isActionOf is another typesafe-actions function...

I'm not claiming it's superior approach or faster, it's an approach that worked for me for medium/large apps, to collaborate with other developers.

I'm pretty sure you are right about the Svelte cool things you saying I wish I had more time to look into it.

Re: Comparing Svelte and React

#63

Post by searchableguy »

brundolf wrote: post #51
searchableguy wrote: post #45

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…

> When it comes to primitives you can only pass by value, but with objects and arrays you can only pass by reference.

A variable stores reference to the original object and when you pass it to a function, it passes the actual reference as the value.

I think the last part you mentioned is actually confusing in js because lack of clear guidance.

isXyz, Xyz.isXyz, Object.is, and other ways are used in practice to do the same thing but they all have different behavior which trips people.

Re: Comparing Svelte and React

#64

Post by _puk »

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?

I came across Appwrite[0], when looking for open source Firebase alternatives.

It has a long list of supported OAuth2 providers [1].

It worked for me out out the box (DO docker image), and seems to be progressing well. They have some beta Svelte libraries, and it was simple enough to integrate for my uses.

No affiliation, just happy to have found it.

0: appwrite.io 1: https://appwrite.io/docs/client/account?sdk=web#accountCreat...

Re: Comparing Svelte and React

#65

Post by IshKebab »

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 caveats though. React was designed for Typescript. Javascript projects that bolt it on later tend to have issues.

Re: Comparing Svelte and React

#66

Post by gkaemmer »

brundolf wrote: post #57
mistersys wrote: post #44

Earlier quoted context omitted.

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

I actually came to this thread expecting more people to call out MobX. When I use MobX with react, I find it to be as simple and _fun_ as the author finds svelte. Most of the problems people tend to raise with React are problems that are solved by observable state objects.

I also evangelize it whenever I can -- I don't want MobX to be forever doomed to its status as a cult hit!

Re: Comparing Svelte and React

#67

Post by dhucerbin »

patwoz wrote: post #23
dhucerbin wrote: post #21

Earlier quoted context omitted.

Last I checked it was impossible to parametrize component type. In React you can write ` users={...} />`.

Please don't. It looks awful. And I think it's not necessary. Typescript should inherit it's type depending on what you are passing into "users".

I assume you don’t like invocation? That’s not the point here. In svelte you can’t* define type variable that’s bound to the same type in whole component. I can’t enforce that properties `items` is `T[]` and `selectedItem` is `T`.

* Last time I checked. I could be wrong now.

Re: Comparing Svelte and React

#68

Post by brundolf »

gkaemmer wrote: post #66
brundolf wrote: post #57

Earlier quoted context omitted.

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

I actually came to this thread expecting more people to call out MobX. When I use MobX with react, I find it to be as simple and _fun_ as the author finds svelte. Most of the problems people tend to raise with React are problems that are solved by observable state objects. I also evangelize it whenever I can -- I don't want MobX to be forever doomed to its status as a cult hit!

It's baffling to me how distant of a second it is in terms of popularity. Instead of forcing you to contort your program into a special paradigm in order to deal with reactivity in a sane way, it simply makes reactivity a non-concern (while remaining pretty simple and predictable when you do actually care to dig beneath the magic). You can write code in a way that's natural and simply not think about reactivity most of the time, and you'll even get better performance in many cases because of the highly-granular pub/sub that it sets up automatically. I cannot praise this paradigm enough.

Re: Comparing Svelte and React

#69

Post by deckard1 »

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 their mind at least 3 times on the API and none of it fits together today. Hooks and classes don't mix, lifecycle methods are still out there and just as confusing today as they were years ago. Mixing state and functions. It's just a horrible bag of half-baked bad ideas. And it's not even batteries included.

Svelte has it all built-in. It has the equivalent of CSS modules. It has global reactive state and an incredibly simple state protocol that seems almost stupid if you're coming from Redux. You step out of your daze and realize you don't need all the rituals and boilerplate. The things I've seen built on top of that simple protocol can be incredible. It's not magic. It's just JavaScript.

I dare say that Svelte is a joy. But I hesitate to even leave this comment here. Because I know the architecture astronauts are listening, eager to sink their claws into this simple elegant new thing and fill up their Github profiles with soon-to-be abandonware cruft which they will use to pad out article after Medium article which will all pour down upon Hacker News like a shit typhoon. Prodding us to join their cult of Svelte+RxJS. Or Svelte Sagas. Or their random dogma they toss into a giant bucket labeled "Svelte best practices." And, of course, "Ten ways you are doing Svelte wrong."

I might be a little bit cynical.

Re: Comparing Svelte and React

#70

Post by elyobo »

duxup wrote: post #24
alfonsodev wrote: post #18

> 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 I've moved to this and it is working so far. Hooks manage the data and etc, UI components are almost exclusively just UI that get some props. The UI components all have an else render if for some reason they're missing something / it avoids a crash (along with other easy to see / figure out protections)

I use an HoC to wrap components in an error boundary around key points to avoid total crashes.
Post reply on HN