5 ms·

Is React language or a library? Does it have its own virtual machine? If I'm debugging something that compiles down to assembly, sure, I can use GDB. Why should

Is React language or a library? Does it have its own virtual machine? If I'm debugging something that compiles down to assembly, sure, I can use GDB. Why shouldn't I be able to use the JavaScript debugger? Why does React go though so much effort to obfuscate its internals to such an extreme? There are a million other JavaScript libraries that do not have this problem, for what it's worth. > It means you don't need to understand the details of how React is implemented. Isn't this the topic of discussion? Why shouldn't it be as simple as "React stores state in this variable" and I can just poke at it like any other variable? Abstractions are great, but they all leak eventually. Being able to see through the abstraction is immensely valuable, regardless of where you are in the stack. Don't confuse simplicity for its pernicious cousin convenience, which usually does not actually reduce complexity, but heralds it.

nicoburns 6y ago
> Is React language or a library? Does it have its own virtual machine? It's a library, but it does provide a runtime. As such it IMO makes sense that it would have it's own debugging tools. This is pretty common for complex frameworks. Other frontend frameworks like Angular and Vue do it. As do backend frameworks like Rails and Laravel. Or as another example you could look at Unity (the game framework). You can still use the JavaScript debugger, and I do all the time with React code. But for React specific concepts the React specific tools provide a better experience. > Why does React go though so much effort to obfuscate its internals to such an extreme? There are a million other JavaScript libraries that do not have this problem, for what it's worth. It doesn't do it intentionally. It's internals are somewhat complex for performance reasons. Which other JavaScript libraries allow you to inspect their current state with the JavaScript debugger? That's what the React dev tools give you: state inspection. IME, lot's libraries make inspecting that quite difficult (unless they're using global variables). > Why shouldn't it be as simple as "React stores state in this variable" and I can just poke at it like any other variable? The problem is that you can't typically poke variables using the JavaScript debugger. To do so you need to get a reference to the variable. And you can only reasonably do that for globals. > Abstractions are great, but they all leak eventually. Being able to see through the abstraction is immensely valuable, regardless of where you are in the stack. I guess I've just never hit into the limitations of the React abstraction (and I've done pretty complex things). Nor have I ever hit a bug in the implementation. To me it's like my database or my filesystem: sure it's great to be able to peak under the hood if I really need to, but 99.9% of the time I'm super glad that I don't. I've had much worse experiences with Angular (1 and 2) where I frequently felt like the abstraction was leaking a lot.
- xyzzy_plugh 6y ago
  As someone who works on and fixes bugs in databases and filesystems, perhaps we don't look at things the same way.
  - coldtea 6y ago
    Well, parent can find an error in a React app with a standard JS debugger, you can find an error in databases and filesystems with gdb or some such, but not vice versa. Can be as simple as that: familiarity.
    - kbenson 6y ago
      I don't think that's quite it, at least not entirely. They were complaining about how everything they found on how to diagnose and inspect the problem started with downloading a third party tool. I read this as a complaint that React doesn't provide information on what's going on that you can see and inspect (whether true or not). The equivalent for Postgres would be if they didn't document their protocol and instead referred you to a special debugger they provided, and you had to rely on that instead, making use of gdb or the equivalent much more complicated.
      - nicoburns 6y ago
        Except the React devtools extension is a first-party tool maintained by the React team [0]. They don't distribute with the library, but given that it's a browser extension there's not really any way that they could. Also, the react dev tools aren't really a debugger. There's no way to step through code or similar. It just provides an insight into React's internal state (the component tree, and any state contained within it). The equivalent would be Postgres providing a tool to inspect the contents of its caches or indexes, and the OP complaining that they can't read them when using GDB. [0]: https://reactjs.org/blog/2019/08/15/new-react-devtools.html https://reactjs.org/blog/2019/08/15/new-react-devtools.html
        kbenson 6y ago
fiddlerwoaroof 6y ago
The difference between a language and a library is arbitrary: it’s all an artifact of programming ecosystems that place a hard division between the “language implementors” and the “programmers”: every library of sufficient complexity is an embedded language with annoying syntax.

nicoburns 6y ago

> Is React language or a library? Does it have its own virtual machine? It's a library, but it does provide a runtime. As such it IMO makes sense that it would have it's own debugging tools. This is pretty common for complex frameworks. Other frontend frameworks like Angular and Vue do it. As do backend frameworks like Rails and Laravel. Or as another example you could look at Unity (the game framework). You can still use the JavaScript debugger, and I do all the time with React code. But for React specific concepts the React specific tools provide a better experience. > Why does React go though so much effort to obfuscate its internals to such an extreme? There are a million other JavaScript libraries that do not have this problem, for what it's worth. It doesn't do it intentionally. It's internals are somewhat complex for performance reasons. Which other JavaScript libraries allow you to inspect their current state with the JavaScript debugger? That's what the React dev tools give you: state inspection. IME, lot's libraries make inspecting that quite difficult (unless they're using global variables). > Why shouldn't it be as simple as "React stores state in this variable" and I can just poke at it like any other variable? The problem is that you can't typically poke variables using the JavaScript debugger. To do so you need to get a reference to the variable. And you can only reasonably do that for globals. > Abstractions are great, but they all leak eventually. Being able to see through the abstraction is immensely valuable, regardless of where you are in the stack. I guess I've just never hit into the limitations of the React abstraction (and I've done pretty complex things). Nor have I ever hit a bug in the implementation. To me it's like my database or my filesystem: sure it's great to be able to peak under the hood if I really need to, but 99.9% of the time I'm super glad that I don't. I've had much worse experiences with Angular (1 and 2) where I frequently felt like the abstraction was leaking a lot.

xyzzy_plugh 6y ago
As someone who works on and fixes bugs in databases and filesystems, perhaps we don't look at things the same way.
- coldtea 6y ago
  Well, parent can find an error in a React app with a standard JS debugger, you can find an error in databases and filesystems with gdb or some such, but not vice versa. Can be as simple as that: familiarity.
  - kbenson 6y ago
    I don't think that's quite it, at least not entirely. They were complaining about how everything they found on how to diagnose and inspect the problem started with downloading a third party tool. I read this as a complaint that React doesn't provide information on what's going on that you can see and inspect (whether true or not). The equivalent for Postgres would be if they didn't document their protocol and instead referred you to a special debugger they provided, and you had to rely on that instead, making use of gdb or the equivalent much more complicated.
    - nicoburns 6y ago
      Except the React devtools extension is a first-party tool maintained by the React team [0]. They don't distribute with the library, but given that it's a browser extension there's not really any way that they could. Also, the react dev tools aren't really a debugger. There's no way to step through code or similar. It just provides an insight into React's internal state (the component tree, and any state contained within it). The equivalent would be Postgres providing a tool to inspect the contents of its caches or indexes, and the OP complaining that they can't read them when using GDB. [0]: https://reactjs.org/blog/2019/08/15/new-react-devtools.html https://reactjs.org/blog/2019/08/15/new-react-devtools.html
      - kbenson 6y ago

fiddlerwoaroof 6y ago

The difference between a language and a library is arbitrary: it’s all an artifact of programming ecosystems that place a hard division between the “language implementors” and the “programmers”: every library of sufficient complexity is an embedded language with annoying syntax.