Hacker News Reader

Comment by robertoandred | Hacker News Reader

It's not complicated because you're not doing anything complicated with it.

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!"

Are you proposing using the DOM for state management? (of data, not document elements)?

I 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.

Or maybe you just think it isn't a problem because you've never worked on an app that had complex enough state.

Why 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?

Because 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.

Yes. 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.

Many 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.

I 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.

This might the conventional wisdom, but the reality is that in a single thread, hiding data behind all sorts of obstacles is a huge detriment. If you can already get to it, you might as well be organized so you can get to it easily. 'object oriented programming' (whatever it means exactly) is good for creating interfaces to data. The GUI might need an interface to its data, but the state of whatever is being processed and manipulated is less likely to need a special interface and almost definitely not whatever a component meant to display data provides.

If you 'encapsulate' every tiny bit of information inside GUI components you end up with things like storing a string in a GUI label or storing a list in a list selection component. Then every time you want to access that information you have to extract it from the GUI, possibly keeping in mind the lifetime of the UI components.

It has long been my conviction that tech stacks like React are necessary and/or seen as good because the frontend is trying to solve overly complicated problems. All of those framework-du-jour praises sound to me like people have found The New Great Tool for building a Tower of Babel¹.

Just, you know, have simpler problems?

SoC your stuff, solve the 80% instead of the 99%, challenge your assumptions about what you need and you'd be surprised how little complications you can get away with.

¹ one common tool in the pipeline actually being called babel never fails to amuse me.

> tech stacks like React are necessary and/or seen as good because the frontend is trying to solve overly complicated problems

I think a lot of these issues are symptomatic of front-end oriented toolkits trying to solve combined frontend and backend issues, causing oodles of arbitrary complexity.

It's hugely beneficial for some kinds of projects/teams, but so much of the challenge is simply due to domain impedence and using suboptimal tools for the job. Client-oriented solutions to server-client issues have some fundamental limitations.

Indeed. And I would argue that 80% of the websites out there do not need anything complicated.

Now if you have a very rich client side desktop-like application, such as:

https://www.tradingview.com/chart

https://ahrefs.com/site-explorer

or if you are Facebook, then maybe a SPA is required.

(by the way, I picked those two examples because I'm pretty sure they do not use a SPA!)

We shouldn't be aiming for complexity. We should be aiming for simplicity.

Reply on news.ycombinator.com