[inigyou]

Your first thought might be to use React, but in prior eras we wrote a function updateFieldVisibility() and that worked fine. Straightforward code can be faster than using a state management framework to determine exactly which fields' visibility changed.

[dsego]

But it's harder to have component composition. Consider also lists and adding/removing items and so on, juggling all of it gets insanely complex and requires MVC or MVVM patterns like with backbone.js

[oneeyedpigeon]

But now we're back at "Not everyone is building complex UIs like google sheets". I agree with the underlying sentiment of this thread: overengineering is way more common than underengineering.

[dsego]

Eventually each crud form evolves into something more complex, the bar is set higher today, we expect pagination, filtering, search, inline editing, grids, instant validation, auto-save, push notifications, state sync, ... that's not a complex UI nowadays, it's expected. Not sure what a non-complex UI looks like.

[inigyou]

You just call updateFieldVisibility() every time the list selection changes and don't worry about the redundancy.

[not-a-llm]

it can be faster, but is it correct?

React was invented because jQuery style state management collapsed into unmanageable code past a certain size

[dsego]

And it wasn't composable, state was kept in the DOM. Even with higher level libs like backbone we didn't have a component-oriented way like now. Each component had to manually manage all of its child components.

[inigyou]

It composes to one level. Each <input> is a component. Is that good enough for your application? For many, it is.

[dsego]

Really sorry to have to say this, but I feel like I'm getting underpaid for the work that I do if people make a living clobbering together input elements and calling it web development.