Comment by everforward
8 days ago
I like functional code, but part of the issue with React in that regard is that it likes to hide state from you.
Eg all those providers that are inputs to your component but get hidden away.
It really diminishes the value proposition of functional code because the implicit inputs make the output feel non-deterministic. Eg you can have bugs because of state in a provider that is a transitive dependency of a downstream component. You never pass it through explicitly, so it’s not readily apparent that that state is important and needs to be tested.
I find imperative to be a mess because of bugs in teardown (eg someone added a div, that div isn’t properly removed when re-rendering, problems only appear when there’s 3 or more left over divs). Unless you tear everything down and rebuild it on view change, which sounds pretty functional to me (though probably not pure, but what is outside of Haskell?)
I could see where imperative might be more of a mess on the web compared to other platforms, but there’s probably ways to alleviate that. One that comes to mind is never using bare HTML primitives and only ever using components with proper teardown/management built in, of which could be enforced with some combo of linters and tests.
EDIT: Thinking about this some more, I suspect that intermingling of low level primitives and high level components is the root of a lot of problems on the web. It’s convenient in the moment but the mismatch in models is a recipe for trouble.