81–90 of 168 posts
[flagged]
I've also go a much simpler Next.js app with a build time of 45s.
I'm starting to wonder whether reactivity (not React specifically) was the originally sin that led to modern UI complexity. UI elements automatically reacting to data changes (as oppposed to components updating themselves by listening to events) was supposed to make things easier. But in reality, it introduced state as something distinct from both the UI and the data source (usually an API or a local cache). That int…
At some point, someone is going to come out with a no-JS, no-NPM, no-SSR framework and we're just going to have invented HTML again
I'm starting to wonder whether reactivity (not React specifically) was the originally sin that led to modern UI complexity. UI elements automatically reacting to data changes (as oppposed to components updating themselves by listening to events) was supposed to make things easier. But in reality, it introduced state as something distinct from both the UI and the data source (usually an API or a local cache). That int…
Yep. It's one of those great on paper, tough in reality models. Used sparingly and wisely, it can make great UX fairly trivial. But sadly, state is more often abused and loaded with tons of data and complexity it shouldn't be holding. Something, something just because you can, doesn't mean you should .
There are people who hate react?
There are people who hate react?
Earlier quoted context omitted.
> The master Render() function draws all of the graphics according to the current state What you are describing is exactly what GP complained about: "state as something distinct from both the UI and the data source". React can be 100% stateless, functional, and have the state live somewhere else. You just need to apply the same limitations as your model: components should be simple and not store data in themselves. T…
> React can be 100% stateless, functional, and have the state live somewhere else. You just need to apply the same limitations as your model: components should be simple and not store data in themselves. "just" is doing a lot of heavy lifting here. Where do you store "pure" GUI state (button state, is expandable expanded, …)? Do you really want to setup Redux for this? (And no, the DOM is not an option in non-trivial…
I'm starting to wonder whether reactivity (not React specifically) was the originally sin that led to modern UI complexity. UI elements automatically reacting to data changes (as oppposed to components updating themselves by listening to events) was supposed to make things easier. But in reality, it introduced state as something distinct from both the UI and the data source (usually an API or a local cache). That int…
But yes, React is a mess. JSX was the original sin of mixing HTML inside JS. And those bundlers and tree-shaking at build time? Ugh.
What if you had this instead: https://community.qbix.com/t/loading-at-runtime-the-web-fram...
At some point, someone is going to come out with a no-JS, no-NPM, no-SSR framework and we're just going to have invented HTML again
Earlier quoted context omitted.
>components should be simple and not store data in themselves. That is a ”controlled component” model which is bad for interactivity, especially text inputs. If every keypress triggers a state change and rerender, the UI will be slow and things like focus management become complex issues. Without a rerender, it must now use a reactive binding to update the field value. If you don’t want to update state on every keypr…
I don't know what people generally recommend now, but for a long time the best practices with organizing React components had them connected to the store midway down the tree or higher, which definitely would have contributed to the UI slowness since it would rerender everything below that on each update. Push the store access down as far into the leaves as possible and you won't get anything noticeable, even though…