7 ms·

> Good luck doing that with React Data is sent to React by inertia/graphql/whatever and React renders it. It’s pretty straightforward. Edit: I do love LiveVie

> Good luck doing that with React Data is sent to React by inertia/graphql/whatever and React renders it. It’s pretty straightforward. Edit: I do love LiveView/HotWire/HTMX etc but honestly everything is a trade off and there are times just rendering a react component is less complex.

ricardobeat 11mo ago
“Just rendering a component” takes thousands of nested function calls, covering a million lines of code; it’s not possible for a person to read or understand the whole process unless they dedicate months to it.
- creakingstairs 11mo ago
  Sure it adds complexity, but isn't that what abstractions are for? We are talking about grokking how data flows in _a web app in Rails_. I wouldn't think usual workflow requires going into actual inner workings of React :p
  - AstroBen 11mo ago
    Well React doesn't come by itself. You need a router, probably some way of managing shared state, bundling, compiling your TypeScript, and 7 other libraries The more stuff you add on the harder everything is to understand, and the less stable your app becomes until suddenly you need specialists for every piece just to keep things chugging forward. Everything needs greasing and maintenance over time.. ..and then in 4 years the React team decides "oh you know what the way Svelte is doing things is actually way better.. we'll need a re-write to integrate their ideas". Now what? "that wouldn't happen! so many businesses depend on React!".. uh they have no obligation to make things compatible with whatever you've built. They're not working for you. What happened with AngularJS? Vue 2? Hotwire is easy to understand (React "just renders it" is a massive oversimplification) If Hotwire rewrites? I create a private fork and continue on. Who cares If I want to tweak how Hotwire works cause it'll benefit my app specifically? I do it myself I'm not against adding complexity.. but if you care at all about longevity and long-term productivity then adding React really needs a tonne more consideration than it gets
    - creakingstairs 11mo ago
      I think we fundamentally agree that we want to be careful about adding complexity to a project. Funnily enough there have been many times where I really thought Hotwire equivalent would have cut down a lot of complexity. I've also actively looked at web components at work and for hobby projects to see if we could make/keep things simpler. But maybe I'm biased because I've been working with React for a long time, I don't find it too daunting to manage dev tools around React. When React was young, I remember that there were _a lot_ of ecosystem churn but now it's more-or-less settled and I don't think it's too bad. I don't know how Hotwire works that well as most of my experience is around Elixir's LiveView, but at least for LiveView, there is also quite a bit going on under the hood to make it performant for large lists and to handle error states gracefully. And I (maybe incorrectly) assume Hotwire is similar, so I feel like it may not be not as simple as you say. (Edit: it is simpler than React though!)
      - AstroBen 11mo ago
        It also doesn't need to be all or nothing. I've become a big fan of progressive enhancement or an islands approach. Default to SSR and scale it up as needed
  - lambdaone 11mo ago
    Once you give up any hope of understanding the inner workings of the frameworks you are using, you're no longer a programmer, you're a cargo cultist. Now compound this a dozen levels deep, with systems piled on systems built by people who don't understand the other systems they are building on top of, and you have the current mess.
    - spoiler 11mo ago
      Every engineer in our industry is a Cargo cultist by that definition. Including experts. Where do you draw the line? I'm sure you have one, but your line is no less arbitrary than mine or someone elses.
      - lambdaone 11mo ago
        A competent programmer should be able to at least conceptualise every level from the transistor up - not necessarily completely understand, but at least know roughly what it does, and what it rests on, and what rests on it. Transistors, gates, logic, state machines, instruction sets, assemblers, parsers, compilers, interpreters, operating systems, memory allocation, graphics, browsers, that sort of thing. Not at all unreasonable for someone with a decent computer science degree, surely? Of course, you don't have to know any of that to grasp how to bang a page together with today's web frameworks; but you end up with the resource-hogging unmaintainable security disaster that is the modern web in the process.
        spoiler 11mo ago
        Ok, but I've worked with people who are pretty good with web dev, but I guarantee you they don't know how memory gets requested from the operating system. Like, sure it helps in some contexts, but in their context it would largely be irrelevant. For the wast majority of people, it's fine for them to know basic tradeoffs between stdlib container types. Most web performance problems today come from misusing tools, whether container types, bad algorithms, memory leaks (and I don't think knowing how an OS manages memory would help them in JS for example), DOM pollution, or oversized assets or whatever. And my take is that that people are often too overworked to care about it, rather than lacking awareness about these things lol On the other hand, if you're a systems engineer, then you absolutely do needs to know all of this stuff. And I bet you they'd navigate stuff like better than a systems engineer, because that's more useful to their day to day!
- nine_k 11mo ago
  I don't think a typical React rendering call is even 100 calls deep. React itself adds maybe a dozen frames. Your components could be complicated, but likely they don't add more than another dozen or two. React is pretty efficient if you hold it right, and use for its intended purpose, that is, large and complex interactive UIs.
  - vhcr 11mo ago
    You also have to take into account the browser and OS call stack.
    - nine_k 11mo ago
      This does not change if you write pure Javascript that directly mutates DOM without calling any intermediate functions. Given the speed of rendering that browsers achieve, I would say that their call stack during this is highly optimized. I don't see OS doing much at all besides sending the drawing buffers to the GPU.
    - zelphirkalt 11mo ago
      And also, that with React you are not only buying into React, but also a JavaScript dependency manager/package manager. Be it NPM, or any other. Installing JS package itself already comes with its own problems. And then probably people buy into more stuff to install through that package manager. Some component library and a "router" here, some material style and a little library to wrap the root node with some styling provider or what it is called there, ... before you know it, a typical FE dev will have turned your stack into 80% React and related dependencies and the maintenance on that will continue to grow, as new features "can be solved sooo easily, by just adding another dependency" from the NPM/React world.
  - ricardobeat 11mo ago
    The event handling alone is almost a hundred calls deep. Because a lot of the work is happening asynchronously, you won't see most of it when stepping through the debugger starting from a click handler for example, but try adding a breakpoint to the compiled JSX. With fibers (React >16) and a couple commonly used hooks you'll easily hit a thousand high call stack.
- spoiler 11mo ago
  And you think slapping ActiveRecord to a Ruby class doesn't hide thousands of lines of code? Do you need a truly holistic and in-depth understand of every piece you use? How in-depth does you understanding need to be to use ActiveRecord/ActionCable/etc? What about underlying libraries? Protocols? Engine internals? Do you need an in depth and holistic understanding of React and all its dependencies to write () => <div>Razzle Dazzle</div>? Nah, surely not

ricardobeat 11mo ago

“Just rendering a component” takes thousands of nested function calls, covering a million lines of code; it’s not possible for a person to read or understand the whole process unless they dedicate months to it.

creakingstairs 11mo ago
Sure it adds complexity, but isn't that what abstractions are for? We are talking about grokking how data flows in _a web app in Rails_. I wouldn't think usual workflow requires going into actual inner workings of React :p
- AstroBen 11mo ago
  Well React doesn't come by itself. You need a router, probably some way of managing shared state, bundling, compiling your TypeScript, and 7 other libraries The more stuff you add on the harder everything is to understand, and the less stable your app becomes until suddenly you need specialists for every piece just to keep things chugging forward. Everything needs greasing and maintenance over time.. ..and then in 4 years the React team decides "oh you know what the way Svelte is doing things is actually way better.. we'll need a re-write to integrate their ideas". Now what? "that wouldn't happen! so many businesses depend on React!".. uh they have no obligation to make things compatible with whatever you've built. They're not working for you. What happened with AngularJS? Vue 2? Hotwire is easy to understand (React "just renders it" is a massive oversimplification) If Hotwire rewrites? I create a private fork and continue on. Who cares If I want to tweak how Hotwire works cause it'll benefit my app specifically? I do it myself I'm not against adding complexity.. but if you care at all about longevity and long-term productivity then adding React really needs a tonne more consideration than it gets
  - creakingstairs 11mo ago
    I think we fundamentally agree that we want to be careful about adding complexity to a project. Funnily enough there have been many times where I really thought Hotwire equivalent would have cut down a lot of complexity. I've also actively looked at web components at work and for hobby projects to see if we could make/keep things simpler. But maybe I'm biased because I've been working with React for a long time, I don't find it too daunting to manage dev tools around React. When React was young, I remember that there were _a lot_ of ecosystem churn but now it's more-or-less settled and I don't think it's too bad. I don't know how Hotwire works that well as most of my experience is around Elixir's LiveView, but at least for LiveView, there is also quite a bit going on under the hood to make it performant for large lists and to handle error states gracefully. And I (maybe incorrectly) assume Hotwire is similar, so I feel like it may not be not as simple as you say. (Edit: it is simpler than React though!)
    - AstroBen 11mo ago
      It also doesn't need to be all or nothing. I've become a big fan of progressive enhancement or an islands approach. Default to SSR and scale it up as needed
- lambdaone 11mo ago
  Once you give up any hope of understanding the inner workings of the frameworks you are using, you're no longer a programmer, you're a cargo cultist. Now compound this a dozen levels deep, with systems piled on systems built by people who don't understand the other systems they are building on top of, and you have the current mess.
  - spoiler 11mo ago
    Every engineer in our industry is a Cargo cultist by that definition. Including experts. Where do you draw the line? I'm sure you have one, but your line is no less arbitrary than mine or someone elses.
    - lambdaone 11mo ago
      A competent programmer should be able to at least conceptualise every level from the transistor up - not necessarily completely understand, but at least know roughly what it does, and what it rests on, and what rests on it. Transistors, gates, logic, state machines, instruction sets, assemblers, parsers, compilers, interpreters, operating systems, memory allocation, graphics, browsers, that sort of thing. Not at all unreasonable for someone with a decent computer science degree, surely? Of course, you don't have to know any of that to grasp how to bang a page together with today's web frameworks; but you end up with the resource-hogging unmaintainable security disaster that is the modern web in the process.
      - spoiler 11mo ago
        Ok, but I've worked with people who are pretty good with web dev, but I guarantee you they don't know how memory gets requested from the operating system. Like, sure it helps in some contexts, but in their context it would largely be irrelevant. For the wast majority of people, it's fine for them to know basic tradeoffs between stdlib container types. Most web performance problems today come from misusing tools, whether container types, bad algorithms, memory leaks (and I don't think knowing how an OS manages memory would help them in JS for example), DOM pollution, or oversized assets or whatever. And my take is that that people are often too overworked to care about it, rather than lacking awareness about these things lol On the other hand, if you're a systems engineer, then you absolutely do needs to know all of this stuff. And I bet you they'd navigate stuff like better than a systems engineer, because that's more useful to their day to day!
nine_k 11mo ago
I don't think a typical React rendering call is even 100 calls deep. React itself adds maybe a dozen frames. Your components could be complicated, but likely they don't add more than another dozen or two. React is pretty efficient if you hold it right, and use for its intended purpose, that is, large and complex interactive UIs.
- vhcr 11mo ago
  You also have to take into account the browser and OS call stack.
  - nine_k 11mo ago
    This does not change if you write pure Javascript that directly mutates DOM without calling any intermediate functions. Given the speed of rendering that browsers achieve, I would say that their call stack during this is highly optimized. I don't see OS doing much at all besides sending the drawing buffers to the GPU.
  - zelphirkalt 11mo ago
    And also, that with React you are not only buying into React, but also a JavaScript dependency manager/package manager. Be it NPM, or any other. Installing JS package itself already comes with its own problems. And then probably people buy into more stuff to install through that package manager. Some component library and a "router" here, some material style and a little library to wrap the root node with some styling provider or what it is called there, ... before you know it, a typical FE dev will have turned your stack into 80% React and related dependencies and the maintenance on that will continue to grow, as new features "can be solved sooo easily, by just adding another dependency" from the NPM/React world.
- ricardobeat 11mo ago
  The event handling alone is almost a hundred calls deep. Because a lot of the work is happening asynchronously, you won't see most of it when stepping through the debugger starting from a click handler for example, but try adding a breakpoint to the compiled JSX. With fibers (React >16) and a couple commonly used hooks you'll easily hit a thousand high call stack.
spoiler 11mo ago
And you think slapping ActiveRecord to a Ruby class doesn't hide thousands of lines of code? Do you need a truly holistic and in-depth understand of every piece you use? How in-depth does you understanding need to be to use ActiveRecord/ActionCable/etc? What about underlying libraries? Protocols? Engine internals? Do you need an in depth and holistic understanding of React and all its dependencies to write () => <div>Razzle Dazzle</div>? Nah, surely not