3 ms·
You can split the first example in small functions and it'll still be a mess. The post is not about duplication, function size, or nesting. We gained predictabi
by danabramov 8y ago
You can split the first example in small functions and it'll still be a mess. The post is not about duplication, function size, or nesting. We gained predictability by preventing _accumulation_ of errors — which we got by always restarting rendering from scratch.
- dyarosla 8y agoWell- the React example doesn’t really restart rendering from scratch (as you yourself mentioned). And in larger applications you’d still prefer to not ‘redraw from scratch’ in React either and build on top of a previous setup. Really what you’re doing is preferring more declarative programming practices over procedural. And as a consequence, more declarative APIs like React.
- danabramov 8y agoFor the app developer, React code _does_ restart rendering from scratch. You have no access to the past rendered state from the render method (at least if you don’t intentionally escape the declarative model). This isn’t true only for bugs in React. What happens internally in React is another question. But the point of React abstraction is to let _you_ think in terms of “render from scratch”.
- deleted 8y ago[deleted]
- k__ 8y agoFunny. I tried to write software like that 10 years ago already, but I always failed at performance. React was just what I was missing.