5 ms·

When will people realize how silly it is to conflate the logical flow of their front-ends with the DOM tree? Why are you all letting the logic of your programs

by feoren 4y ago

When will people realize how silly it is to conflate the logical flow of their front-ends with the DOM tree? Why are you all letting the logic of your programs be dictated by where you want to place visual elements on the page? Just because you don't feel like a real front-end developer if you don't use React / Angular / Vue / any of the other "component"-based frameworks?

unconed 4y ago
You haven't done any front end development recently I imagine? The entire purpose of what people do with state management and contexts is to decouple this.
- feoren 4y ago
  > You haven't done any front end development recently I imagine? Yes, I do front-end development every day. No, I have not done any React/Angular/Vue development recently. The tunnel-vision idea that "front-end development" must mean using one of the Big Frameworks is exactly the idea I'm pushing back against. I tried them for a while (Angular and Knockout), but wrote them off because they couple the logical organization of your app to the DOM tree and they've never taken any steps to improve that (nor even accept that it's a problem). If you're talking about Redux, there are good ideas there, but it's really just trading one kind of global state for another.
- feoren 4y ago
  > The entire purpose of what people do with state management and contexts is to decouple this. I think I now understand what you're saying. You're saying people spend lots and lots of time trying to work around this exact problem, which is introduced by Angular, React, Vue, et al. Realize that this is entirely an extrinsic problem introduced by "component-based" architecture and that a different approach (HTML as one output of the program) avoids this entirely. Managing state is still hard (as it always is), but there's nothing that needs to be decoupled in the first place. It's similar to how "design patterns" are really workarounds for the limitations of OO programming: Redux is a workaround for the limitations of React.
deleted 4y ago
[deleted]

by feoren 4y ago

unconed 4y ago

You haven't done any front end development recently I imagine? The entire purpose of what people do with state management and contexts is to decouple this.

feoren 4y ago
> You haven't done any front end development recently I imagine? Yes, I do front-end development every day. No, I have not done any React/Angular/Vue development recently. The tunnel-vision idea that "front-end development" must mean using one of the Big Frameworks is exactly the idea I'm pushing back against. I tried them for a while (Angular and Knockout), but wrote them off because they couple the logical organization of your app to the DOM tree and they've never taken any steps to improve that (nor even accept that it's a problem). If you're talking about Redux, there are good ideas there, but it's really just trading one kind of global state for another.
feoren 4y ago
> The entire purpose of what people do with state management and contexts is to decouple this. I think I now understand what you're saying. You're saying people spend lots and lots of time trying to work around this exact problem, which is introduced by Angular, React, Vue, et al. Realize that this is entirely an extrinsic problem introduced by "component-based" architecture and that a different approach (HTML as one output of the program) avoids this entirely. Managing state is still hard (as it always is), but there's nothing that needs to be decoupled in the first place. It's similar to how "design patterns" are really workarounds for the limitations of OO programming: Redux is a workaround for the limitations of React.

deleted 4y ago

[deleted]