4 ms·

I’ve been writing web apps for easily 25+ years. Never have I reached for React and friends voluntarily. But again, I know I’m in a minority. I’m just not compl

I’ve been writing web apps for easily 25+ years. Never have I reached for React and friends voluntarily. But again, I know I’m in a minority. I’m just not completely sure why.

duxup 3y ago
You could work for 50 years and never need those… it just depends on what you’re creating / how many devs and so on. I know some guys who over the years wrote their own framework. It works great… for them.
- tambourine_man 3y ago
  Right, the only thing that convinces me is team and hiring dynamics. But that’s not what these tools advertise. It’s always like: you have dozens of interactive controls in this view, it’s getting out of hand, you should use this language that compiles to HTML and JavaScript and carry all these dependencies. To which I always reply: no thanks, I rather deal with the dozens of controls.
  - duxup 3y ago
    > team and hiring dynamics. But that’s not what these tools advertise. I think that’s a given for any proposed standard. We all get a common way we understand things and can even just communicate about a thing.
    - tambourine_man 3y ago
      My argument is that it’s not their selling point. When you go to React’s page you’re not greeted with: “React is a great way to hire devs and manage a team”. The solution they sell is technical, like state management, reusable components, etc. Which I don’t find convincing.
  - unrealhoang 3y ago
    > Right, the only thing that convinces me is team and hiring dynamics. But that’s not what these tools advertise. And that's fine, these tools don't solve what you search for. A dozens of controls multiply with a dozens of events are already a quite big amount of points of failure, so people gladly trade it with the dependencies (what's the issues with dependencies anyway?). So yeah, not many people want to be good, and only hire good people like you to use the hand tools and "just do it correctly". Most acknowledge their downsides and use proper tools to aide them.
pvg 3y ago
FB's website has settings subpages that are more complicated than an average web app and is an SPA-style-mega-app made of piles of other apps. It typically keeps highly consistent state throughout. There's no doing that sanely by hand, you'll just forget something or, more likely, it will get lost between the dozens upon dozens of people needed to build such a thing.
- tambourine_man 3y ago
  1) Almost no one is building FB or Gmail, yet act like it. The precise reason why still escapes me. 2) For other use cases, it’s not that hard to manually update some elements in the DOM. You very quickly learn how not shot yourself in the foot. Certainly a lot easier (and faster) than dealing with the mess that is the React ecosystem.
  - mardifoufs 3y ago
    You don't need to be building Facebook or Google to have a TON of state in a webpage. Obviously if you are doing a basic dashboard, a blog or something similar, it isn't really needed. But for more complex stuff I think react provides a much better way to handle state changes than just using vanilla js. It's not like using react makes an app more complex, because if you wanted to do the same thing in vanillajs you'd end up with a much bigger mess. I agree that some web pages don't need any of that, but those don't usually require a lot of development anyways.
    - xg15 3y ago
      Could you give a concrete example for the more complex stuff?
      - mardifoufs 3y ago
        Sure! Where I work we build very specialized, very low user count live remote non destructive testing software that can be run on a browser. Well, it used to be native, but clients complained a lot in part due to IT restrictions on updates. That means that we basically have to have a remote processing unit, sync the state with the front end at all time, and with the scanning equipment too. That means multiple different canvases and charts, different tabs etc that all contain state, need state to be updated sometimes in the background, and need to have consistent state changes. I don't do a lot of front end dev, but I did help in setting up our new inference module there as I'm in the AI/ML side and it would've been a nightmare to deal with even if I mostly did stuff in a webgl canvas. It was angular, which I don't really like, but is still much better than going vanilla. I know it's pretty niche, but I'd say most non-trivial (blogs, CMS, forms) front ends handle a lot of state. If they don't, then they are relatively simple anyways. That's a generalization but still, you quickly hit the point where react/other framework becomes worth the complexity overhead versus the complexity of doing it in vanillajs
__david__ 3y ago
Do you just use document.createElement(), getElementById(), and friends? I've written lots of web apps that just used those. But I've also jumped into React a couple times to learn if it's better or faster or whatever. I generally think it's a reasonable approach for a template style web app—ie, when you need to build a whole lot of html nodes that interact with each other in the way a complicated ui does. But I do find I can get stuck trying to reason about some of the weird reactivity stuff with useState() and useEffect(). I kinda chalk that up to me being not an expert, but it also feels like a bit of an impedance mismatch with the language itself. But I don't think React necessary for _every_ app and it really depends on what kind of apps you are making. Certainly you can do the original style of app where the templating is on the server and any js is just to hook up already existing nodes. The js community has more or less moved away from that "rails" style of app years ago…
zero_shift 3y ago
I think it would help if you mentioned the kinds of applications you're building. What do you mean by "web apps" here? My memory of the web in 1999 was that the only rich web UX was in Java applets
- tambourine_man 3y ago
  There was this thing called DHTML. It was no Ajax, but you could hide and show elements, change its contents, respond to events, etc. Cross browser was a nightmare. And the server side handled most of the work. Today I build all sorts of things with lots of interactive elements on the frontend, but trying to avoid using React if I can.
pquki4 3y ago
If you are working in a team with 5+ developers who work on the UI where people need to be able to quickly reuse components and put them in large, complicated applications with lots of data that could be fetched and updated with HTTP requests, it is almost impossible not to use any of those frameworks. If you are working on your own, or only create small web apps, sure, you can avoid frameworks in some cases.
- tambourine_man 3y ago
  > it is almost impossible not to use any of those frameworks. Agreed, but because it’s a lot easier to just search for “React programmer” these days than it is to evaluate lots of JavaScript candidates, which has a much wider scope and proficiency level and make sure they’ll fit right in when hired. But not because direct DOM manipulation is not inherently scalable. See puter[1] for instance, a fairly complex, 100k+ lines of code of jQuery. https://github.com/HeyPuter/puter https://github.com/HeyPuter/puter

I’ve been writing web apps for easily 25+ years. Never have I reached for React and friends voluntarily. But again, I know I’m in a minority. I’m just not completely sure why.

duxup 3y ago

You could work for 50 years and never need those… it just depends on what you’re creating / how many devs and so on. I know some guys who over the years wrote their own framework. It works great… for them.

tambourine_man 3y ago
Right, the only thing that convinces me is team and hiring dynamics. But that’s not what these tools advertise. It’s always like: you have dozens of interactive controls in this view, it’s getting out of hand, you should use this language that compiles to HTML and JavaScript and carry all these dependencies. To which I always reply: no thanks, I rather deal with the dozens of controls.
- duxup 3y ago
  > team and hiring dynamics. But that’s not what these tools advertise. I think that’s a given for any proposed standard. We all get a common way we understand things and can even just communicate about a thing.
  - tambourine_man 3y ago
    My argument is that it’s not their selling point. When you go to React’s page you’re not greeted with: “React is a great way to hire devs and manage a team”. The solution they sell is technical, like state management, reusable components, etc. Which I don’t find convincing.
- unrealhoang 3y ago
  > Right, the only thing that convinces me is team and hiring dynamics. But that’s not what these tools advertise. And that's fine, these tools don't solve what you search for. A dozens of controls multiply with a dozens of events are already a quite big amount of points of failure, so people gladly trade it with the dependencies (what's the issues with dependencies anyway?). So yeah, not many people want to be good, and only hire good people like you to use the hand tools and "just do it correctly". Most acknowledge their downsides and use proper tools to aide them.

pvg 3y ago

FB's website has settings subpages that are more complicated than an average web app and is an SPA-style-mega-app made of piles of other apps. It typically keeps highly consistent state throughout. There's no doing that sanely by hand, you'll just forget something or, more likely, it will get lost between the dozens upon dozens of people needed to build such a thing.

tambourine_man 3y ago
1) Almost no one is building FB or Gmail, yet act like it. The precise reason why still escapes me. 2) For other use cases, it’s not that hard to manually update some elements in the DOM. You very quickly learn how not shot yourself in the foot. Certainly a lot easier (and faster) than dealing with the mess that is the React ecosystem.
- mardifoufs 3y ago
  You don't need to be building Facebook or Google to have a TON of state in a webpage. Obviously if you are doing a basic dashboard, a blog or something similar, it isn't really needed. But for more complex stuff I think react provides a much better way to handle state changes than just using vanilla js. It's not like using react makes an app more complex, because if you wanted to do the same thing in vanillajs you'd end up with a much bigger mess. I agree that some web pages don't need any of that, but those don't usually require a lot of development anyways.
  - xg15 3y ago
    Could you give a concrete example for the more complex stuff?
    - mardifoufs 3y ago
      Sure! Where I work we build very specialized, very low user count live remote non destructive testing software that can be run on a browser. Well, it used to be native, but clients complained a lot in part due to IT restrictions on updates. That means that we basically have to have a remote processing unit, sync the state with the front end at all time, and with the scanning equipment too. That means multiple different canvases and charts, different tabs etc that all contain state, need state to be updated sometimes in the background, and need to have consistent state changes. I don't do a lot of front end dev, but I did help in setting up our new inference module there as I'm in the AI/ML side and it would've been a nightmare to deal with even if I mostly did stuff in a webgl canvas. It was angular, which I don't really like, but is still much better than going vanilla. I know it's pretty niche, but I'd say most non-trivial (blogs, CMS, forms) front ends handle a lot of state. If they don't, then they are relatively simple anyways. That's a generalization but still, you quickly hit the point where react/other framework becomes worth the complexity overhead versus the complexity of doing it in vanillajs

__david__ 3y ago

Do you just use document.createElement(), getElementById(), and friends? I've written lots of web apps that just used those. But I've also jumped into React a couple times to learn if it's better or faster or whatever. I generally think it's a reasonable approach for a template style web app—ie, when you need to build a whole lot of html nodes that interact with each other in the way a complicated ui does. But I do find I can get stuck trying to reason about some of the weird reactivity stuff with useState() and useEffect(). I kinda chalk that up to me being not an expert, but it also feels like a bit of an impedance mismatch with the language itself. But I don't think React necessary for _every_ app and it really depends on what kind of apps you are making. Certainly you can do the original style of app where the templating is on the server and any js is just to hook up already existing nodes. The js community has more or less moved away from that "rails" style of app years ago…

zero_shift 3y ago

I think it would help if you mentioned the kinds of applications you're building. What do you mean by "web apps" here? My memory of the web in 1999 was that the only rich web UX was in Java applets

tambourine_man 3y ago
There was this thing called DHTML. It was no Ajax, but you could hide and show elements, change its contents, respond to events, etc. Cross browser was a nightmare. And the server side handled most of the work. Today I build all sorts of things with lots of interactive elements on the frontend, but trying to avoid using React if I can.

pquki4 3y ago

If you are working in a team with 5+ developers who work on the UI where people need to be able to quickly reuse components and put them in large, complicated applications with lots of data that could be fetched and updated with HTTP requests, it is almost impossible not to use any of those frameworks. If you are working on your own, or only create small web apps, sure, you can avoid frameworks in some cases.

tambourine_man 3y ago
> it is almost impossible not to use any of those frameworks. Agreed, but because it’s a lot easier to just search for “React programmer” these days than it is to evaluate lots of JavaScript candidates, which has a much wider scope and proficiency level and make sure they’ll fit right in when hired. But not because direct DOM manipulation is not inherently scalable. See puter[1] for instance, a fairly complex, 100k+ lines of code of jQuery. https://github.com/HeyPuter/puter https://github.com/HeyPuter/puter