2 ms·

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 upda

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
  - pcthrowaway 3y ago
    Maybe try making something like Grafana's dashboard by hand.
pvg 3y ago
This sounds more like a complaint the kids aren't happy to eat turnips and mashed bugs (just pick the legs and wings out!) like we had to and that their newfangled 'sandwiches' are too fancy. What if they get caught out in the forest with nothing but sandwiches? That oughta learn'em real quick.
- tambourine_man 3y ago
  Haha, if you want to go with the food analogy, I'd say they are discussing over meat sticks brands without having tasted a real steak. Or better still, running a meat stick factory because doing the dishes is hard. But I don't know if such analogies are any good other than being funny.

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
- pcthrowaway 3y ago
  Maybe try making something like Grafana's dashboard by hand.

pvg 3y ago

This sounds more like a complaint the kids aren't happy to eat turnips and mashed bugs (just pick the legs and wings out!) like we had to and that their newfangled 'sandwiches' are too fancy. What if they get caught out in the forest with nothing but sandwiches? That oughta learn'em real quick.

tambourine_man 3y ago
Haha, if you want to go with the food analogy, I'd say they are discussing over meat sticks brands without having tasted a real steak. Or better still, running a meat stick factory because doing the dishes is hard. But I don't know if such analogies are any good other than being funny.