51–60 of 75 posts
Earlier quoted context omitted.
Hooks are not simple at all, are very error prone, and definitely do not put the user in the "pit of success". JSX is terrific, but React has only gone backwards since classes IMO.
Highly highly disagree. Hooks and Functional components are so much easier to work with nowdays then class based components that came before.
Earlier quoted context omitted.
I just don't know, svelte feels way too similar to the "magic" of knockout and angular 1.0 when looking at the output... Something I got burnt by with weird edge cases of update loops or desync. Svelte might have that all reasoned out though, in which case the harder separation of logic and view is the only stickler for me, and transpiling JSX into svelte would be interesting to see.
If you think Svelte is magic, wait until you see how hooks work.
I think they are actually _more_ explicit than classes about how the state is stored. IMO `this` in class based components isn't as straightforward (e.g. https://overreacted.io/why-do-we-write-super-props/)
Earlier quoted context omitted.
If you think Svelte is magic, wait until you see how hooks work.
A fair point, and I haven't dove into react's inner workings to see how the sausage (I was more discussing the compiled code of the app), but one can reason "how" hooks work after observing them. - They're tied to the lifecycle of the component, so they must reach "up" into whatever just called our component function. - They do not like being moved about/conditionally executed, so hook's likely use an array for metad…
Earlier quoted context omitted.
What Rich Harris said sounds very nice and interesting, but I'd take issue with it being "not the best solution for a scalable UI." As long as the slowdown caused by the Virtual DOM remains below limits of human perception, it doesn't really matter whether something can do without Virtual DOM or not.
I’ve worked on React applications where a single key press would cause lags over 300ms. The React profiler wasn’t able to show any latency in my render functions and using the browser profiler I saw that all time was spent somewhere inside React’s internal. There’s some real overhead of React’s virtual DOM.
React also gives you great tools to avoid and remediate this (memoization wrappers, the dev tools highlight elements that rerender, linters that check you're using hooks correctly), so it's really hard to say that this is a slowness that's endemic to the vdom.
Earlier quoted context omitted.
That's bizarre; I've spent a lot of time spot-optimizing React apps and never had something like that happen The VDOM definitely carried overhead in my case, but it was easy to profile and optimize (with the React tools). In many cases, reflowing the sheer size of the DOM we were generating was a bigger bottleneck than the time it took React to render it in the first place I'm really curious what was going on in your…
I've seen it a lot, personally. I've even seen instances where the input would delay by over a second. Really wild stuff. Can a better design help to mitigate those issues? Sure. But I don't like having to wonder whether it was my own design, or if it's something internal to the library.
Svelte avoids this by magically not doing the unnecessary work. That doesn't mean it's faster, it just means your design needs to make different kinds of considerations.
Earlier quoted context omitted.
What give you the impression that people don't get hooks? In our company I see zero questions about how hooks work on slack. 90% of the time useEffect is enough.
Do they understand how useEffect actually works? Or do they slap on dependency lists on it because eslint tells them to? People understand how to use hooks, but I don't think many people understand them.
Honestly, I would say 90% of professional engineers don't understand how these reactivity models actually work under the hood, and that is okay because it's not strictly necessary to get the job done.
That being said, if I ever had a candidate that is in that remaining % of people who not only know how to use the technology, but what it's doing under the hood (and as a bonus, the benefits and drawbacks of a given approach), it would be an enthusiastic two thumbs up from me.
Earlier quoted context omitted.
> hooks are just iterables and you access them by calling next() In Javascript, "just iterables" can be put in conditional statements, and they don't cause the outer function to be called again. > Also you're just just Ah yes. That "just" again Edit: > just passing a callback function to React and then giving it some pointers to data Thing is, in plain JavaScript if it was a callback function, it could be called anyt…
Nothing is stopping you from putting useState in an if statement. You just have to be careful since it's an "iterator." For example if you put it in an if branch you will want to also use it in the else branch so "next" is called the same number of times.
React still rocks, as it keeps "magic" to the minimal (Hook introduces a little magic for a tradeoff). Simplicity is key here.
Hooks are not simple at all, are very error prone, and definitely do not put the user in the "pit of success". JSX is terrific, but React has only gone backwards since classes IMO.
One of the nicest things about hooks + functional components is how much easier it is to refactor. With class based components, nested state and lifecycle behavior made it sometimes difficult to break down complex components.
But I feel like with functional components and hooks, refactoring into logical subcomponents is a breeze.
Rich Harriss, the author of Svelte talked about all the features that come to React to speed up virtual dom comparisions, but to me he's framework proved it that virtual dom is not necessary, and not the best solution for a scalable UI. At the same time there's a huge amount of React code at this point. It would be an interesting experiment to try to compile React code to really reactive code that doesn't need virtua…
Still the best choice for huge, corporate frontend projects.
Earlier quoted context omitted.
> hooks are just iterables and you access them by calling next() In Javascript, "just iterables" can be put in conditional statements, and they don't cause the outer function to be called again. > Also you're just just Ah yes. That "just" again Edit: > just passing a callback function to React and then giving it some pointers to data Thing is, in plain JavaScript if it was a callback function, it could be called anyt…
Nothing is stopping you from putting useState in an if statement. You just have to be careful since it's an "iterator." For example if you put it in an if branch you will want to also use it in the else branch so "next" is called the same number of times.
- These are "just function calls"
- Except they are "iterators"
- Except if you have them in a conditional, you must provide an `else` branch so that `next` is called the same number of times
None of this is in the semantics of the language where I don't have to provide an else branch to an iterator, and function calls are not iterators ;)