Hacker News new | past | comments | ask | show | jobs | submit login

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.



Well- 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.


For 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”.


Funny.

I tried to write software like that 10 years ago already, but I always failed at performance.

React was just what I was missing.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: