Live data from Hacker News

Comparing Svelte and React

jackfranklin.co.uk

161–170 of 338 posts

Re: Comparing Svelte and React

#161
post #11
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've always wanted to try Auth0 and I've heard great things! I would love to hear if anyone has had a positive experience with Auth0 as well.

My experience is that if you use it how they want you to use it (as a separate page hosted by them) then it’s simple and easy to use, but if you want to embed it they go out of your way to make your life painful. We took the latter route since we care about our UX and probably would have been better off if we just rolled it all ourselves.

Re: Comparing Svelte and React

#162
post #160
post #158

Earlier quoted context omitted.

I understand why they did it, but there are alternatives. Such as: import * from "svelte"; // ...omitted for brevity. { svelte.each(cats, ({ id, name }) => Hello {name} ) } // ...omitted This is easy to parse and transform, while being fully within JS.

FWIW, I did a mini-study a while back about the different possible syntaxes. It turns out there's more than meets the eye wrt what control flow structures need to do, and there are also DX reasons why the dedicated syntax might be more desirable: when you consider all permutations of loop flavors - w/ else clauses, keyed, exposing index, etc - the DSL consistently came out on top in terms of succinctness and readabil…

> There are also technical reasons why `svelte.each` would be problematic...

I am not suggesting that the svelte.each() call be moved into a library; I'm proposing that the callsite is trivial to identify in the AST. Svelte compiler could then do the same thing that it does now.

Re: Comparing Svelte and React

#163

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…

The one place where react typings are disappointing to me is that all elements are typed as JSX.Element, meaning you can’t assert a specific type of child element. Usually not a big deal but would be useful in a number of cases.

Re: Comparing Svelte and React

#164
post #158
post #155

Earlier quoted context omitted.

I agree that gratuitous syntax differences are tiring, but in this case, there's actually a very good reason why it's not just using JS. When it comes to reactive systems, you need to be able to statically analyze control flow structures in order to compile to efficient code. In JS, a for loop is a loop, but so is array.map, Object.keys and someLib.each. The loop could be hidden three layers deep in a higher-order fu…

I understand why they did it, but there are alternatives. Such as: import * from "svelte"; // ...omitted for brevity. { svelte.each(cats, ({ id, name }) => Hello {name} ) } // ...omitted This is easy to parse and transform, while being fully within JS.

Until you try to do something svelte doesn't understand. Then it'd silently break. Templates are powerful _because_ of the restrictions they place, not in spite of them.

I think a much better recommendation would be an existing template language, iff svelte could understand it with perfect parity.

I hate being handed normal syntax to use when not all of it is normal, or when using it has different semantics than the syntax usually carries.

Re: Comparing Svelte and React

#167
Great comparison writeup! However, I do feel some of the points made are weak and seem to be rushing to conclusion.

In the React hook worker code you do not really need to use the `ref` and you can do something like:

```

function useWorker(currentUser, setCurrentPom) { const [worker] = useState(() => new Worker(workerURL))

  useEffect(() => {
    const onMessage = (event) => {
      if (event.data.name === 'tick') {
        setCurrentPom((currentPom) => ({
          ...currentPom,
          secondsRemaining: event.data.counter,
        }))
      } else if (event.data.name === 'start') {
        // More branches removed here to save space...
      }
    }
    worker.addEventListener('message', onMessage)
    return () => {
      worker.removeEventListener('message', onMessage)
    }
  }, [currentUser, setCurrentPom])
  

  return worker
}

```

The reason it works is that `useState` allows you to lazy load something.

You mention two points which make svelte easier, but I would challenge you on those:

> We don't have to keep the worker in useRef, and can just assign it to a variable.

As per my thoughts above you do not need useRef, in fact you just separated the whole worker logic into a separate function which gives us separation of concern and better readability.

> We can pull the event listener code out into a function more easily, as that function won't then become a dependency to a useEffect - at which point we will have to wrap it in useCallback.

I am not sure I fully understand this. But if you are talking about wrapping the event listener code into a function, you can do that and you do not need to wrap it in a callback. Though, I am not sure what we gain out of abstracting the event handling part.

Re: Comparing Svelte and React

#168
post #158

Earlier quoted context omitted.

I understand why they did it, but there are alternatives. Such as: import * from "svelte"; // ...omitted for brevity. { svelte.each(cats, ({ id, name }) => Hello {name} ) } // ...omitted This is easy to parse and transform, while being fully within JS.

Until you try to do something svelte doesn't understand. Then it'd silently break. Templates are powerful _because_ of the restrictions they place, not in spite of them. I think a much better recommendation would be an existing template language, iff svelte could understand it with perfect parity. I hate being handed normal syntax to use when not all of it is normal, or when using it has different semantics than the…

I was saying elsewhere on the thread - I am not suggesting that each should be turned into a runtime call. Instead, 'svelte.each()' callsites are easy to identify in the AST and transform in the compiler.

So the errors remain compile-time, not run-time.

Re: Comparing Svelte and React

#169
post #162
post #160

Earlier quoted context omitted.

FWIW, I did a mini-study a while back about the different possible syntaxes. It turns out there's more than meets the eye wrt what control flow structures need to do, and there are also DX reasons why the dedicated syntax might be more desirable: when you consider all permutations of loop flavors - w/ else clauses, keyed, exposing index, etc - the DSL consistently came out on top in terms of succinctness and readabil…

> There are also technical reasons why `svelte.each` would be problematic... I am not suggesting that the svelte.each() call be moved into a library; I'm proposing that the callsite is trivial to identify in the AST. Svelte compiler could then do the same thing that it does now.

Yes, parsing is trivial, but compiling (in the traditional sense, not the transpilation sense) is a different story. The other sibling comment nails it.

Grammar enforces where a grammar construct is allowed to exist. A custom grammar can be very restrictive (which it is, to great effect, in Svelte's case).

If we reuse JS grammar, then that comes with expectations of what should semantically work. For example something as simple as `$ = svelte.each` might evade a not-sufficiently-smart compiler. Or maybe `console.log(svelte.each(...))` might mis-compile because nobody ever thought to handle that case.

Having used systems with compile-time grammar constructs that look like runtime constructs, I can tell you that having your expectations about semantics being changed from under your feet can be a very frustrating experience.

Re: Comparing Svelte and React

#170

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

> a constant worry that I'll miss a dependency in my useEffect call and end up crashing my browser session. As an fyi for anyone not aware, there are eslint/tslint plugins for this to help avoid it.

100% this, I often find myself getting tripped up when reading people's complaints about the JS / React ecosystem until I remember that TypeScript and the ESLint (and typescript-eslint and eslint-plugin-react) recommended config isn't standard in everyone's projects. It saves you from a ton of these headaches.

Not that the answer to a complaint of a complex toolchain is more tools in the chain, but it's a wonderful development experience once you develop a collection of tools you really like.

Post reply on HN