7 ms·

I’ve been trying for decades to understand why people find it so hard to keep track of state and update the DOM. Sure, it requires a bit of discipline, but it’

I’ve been trying for decades to understand why people find it so hard to keep track of state and update the DOM. Sure, it requires a bit of discipline, but it’s vastly simpler to me than whatever solution comes up every few years (Backbone, Knockout, Angular, React, modifying the language itself, etc). There must be something profoundly different with the way I think. It even expresses itself in the function naming. They call updating innerText “render”. You’re not rendering anything. At most, the browser is, but so is everything else it does related to painting. It feels like a desperate attempt to complicate what is one of the simplest DOM functions. It really baffles me.

duxup 3y ago
In simple applications it is easy. More complex it is not easy.
- tambourine_man 3y ago
  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
dclowd9901 3y ago
Decades is a long time. You must remember the complexities of updating the DOM between browsers, surely. Keeping the DOM in sync with a data state isn’t too difficult but doing so in a highly performant (60 fps) way _is_ tremendously difficult. Especially when it comes to creating APIs that aren’t leaky but also not too cumbersome. It would frankly be easier to just paint pixels to a canvas game-style, than translating changes to a living DOM tree.
- tambourine_man 3y ago
  If you need 60fps you shouldn’t use the DOM. It’s not a game engine. Like you said, go with canvas.
  - pquki4 3y ago
    60fps is not a high bar. A timer that gets updated every 10 millisecond (or in truth whatever the next event loop interval) is commonly used as tutorial, and there is no reason such a widget does not have a high refresh rate. The point of the original comment is that DOM updates should be fast, efficient and avoid visible delays to user's eye, which is not easy. If you are not careful, small changes in a large application could lead to too many DOM updates -- that is where frameworks shine. And canvas is not the solution to everything and has its own problems. To begin with, accessibility.
    - tambourine_man 3y ago
      I agree with all of it. I did recently a timeline with hundreds of elements, 3D transforms etc. Everything was smooth and not because I was particularly clever, but because browsers are fast. All direct DOM manipulation. My complaint with modern frameworks is not FPS, but rather that a hello world often requires 20k files plus a compilation step and the upshot isn’t particularly clear to me. I’ve never been to one of its landing pages and thought: wow, that’s a problem I have and this looks like the perfect solution. Conversely, I clearly remember the first time I saw jQuery. Loading content via Ajax and fading in when done, all in 3 lines of code and cross browser. I was sold at that very second.
rhapsodic 3y ago
Preach brother! My sentiments exactly. And I've developed SPAs that are massively complex and highly interactive, and whatever problems these folks are referring to that stuff like this supposedly solves, I've not yet encountered.
Offler 3y ago
I work on FX trading applications with hundreds of thousands of lines of code. Full fat desktop application replacements. Good luck not using a framework. 20-30 developers with multiple clients with their own devs.
naasking 3y ago
> Sure, it requires a bit of discipline I strongly suspect that in ages past you would have been an ASM programmer shaking your fist at those crazy portable C programmers, and then a C programmer shaking his fist angrily at those crazy memory safe Java programmers. Progress in programming can be marked by eliminating the need for ceremonial kinds of strict discipline needed to achieve good results. Which isn't to say React is some kind of next evolution, but signals certainly are a step in the right direction.

duxup 3y ago

In simple applications it is easy. More complex it is not easy.

tambourine_man 3y ago
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

dclowd9901 3y ago

Decades is a long time. You must remember the complexities of updating the DOM between browsers, surely. Keeping the DOM in sync with a data state isn’t too difficult but doing so in a highly performant (60 fps) way _is_ tremendously difficult. Especially when it comes to creating APIs that aren’t leaky but also not too cumbersome. It would frankly be easier to just paint pixels to a canvas game-style, than translating changes to a living DOM tree.

tambourine_man 3y ago
If you need 60fps you shouldn’t use the DOM. It’s not a game engine. Like you said, go with canvas.
- pquki4 3y ago
  60fps is not a high bar. A timer that gets updated every 10 millisecond (or in truth whatever the next event loop interval) is commonly used as tutorial, and there is no reason such a widget does not have a high refresh rate. The point of the original comment is that DOM updates should be fast, efficient and avoid visible delays to user's eye, which is not easy. If you are not careful, small changes in a large application could lead to too many DOM updates -- that is where frameworks shine. And canvas is not the solution to everything and has its own problems. To begin with, accessibility.
  - tambourine_man 3y ago
    I agree with all of it. I did recently a timeline with hundreds of elements, 3D transforms etc. Everything was smooth and not because I was particularly clever, but because browsers are fast. All direct DOM manipulation. My complaint with modern frameworks is not FPS, but rather that a hello world often requires 20k files plus a compilation step and the upshot isn’t particularly clear to me. I’ve never been to one of its landing pages and thought: wow, that’s a problem I have and this looks like the perfect solution. Conversely, I clearly remember the first time I saw jQuery. Loading content via Ajax and fading in when done, all in 3 lines of code and cross browser. I was sold at that very second.

rhapsodic 3y ago

Preach brother! My sentiments exactly. And I've developed SPAs that are massively complex and highly interactive, and whatever problems these folks are referring to that stuff like this supposedly solves, I've not yet encountered.

Offler 3y ago

I work on FX trading applications with hundreds of thousands of lines of code. Full fat desktop application replacements. Good luck not using a framework. 20-30 developers with multiple clients with their own devs.

naasking 3y ago

> Sure, it requires a bit of discipline I strongly suspect that in ages past you would have been an ASM programmer shaking your fist at those crazy portable C programmers, and then a C programmer shaking his fist angrily at those crazy memory safe Java programmers. Progress in programming can be marked by eliminating the need for ceremonial kinds of strict discipline needed to achieve good results. Which isn't to say React is some kind of next evolution, but signals certainly are a step in the right direction.