4 ms·
Fully agree. With React, "plain JS" works just like I expect it to. If I have an event handler that does `x = foo` then I don't expect my component to re-rende
by peferron 5y ago
Fully agree.
With React, "plain JS" works just like I expect it to. If I have an event handler that does `x = foo` then I don't expect my component to re-render. Why should it? I'm just changing the value of a local variable. If I want to re-render, there's no way to express that in plain JS, so I'll use React's API and write `setX(foo)` instead. Now it's clear that it's not just changing the value of a local variable, but using React's API to do something else.
With Svelte, writing `x = foo` doesn't just change the value of a local variable. Maybe it's going to run a bunch of magic to update a piece of the DOM instead. Or maybe I need to prefix it with `$: ` which in plain JS is a label for a continue or break statement, but here doesn't mean that at all and means reactivity instead.
Oh, and to conditionally render an element, instead of writing idiomatic JS like `condition && <Element />`, I now have to write `{#if condition} <Element /> {/if}`.
WTF. What looks like plain JS is now magic, and what should look like plain JS such as conditional rendering and lists are now some contrived templating constructs.
And almost everyone here is telling me that I should find that simpler somehow.
It makes zero sense.
- egeozcan 5y agoSorry for the "+1" chain but I want to express my agreement as well. Especially when I compare it to Svelte and Vue (not solid, solid.js is just... good), if I look at a component, with react it's way easier to say what's going to happen. Aren't there gotchas? Yes, but sometimes it's just stuff JS lacks, and so does React. I'm very excited about Records and Tuples in JS to help with the immutability, for example: https://github.com/tc39/proposal-record-tuple https://github.com/tc39/proposal-record-tuple