3 ms·
For what it’s worth, this is also true of whatever else one might express with JSX: imperative code (and syntax, and semantics) can be structured in a way that
by eyelidlessness 1y ago
For what it’s worth, this is also true of whatever else one might express with JSX: imperative code (and syntax, and semantics) can be structured in a way that closely resembles declarative code… with discipline.
It’s doesn’t have to be especially onerous discipline if you embrace it, but it becomes considerably more onerous as it becomes more social: if some members of a team/contributors to a project embrace it more/less than others, that difference in commitment becomes a constant source of friction.
- mikebelanger 1y ago> It’s doesn’t have to be especially onerous discipline if you embrace it, but it becomes considerably more onerous as it becomes more social: if some members of a team/contributors to a project embrace it more/less than others, that difference in commitment becomes a constant source of friction. That's one of the stronger arguments for opinionated pre-processors/frameworks/libraries like Typescript/TSX/JSX/React in general. Because it abstract away those things that only some team members would embrace, you effectively make everyone embrace them. That leads to less friction. But this reduced friction comes at a cost: more complex abstractions and incidental bugs related to that complexity. And as far as the procedural vs declarative: after a certain degree of complexity, I find myself introducing procedural codes within useEffects, useMemos anyways