5 ms·

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

skore 7y ago
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.
- bonesss 7y ago
  > 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.
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 ago
  Are you proposing using the DOM for state management? (of data, not document elements)?
  - csande17 7y ago
    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.
    - schwartzworld 7y ago
      Or 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 ago
    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?
    - krzepah 7y ago
      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.
electrotype 7y ago
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://www.tradingview.com/chart https://ahrefs.com/site-explorer 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!)
collyw 7y ago
We shouldn't be aiming for complexity. We should be aiming for simplicity.

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.

bonesss 7y ago
> 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.

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 ago
Are you proposing using the DOM for state management? (of data, not document elements)?
- csande17 7y ago
  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.
  - schwartzworld 7y ago
    Or 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 ago
  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?
  - krzepah 7y ago
    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.

electrotype 7y ago

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://www.tradingview.com/chart https://ahrefs.com/site-explorer 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!)

collyw 7y ago

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