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.
Comparing Svelte and React
161–170 of 338 posts
Re: Comparing Svelte and React
#162Earlier 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…
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
#163No 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…
Re: Comparing Svelte and React
#164Earlier 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.
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
#165Re: Comparing Svelte and React
#166Re: Comparing Svelte and React
#167In 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
#168Earlier 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…
So the errors remain compile-time, not run-time.
Re: Comparing Svelte and React
#169Earlier 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.
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.
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.