4 ms·

Nothing new to what I am going to say and not strictly related to React 19. I once loved client-side frameworks like React. Then I realized: Great, we managed

Nothing new to what I am going to say and not strictly related to React 19. I once loved client-side frameworks like React. Then I realized: Great, we managed to add complexity wherever possible. In the backend, in the front-end, in the DevOps stack, EVERYWHERE. And more layers will be introduced to keep all that distributed complexity in sync. sigh

norswap 2y ago
Frontend frameworks really do make things simpler once you go beyond small applications though. Automatically re-rendering when the data/model changes is the right thing to do. We can argue over the specifics for sure, but simply imperatively changing your UI whenever your data changes doesn't scale very far, neither in term of codebase nor in terms of team.
- taeric 2y ago
  I think there are assumptions here that are not shared? First, there is an implication that the HTTP model is benign in the complications that we see in web applications. I don't think it would take a lot of arguments to bust this? Trying to hide it, also leads to several problems of its own. Second, that the rest of the abstractions in a browser are benign in the complications most people complain about. The DOM, CORS, general document structure, CSS(!), and all of the extra APIs that browsers have added through the years are building on some rather awkward layers. I don't think it is hard to argue that the biggest reason that browsers have had the success and development that they have had, is the privilege that we have given port 80 in the world. Now. I think an area we would have solid agreement on, is that I don't necessarily think we had better options along the way? Bringing this back to frameworks, though, tooling is tough to ignore. The tooling that people used to have in easy application creation is tough to scoff at. I think it is safe to say that Dreamweaver was also not that bad, looking back. We had some odd purity tests on whether or not it should use tables for layout. Hard to really keep that complaint top of mind when I look at the absurd amount of markup that is in so many sites, nowadays.
  - bobthepanda 2y ago
    tables with layout wasn't really an issue of purity, but they were another layer of the cruft you described where we were abusing things not built to actually do that. grid and flexbox are probably closer to actually being a one-stop easy-to-use paradigm with less nasty edge cases than tables, but all the table code stuff is still there if you really want to do it. --- > I don't think it is hard to argue that the biggest reason that browsers have had the success and development that they have had, is the privilege that we have given port 80 in the world. I actually think this is orthogonal. The power of frameworks like React is that nobody wants to write the same app five times (windows/mac/linux/ios/android) using sometimes wildly different native coding paradigms, and coordinating feature development across native platforms is like herding cats.
    - taeric 2y ago
      You can really only hang a claim on "abusing things not build to actually do that" on the same peg that "purity" hangs on, though? I mostly agree with the point that this is orthogonal to frameworks. I'm just putting that in here for why people disagree with many common web frameworks. A lot of the complaints that many of us have, are ultimately rooted in what they are building on top of. CSS, in particular, is remarkably ill suited for interface design.
      - bobthepanda 2y ago
        Yeah, but it's the same thing as the "built on top of awkward layers" problem that you describe as a problem. it either is or isn't a problem, and then today you can still write it if you want. People were doing things like making rounded buttons using tables, using things self-described as "clever hacks", and they mostly stopped working because as things like new viewport dimensions showed up you needed to paper over that too. at least from what i've seen, the other strength of CSS is that it gets used for literally everything and so it's possible to build most conceivable layouts. A lot of the other layout frameworks either just use CSS, or you might run into edge cases because of the sheer amount of things in CSS that may not be well supported elsewhere or do not have a clear parallel.
- EternalFury 2y ago
  You must have found a way to add more components, actions, properties, etc. automatically when your data models change. Otherwise, you are changing your UI every time those change. Except that now you have to maintain DTOs, models, actions, APIs, schemas, etc. in many places and across many teams. Sorry, I have been around the block so many times, there’s now a moat around the block.
Muromec 2y ago
That's because VC funded software development is a welfare program for smart people that also want to have fun. It's okay.
paulddraper 2y ago
> we managed to add complexity wherever possible Sure you can centralize your complexity. But that doesn't necessarily get rid of this. You can put database queries, business logic, UI interactions, etc all in one place.
kobalsky 2y ago
> we managed to add complexity wherever possible Did you? You can always opt for a simpler framework and you can avoid server orchestation. If you are not in the position to choose then you could work on starting your own project if you think you will have a efficiency edge over the rest with your simpler stack.
ransom1538 2y ago
I just rsynced my php files over. ci/cd done. php does html/css ui done. I am not sure what all the js trend is about.
- veidelis 2y ago
  You just havent worked on an app that is heavy on client state.
mrtksn 2y ago
React was my reason to distance myself from Web frontend. Huge complexity just to make the web browser render boxes in a way it’s not intended to do. Huge loss of productivity and tooling in the name of changing a coding paradigm. Some cool ideas and implementations, sure but was it worth it? Maybe it was a job security stunt or something of that sort? Well it wasn’t just ReactJS, the whole JavaScript ecosystem went mad with its libraries and tooling for all these libraries but React was particularly annoying to get started so they built create react app so you can have a hello world app in a reasonable time.
- veidelis 2y ago
  What is your alternative to the problems that React supposedly solves?
  - mrtksn 2y ago
    I no longer have an idea for the web, I do native mobile apps now. SwiftUI for example shares many ideas with react, like being declarative. The difference is, in SwiftUI you fire up Xcode and you are up and ready to build the thing you intend to. No tooling setup, no intermediate steps to transpile the code into something you can’t recognize and the “backend” that deals with the logic is the same language with the same paradigms. Mind you, SwiftUI is considered a downgrade when it comes to tooling. Yet everything fits and you didn’t spend mental energy to try to make the tools work as intended. My mantra now is to use the tool that is built to do the things I want to do and stop trying to make make it work in ways it’s not intended to. That’s why when I want to have a web interface I simply work with DOM directly. That’s how the creators of the web browser intended:) No virtual DOM, no libraries doing magic and managing the DOM for me. I'm sure there's place for ReactJS too, it's just that its not for most use cases. All I want is tools that I can fully fit in my working memory and don’t spend time trying to make things work so I can do the work I care about. Simplicity and robustness is the paramount.
    - dnh44 2y ago
      I'm kind of the same with that. At some point quite a long time ago doing the front-end side of webdev became a chore for me so I stopped. I'm finding SwiftUI attractive because I feel like I make a decent frontend experience for free which allows me to focus on the functionality.
ken47 2y ago
React and similar frameworks have made it easier to manage a given level of complexity. The complexity of app features have adjusted and will continue to adjust to the new frontier enabled by said frameworks.
efortis 2y ago
I like React but since hooks (v16.8), React’s changes are nothing but skill bragging. I stopped hoping for the reason behind changing the class components API to hooks.

norswap 2y ago

Frontend frameworks really do make things simpler once you go beyond small applications though. Automatically re-rendering when the data/model changes is the right thing to do. We can argue over the specifics for sure, but simply imperatively changing your UI whenever your data changes doesn't scale very far, neither in term of codebase nor in terms of team.

taeric 2y ago
I think there are assumptions here that are not shared? First, there is an implication that the HTTP model is benign in the complications that we see in web applications. I don't think it would take a lot of arguments to bust this? Trying to hide it, also leads to several problems of its own. Second, that the rest of the abstractions in a browser are benign in the complications most people complain about. The DOM, CORS, general document structure, CSS(!), and all of the extra APIs that browsers have added through the years are building on some rather awkward layers. I don't think it is hard to argue that the biggest reason that browsers have had the success and development that they have had, is the privilege that we have given port 80 in the world. Now. I think an area we would have solid agreement on, is that I don't necessarily think we had better options along the way? Bringing this back to frameworks, though, tooling is tough to ignore. The tooling that people used to have in easy application creation is tough to scoff at. I think it is safe to say that Dreamweaver was also not that bad, looking back. We had some odd purity tests on whether or not it should use tables for layout. Hard to really keep that complaint top of mind when I look at the absurd amount of markup that is in so many sites, nowadays.
- bobthepanda 2y ago
  tables with layout wasn't really an issue of purity, but they were another layer of the cruft you described where we were abusing things not built to actually do that. grid and flexbox are probably closer to actually being a one-stop easy-to-use paradigm with less nasty edge cases than tables, but all the table code stuff is still there if you really want to do it. --- > I don't think it is hard to argue that the biggest reason that browsers have had the success and development that they have had, is the privilege that we have given port 80 in the world. I actually think this is orthogonal. The power of frameworks like React is that nobody wants to write the same app five times (windows/mac/linux/ios/android) using sometimes wildly different native coding paradigms, and coordinating feature development across native platforms is like herding cats.
  - taeric 2y ago
    You can really only hang a claim on "abusing things not build to actually do that" on the same peg that "purity" hangs on, though? I mostly agree with the point that this is orthogonal to frameworks. I'm just putting that in here for why people disagree with many common web frameworks. A lot of the complaints that many of us have, are ultimately rooted in what they are building on top of. CSS, in particular, is remarkably ill suited for interface design.
    - bobthepanda 2y ago
      Yeah, but it's the same thing as the "built on top of awkward layers" problem that you describe as a problem. it either is or isn't a problem, and then today you can still write it if you want. People were doing things like making rounded buttons using tables, using things self-described as "clever hacks", and they mostly stopped working because as things like new viewport dimensions showed up you needed to paper over that too. at least from what i've seen, the other strength of CSS is that it gets used for literally everything and so it's possible to build most conceivable layouts. A lot of the other layout frameworks either just use CSS, or you might run into edge cases because of the sheer amount of things in CSS that may not be well supported elsewhere or do not have a clear parallel.
EternalFury 2y ago
You must have found a way to add more components, actions, properties, etc. automatically when your data models change. Otherwise, you are changing your UI every time those change. Except that now you have to maintain DTOs, models, actions, APIs, schemas, etc. in many places and across many teams. Sorry, I have been around the block so many times, there’s now a moat around the block.

Muromec 2y ago

That's because VC funded software development is a welfare program for smart people that also want to have fun. It's okay.

paulddraper 2y ago

> we managed to add complexity wherever possible Sure you can centralize your complexity. But that doesn't necessarily get rid of this. You can put database queries, business logic, UI interactions, etc all in one place.

kobalsky 2y ago

> we managed to add complexity wherever possible Did you? You can always opt for a simpler framework and you can avoid server orchestation. If you are not in the position to choose then you could work on starting your own project if you think you will have a efficiency edge over the rest with your simpler stack.

ransom1538 2y ago

I just rsynced my php files over. ci/cd done. php does html/css ui done. I am not sure what all the js trend is about.

veidelis 2y ago
You just havent worked on an app that is heavy on client state.

mrtksn 2y ago

React was my reason to distance myself from Web frontend. Huge complexity just to make the web browser render boxes in a way it’s not intended to do. Huge loss of productivity and tooling in the name of changing a coding paradigm. Some cool ideas and implementations, sure but was it worth it? Maybe it was a job security stunt or something of that sort? Well it wasn’t just ReactJS, the whole JavaScript ecosystem went mad with its libraries and tooling for all these libraries but React was particularly annoying to get started so they built create react app so you can have a hello world app in a reasonable time.

veidelis 2y ago
What is your alternative to the problems that React supposedly solves?
- mrtksn 2y ago
  I no longer have an idea for the web, I do native mobile apps now. SwiftUI for example shares many ideas with react, like being declarative. The difference is, in SwiftUI you fire up Xcode and you are up and ready to build the thing you intend to. No tooling setup, no intermediate steps to transpile the code into something you can’t recognize and the “backend” that deals with the logic is the same language with the same paradigms. Mind you, SwiftUI is considered a downgrade when it comes to tooling. Yet everything fits and you didn’t spend mental energy to try to make the tools work as intended. My mantra now is to use the tool that is built to do the things I want to do and stop trying to make make it work in ways it’s not intended to. That’s why when I want to have a web interface I simply work with DOM directly. That’s how the creators of the web browser intended:) No virtual DOM, no libraries doing magic and managing the DOM for me. I'm sure there's place for ReactJS too, it's just that its not for most use cases. All I want is tools that I can fully fit in my working memory and don’t spend time trying to make things work so I can do the work I care about. Simplicity and robustness is the paramount.
  - dnh44 2y ago
    I'm kind of the same with that. At some point quite a long time ago doing the front-end side of webdev became a chore for me so I stopped. I'm finding SwiftUI attractive because I feel like I make a decent frontend experience for free which allows me to focus on the functionality.

ken47 2y ago

React and similar frameworks have made it easier to manage a given level of complexity. The complexity of app features have adjusted and will continue to adjust to the new frontier enabled by said frameworks.

efortis 2y ago

I like React but since hooks (v16.8), React’s changes are nothing but skill bragging. I stopped hoping for the reason behind changing the class components API to hooks.