4 ms·
In practice, a lot of complexity in front-end development comes because front-end developers only solve problems by adding layers of abstraction, never removing
by csande17 7y ago
In practice, a lot of complexity in front-end development comes because front-end developers only solve problems by adding layers of abstraction, never removing them.
Like, in vanilla JavaScript, you have a single global tree representing the state (the DOM), and you write event handlers that manipulate that tree. But that isn't a good fit for every use case, so you introduce React, which encapsulates all your functionality into components.
But that turns out not to be a good fit for every use case, so you add a state-management library like Redux on top. With Redux, you have a single global tree representing your state (the Redux store), and you write actions that manipulate it.
Congratulations, you are now back where you started, but you've introduced two third-party library dependencies (probably more, if your libraries need separate adapter libraries to work with one another) and a bunch of overhead and complexity.
See also: client-side navigation. "Pages on my website load slowly because the browser has to run all the JavaScript I wrote. How can I solve this? Oh I know, even more JavaScript!"
- igornadj 7y agoAre you proposing using the DOM for state management? (of data, not document elements)?
- csande17 7y agoI am proposing that, in many cases, data is trivially representable as document elements. Lots of websites don't actually have much state to store -- at least in terms of the front-end developer's idea of state, of course you often need a database and user sessions and stuff -- beyond what's currently being shown on the page (and occasionally display:none'd, reordered, or scrolled off-screen). "State management" is a problem you think you have only because you're trying to use React for things it isn't good at.
- schwartzworld 7y agoOr maybe you just think it isn't a problem because you've never worked on an app that had complex enough state.
- deleted 7y ago[deleted]
- Udik 7y agoWhy not storing local state in the components themselves? Why do you need global state management at all, except for the very rare cases in which many totally unrelated components need to tap into the data?
- krzepah 7y agoBecause some complex application have multitude of variables that need to be passed along various components and that's exactly what is doing redux. In these cases it is much simpler to work with the tools that the community built, and as soon as you actually understand how redux and connect work, you are usually rather happy about what it does for you.
- Udik 7y agoYes. I think that some applications, with multitudes of variables that need to be shared between unrelated components, will benefit from a store that manages only those variables. For all the other cases, I don't see any reason to use one, and my experience of the same application developed, by different people, with and without a reactive store, tells me that the solutions without a store are generally much simpler and look way more maintainable.
- BubRoss 7y agoMany GUI programs use components to store data instead of using them only for display, but this eventually means that your program's state is contained in lots of different data structures with different ways of accessing them. Having everything centralized yet organized enables managing a lot more complexity.
- Udik 7y agoI don't understand, it seems you could say the exact same about object oriented programming in general. But encapsulation is a feature- it allows you to expose to the rest of the application only the data that really needs to be exposed, through a well defined interface. It allows to compose applications of parts that are completely self-contained, without having to think of their interaction with the entire application. I get that in some cases you might need components to plug into a global state that can have multiple sources of change, but this is more an exception than the norm.