Hacker News Reader

Comment by inigyou | Hacker News Reader

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.

View on HN

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

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.

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.

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

it can be faster, but is it correct?

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

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.

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

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.

Reply on news.ycombinator.com