7 ms·
React DevTools are very valuable. But only because React, with transpiling and the shadow DOM and all that is so inscrutable. There’s no hope of understanding
by erikpukinskis 7y ago
React DevTools are very valuable.
But only because React, with transpiling and the shadow DOM and all that is so inscrutable.
There’s no hope of understanding the DOM with React, no hope of understanding styles with styled-components.
There’s no hope of placing a breakpoint in your code and tracing forward through events. No hope of understanding stack traces.
The DevTools begin to address some of those deficiencies. It does help, but still leaves me thinking the tradeoffs weren’t worth it. You can never reach simplicity, only manageable complexity. In the long run it leaves an opportunity for a new generation of tools that respect JavaScript and the DOM.
- onion2k 7y agoThere’s no hope of understanding the DOM with React... You can still understand the DOM in a React driven app though. The component output is there for anyone to read. I do that every day. All React is doing is generating DOM content and then working out the smallest update necessary when the state changes. The problem that React Devtools addresses is that it's the component output that's there, not the components themselves. There's more information behind the scenes, and that is what React Devtools lets you peek in to. It does help, but still leaves me thinking the tradeoffs weren’t worth it. You have to reason about the way you write code, what your apps need, and what works best for your users. If the tradeoff is that using React's features means you can no longer work with the complexity of what's happening in the browser and that's slowing down your development process then don't use React. Your development process and your users are way more important than any framework.
- blueprint 7y ago> You have to reason about the way you write code, what your apps need, and what works best for your users. Not to use too-harsh language but that's a cop-out in my opinion. Yes, some tools are better for a given job than others. But we're working with general-purpose machinery for the purpose of building UIs and applications. There isn't really a differing set of requirements or problems in that domain. ... and if that's true, then it means that one size should actually fit all. I think, personally, UIKit is excellent. I think people don't understand how to use it properly… they don't understand how to write good imperative code, so they look to a declarative system as a way around that… but I think they're only deferring the inevitable or shifting non-problem-inherent complexity they couldn't initially solve.
- erikpukinskis 7y agoMy employer uses React. At home I don’t.
- ghego1 7y ago> There’s no hope of understanding the DOM with React, no hope of understanding styles with styled-components. There’s no hope of placing a breakpoint in your code and tracing forward through events. No hope of understanding stack traces. Agree. IMHO the fact that React uses the virtual DOM is one of its biggest inconveniences. > In the long run it leaves an opportunity for a new generation of tools that respect JavaScript and the DOM. Angular (v. >= 2.x.x) on this is much simpler to understand as it manipulates the DOM directly. With the built-in dev tools of any browser you pretty much can inspect any portion of HTML, CSS and source code.
- nojvek 7y agoOne of the reasons why I love webcomponents. It’s a simple api and plays well with the dom. Wanna innerHTML some string? Boom it works. document.createElement(‘my-foo’). Works. addEventListener. Works. Dom explorer shows the elements. document.querySelector finds your tags. Css just works. Nothing new to learn. Custom elements let you be just another html tag and do your magic. Not fully sold on shadow dom but web components api is simple and I love it.
- chrisco255 7y agoAll of these things work with React, too. React appropriately names the prop to "dangerouslySetInnerHtml" because it's vulnerable to XSS attacts and a lot of beginner web developers don't realize that. CSS has of course always worked just fine with React (as does LESS and SASS). Styled-components is totally optional. There's tradeoffs at scale with trying to use an imperative style of coding with document.querySelector or JQuery. Fine for simple websites. Absolutely awful for complex web apps with large teams. Dom explorer is still a tab in Chrome for react devs. I readily switch between the React devtools and Dom explorer all the time. The reason in my mind, for React, is that it's a higher level, functional abstraction above the DOM that makes complex web development manageable.
- mosselman 7y agoOne of the downsides, depending on implementation mostly of course, that you still need JS to render your component. I prefer server-side rendered HTML over both React and web components because of the compatibility. After showing the HTML you can still make elements more interactive with things like jQuery, Stimulus or Freudjs (disclaimer: my own)
- danabramov 7y agoIt’s worth nothing you can do server rendering to HTML with React, too.
- mosselman 7y agoIt is, but I meant more in a 'traditional' way, so rendering with some templating engine whose abstractions aren't so far detached from HTML as they are with React. Mostly by mixing some dynamic parts into HTML rather than the other way around.
- SzamarCsacsi 7y agoTime-travel debugging is miles better than the old way of placing breakpoints. For me, debugging with breakpoints was always a pain. I often skipped through stuff accidentally and had to start all over again from the beginning, or accidentally went inside some third-party library code that I did not intend to, or placed the breakpoint at the wrong spot. It was just slow and inconvenient, unlike React DevTools where you can see every change and step forward or backward, replay events and observe the state at various points without having to put watchers on every variable / expression.
- true_religion 7y agoTime travel debugging is Redux devtools, not React devtools.
- SzamarCsacsi 7y agoOh, you're right. Been working with Vue lately where the component and Vuex inspectors are packaged into one devtools, that's why I got confused.
- tigershark 7y agoYou can return back to the previous statements in any decent debugger instead of starting from scratch. And by default they don’t go inside third party libraries unless you specify that it’s what you want. What kind of debuggers were you using?
- oauea 7y ago> You can return back to the previous statements in any decent debugger That's a bit of a stretch. What debuggers are /you/ using?
- mcintyre1994 7y agoYou can move around the execution in the VS debugger - if you’re at a break point you can move execution earlier in that function etc. That’s the only debugger I’ve seen doing that though.
- mosselman 7y ago> You can never reach simplicity, only manageable complexity. A great phrase that puts my feelings about React or any other front-end JS framework into words. Thanks for that.
- mieseratte 7y agoWhat’s wrong with the in-browser DOM inspector? I’ve never run into a problem with React, it’s output, it’s error messages, or anything else such that I couldn’t trivially dive in and fix. I’ve never once felt the need for React DevTools in my 5 or so years of React. I remember AngularJS well, that’s a framework I can do without.
- DrJokepu 7y agoInspecting the state or properties of components. Inspecting the component hierarchy (not always possible to guess it from the DOM). Things like that.
- waveymaus 7y agofor me, a lot of it is simply not having to go in and add in console.logs to everything to see what props and state are, you can just explore around instead
- ivanhoe 7y agoThere's a problem when you set breakpoints trough DevTools and instead of Chrome breaking on that line, you end up in some VM1234 file with a bunch of minimized react core code in it.
- sureaboutthis 7y agoI'm always suspicious of one tool, that is supposed to make work easier, needing another tool that makes the tool easier.
- k_bx 7y ago> It does help, but still leaves me thinking the tradeoffs weren’t worth it. You can never reach simplicity, only manageable complexity. 100% agreed. May I shamelessly plug my enormously positive experience with Elm here, with DOM being DOM, always-present time-travelling debugger, no runtime exceptions and other nicities? Main point is that you don't have to do the tradeoffs sometimes if you go full way towards a different, pure, statically-typed language. The analog of styled-components exists, but I never used it, just regular BEM+SCSS.
- draw_down 7y agoSorry, what relationship between React and shadow DOM are you claiming?
- ronaldj 7y ago"There’s no hope of understanding the DOM with React" This is false. I've been developing with React for over a year and a half and have never used the React dev tools. I've only ever used the browser's web inspector and it's fine. We don't write CSS in JS, so this could play in to that, but when we were evaluating those solutions it wasn't impossible to figure out what was going on, even if you had hashes for class names.
- ulisesrmzroche 7y agoYou’re probably using super basic react then. Start adding some more to the plate, and you’ll get there.