
New React Developer Tools - spicyj
http://facebook.github.io/react/blog/2015/09/02/new-react-developer-tools.html
======
laichzeit0
This is going to be slightly off-topic. I'm mostly a "backend" dev (C/Java,
server side things) that recently had to do some frontend dev again after
about 4 years. The last time I did this jQuery/Bootstrap was the trend. So
this time I played with React for about a month, then went to Angular
(coincidently starting with React components and being an Angular virgin made
me think of making everything isolated-scope directives in Angular).

So the problem for me was not React being bad or Angular better but at the end
of the day it has to do with: As a non-fulltime webdev I need a _complete_
widget/component library available for when I want to build my apps. With
React I felt like I was constantly either having to look for components that
kind-of/sort-of worked for me but had some short falls or I had to build them
from scratch. Then there's the look and feel so you're either looking for
components that are Bootstrap ready or Material Design-ish, etc. Even then,
you take Angular Material: it's not there yet. Go to the website. That side-
nav menu they have going is really nice. I wanted to use that in my app. Is
that an MD component? Nope. It's a hacked together mess of custom things. Talk
about "eating your own dog food".

Is this common place in the web world right now? Regardless of choosing
React/Angular/whatever. I mean I'm used to QT. There's a widget for just about
anything. You just wire up your events and you have an app. It seems like the
web world is slowly just going to end up reinventing Delphi at the end of the
day when I look at things like Polymer (why has it taken so long?)

All these frameworks are great but can we please just work on having feature-
rich components/widgets now. And maybe keep them maintained for the next 5
years or so?

~~~
grayrest
I've thought about why widget libraries don't work on the web since 2008. In
2007 I was making iOS webapps, in 2008 Apple put out the SDK and the native
apps were better. I decided that the native apps were better because the devs
didn't blow 60% of their time budget building a poor, custom widget library.
The problems I've encountered:

The first and most basic is that the expectation on the web is that every
project will have a unique look and feel. This greatly limits the adoption of
frameworks based on desktop widget library concepts (dojo, ext, sencha,
cappuccino, sproutcore). The times I've used these frameworks, I spend as much
time fighting the look and feel as I would building an interface from scratch.
This isn't a problem if you're look and feel insensitive and desktop style
widget libraries do get picked up for internal corporate apps.

The second problem is size. The need to download everything, desire for
reduced page load times, and lack of dead code elimination has historically
made web devs more sensitive to the size of their libraries. This was a
problem for libraries like YUI2, which had excellent components that simply
had an option for anything somebody at yahoo wanted but adding a new widget
would frequently add hundreds of K to the download. This is a reduced concern
with the increased capabilities of mobile and I believe that the combination
of HTTP2, having a standard module system, increased tooling (e.g. webpack),
universal/isomorphic JS, and ServiceWorker provide the means to more or less
eliminate this as a core problem.

The third problem is CSS. The language provides no tools for abstraction when
the target markup (your widget) is fixed. Happily, this problem is solved via
sass. You can separate style concerns into mixins (or placeholders) and
compose them into either widget or instance specific rules and avoid the
cascade.

The fourth problem is component composition. In order to get more code reuse,
you need to be able to build up bigger widgets from small pieces and then make
a lot of useful small pieces. Stateful components don't compose particularly
well and I've spent a lot of time on this (in yui3, knockout, and angular)
before I found React's virtual dom approach two years ago. With the vdom, it's
possible to view components as functions projecting state onto a virutal DOM.
Composition can then be solved by creating higher order components and using
normal functional programming composition and code reuse. With care put in to
how larger components are designed, it's possible (I've done it) to swap out
sub components to customize behavior on a per-instance basis. I consider the
core problem solved but I haven't seen the equivalent of an underscore for
react components yet.

The fifth problem is widget interaction. I define widgets as components that
are an isolated concern (and generally maintain internal state): Autocomplete
instead of FooList. Since the components are generally stateful and produce
events, you have to have a protocol for having them interact with each other
and the rest of the app. As an example, a FOO widget is a React component has
PropTypes that get compiled into a Falcor query and all its event handlers
call a function `dispatch` with an object shaped like X. Everybody comes up
with this in their app but without a consensus on what the approach is,
everybody's widget libraries are parochial. This is an active area of
development and Web Components is Google's take on the problem. Facebook is
also very interested in this with Flux/GraphQL.

Once all the problems are solved (I believe we're relatively close) then we
should see widget libraries come into their own. I'm estimating about 3 years
before someone starts really winning the widget library battle and we get a
"standard" set of widgets you're looking for. I believe that something from
the React or Ember communities are the likely source and Polymer has an
outside chance (I don't see how component composition works in Polymer).

~~~
spankalee
Component composition works great in Polymer - it's just the Shadow DOM spec:
child elements are distributed into the Shadow DOM via <content> tags. The
result is what's called the composed tree.

Because standards, you can compose Polymer elements with native elements or
custom elements built with or without a helper library like Polymer.

What part is confusing?

~~~
grayrest
Not so much confusing as my own ignorance. My last pass through Polymer was
two years (I think) ago and there's been a number of changes to the components
specs that I've been ignoring. At the time I saw a lot of excellent
examples/docs related to encapsulation and none related to content insertion.
I'll take another look later this year.

------
ericjang
The software engineering quality of FB's open source projects is simply
amazing.

I used to think that a lot of their projects were trying too much to re-invent
the wheel, but now I see it as an uncompromising attitude towards having the
most streamlined development experience. I also really appreciate the strong
commitment to open source.

~~~
philip1209
I find it amusing that Chrome, the Google open-source project that this is
built on, receives so little praise in the developer community. Perhaps it is
because Facebook builds things primarily for developers, versus Google which
seems to be function-driven (eg bettering the whole internet instead of self-
serving within the developer community).

~~~
tacone
It is not specifically built on Chrome. It happens to be developed on chrome
because that's the tool of choice of Facebook devs. Incidentally, a Firefox
version is now available.

~~~
argonaut
> It is not specifically built on Chrome. > It happens to be developed on
> chrome

This is contradictory.

~~~
cjhveal
In fact, it isn't. From a quick perusal of the github repo[1], it seems that
the react devtools can mostly stand alone, and have wrapping shells that
access the Chrome and Firefox APIs when necessary. Here's the plain shell:
[2]. My understanding is that the GP was trying to convey this architectural
flexibility while pointing out that the Chrome shell is more mature because it
is the tool of choice for most devs at Facebook.

[1]: [https://github.com/facebook/react-
devtools/](https://github.com/facebook/react-devtools/) [2]:
[https://github.com/facebook/react-
devtools/tree/master/shell...](https://github.com/facebook/react-
devtools/tree/master/shells/plain)

~~~
argonaut
It is, at least the way the OP put it. I was pointing out the absurdity of
saying something A isn't specifically built on B, then immediately
acknowledging that A is in fact built on B.

But I'm happy to hear the original statement isn't totally accurate.

~~~
tempestn
There's a difference between being "built on chrome", ie relying on the Chrome
source, and simply being developed on Chrome, ie developed using Chrome. It's
like someone building a website. They might use Chrome to do their
development, but that doesn't mean the website is somehow built on top of
Chrome.

------
estefan
I've just started building the app I've been trying to build for the last 5
years again. I'm on about version 29 now. I've tried jquery, ember, angular,
native android all with REST (which I found to be a complex time-sink), grpc
(has potential but a bit too non-standard/bleeding edge), and was just looking
at swagger when I came across the FB stack of react, relay & graphql. This is
like heaven.

No more faffing around with marshalling/demarshalling and such a simple API
code generation on client & server aren't even necessary. Plus, react makes
the UX incredibly responsive _and_ in future I should be able to use the same
server as a backend for native IOS and Android apps which I'm hoping should be
pretty quick to chuck together once I've worked out the business logic for a
website. It's like a different world since last time I did front end work, and
I think this time I might actually be able to create the app I want to, while
having something that's maintainable and boiler-plate free. Thanks Facebook!

~~~
k__
Yes, I think the server part is the most annoying.

~~~
dfischer
Check out Meteor, it makes the server part easy. :)

~~~
estefan
I tried meteor shortly after it was released. It wasn't clear whether there
was a path to making a native app and it felt like there was quite a lot of
magic going on. I wasn't sure I'd get the security right and wasn't clear on
whether it could scale beyond a single server. I preferred the idea of REST
because I could drop in caching proxies etc and knew it was stateless. Of
course, things might have changed now.

I guess there's no parallel for react-native though, which is really the
killer feature for me. GraphQL & Relay are really the icing on the cake.

------
abritinthebay
It really can't be emphasized how much better this version is over the last
version.

It's like going from IE Dev Tools in IE7 to Chrome Dev Tools. Night and Day.

~~~
baddox
Indeed. I've been using it since they published the first beta, and it has
seemed as stable as can be.

------
arm55
Since the upgrade, I'm just getting "Connecting to react...If this is React
Native, you need to interact with the app (just tap the screen) in order to
establish the bridge." when I try to load the dev tools.

EDIT: Apparently the tools don't work for local dev. Just hosted the files
behind a python simple httpserver.

~~~
spicyj
Any chance you can file an issue with a link to your site so I can look into
it?

~~~
arm55
It's all local, sorry.

~~~
brbcoding
That actually may be part of the issue... I just spun up a server behind mine
and it works now.

~~~
arm55
Yup.

    
    
      python -m http.server 8000
    

did the trick.

------
49531
Man, this makes you feel like vanilla html / css (and the DOM) are almost like
browser machine code.

------
quaunaut
Since the developers are here in this thread- I'm curious where this goes from
here. I'm an Ember developer, but sometimes Ember's heavyweight attitude isn't
needed for a project, and I see React as the natural direction to go when I
want something smaller.

Seeing something like this, and the strength of having developer tools like
Ember Inspector or React DevTools, is just going to make frontend development
so much easier.

~~~
Cshelton
Once you do web development the "react way", you'll probably drop Ember for
every project and stick with React. Just saying. I've probably built over a
thousand React components at this point. I've used all the other frameworks,
knockout, Angular 1.x, ember. React is by far the better way to do things as
of now.

~~~
quaunaut
Personally, I'm not as confident. I spent a week doing a lot of React
projects, and while it's nice, it is what it is- a view layer.

When interacting with a complex web of routes, models, components, and
templates, I have found Ember to be similar to Rails in terms of
expressiveness and speed of development.

Then again, I don't know a lot of the tools that people use to solve these
problems in React- the most I ever encountered was having to do most things
manually, but having page layout managed by React. I was still managing my M
and C. What do you usually use to ease the work there?

~~~
k__
Most people who say they use React usually don't use it stand-alone.

When I say that I use React it includes the whole client-side stack.

React, react-router (inspired by the Ember router), Redux, react-bootstrap and
newforms.

This is a bit like using Ember, Ember-Data, Bootstrap and ember-forms.

~~~
quaunaut
Thanks! I'll give it another shot, using those exact tools. Is there any guide
out there for the usual application structure?

------
mrspeaker
If you're using a recent version of Firefox (like Nightly) you need to set
xpinstall.signatures.required to false in about:config to be able to install
the unsigned add-on.

------
jallmann
Looks awesome. Does this still work with JSX that's been precompiled and/or
minified? Eg, after a build step involving Babel, Closure Compiler, etc?

~~~
spicyj
Yup! Try it on facebook.com.

~~~
TheAceOfHearts
Whoa, that's freaking awesome! Peaking at how Facebook is implementing some
components should be fun.

~~~
Ambroos
Try Netflix, their interface has some fun elements that are easy to recreate.
Looking at the state and props (even modifying them) is a great way to get
inspiration for your own components.

Or messenger.com, which is an impressive React application too!

------
joe-stanton
An enormous improvement over the old dev tools! Good work FB team.

------
sergiotapia
Does this work with MeteorJS? I'm going to try it out though, looks really
interesting!

~~~
jakecraige
This will definitely not work with MeteorJS. It's a React tool built around
their framework. I don't think there's anything like this for Meteor yet.

Unless you mean does it work if you use React within a Meteor app. If so, it
may.

------
felixrieseberg
> We're calling it version 0.14, but it's a full rewrite so we think of it
> more like a 2.0 release.

I love React, but that just seems like a bad idea. Especially given the fact
that the previous version was called "v2-beta".

~~~
spicyj
Did we use that number anywhere? The only place you should actually see this
version number is in your browser settings so it shouldn't really matter.

Edit: Oh, I see we did. The version number in manifest.json and package.json
was 0.14 though… I'll leave it like this but will bump it up to 2.0 if it
causes any serious confusion.

~~~
Exuma
Great work on this Ben!

------
krebby
Any plans to make it integrate a little nicer with Immutable.js? Currently
it's impossible to update Immutable props and have them reflect live in my app
through React Devtools the way that you can with plain JS datatypes.

What would be really awesome is if there was something similar to Chrome Dev
Tools' "store as global variable" feature, so that I could edit props in the
console and then pass back to React.

~~~
spicyj
Yes, we'd like to do that sometime, at least for viewing Immutable data
structures easily. We already have "Store as global variable" if you right-
click.

------
dopeboy
Just started a client project with React. This will be very handy. Thank you
Facebook.

------
aidenn0
Wow, just played with this and it is insanely better than the previous
version. Now I just need a feature to add to my react webapp so I can use this
to debug it.

------
iamstef
Very nice, good work!

------
jtchang
Whoa awesome! And it even shows you props, state, and context for each item.

------
MrBra
React is well designed and a nice work.

It's the idea behind it that is totally flawed and doomed.

~~~
sergiotapia
It's a shame you were downvoted, I enjoy technical discussions here. Can you
elaborate why you think React's approach is bad?

~~~
MrBra
Because it's built on the assumption that just because DOM access is slow,
then it's a good idea to just add another layer of JS in order to provide a
cached-like faster DOM access speed, rather than focusing on fixing DOM access
speed issue itself.

React augments the complexity of a stack that it's already too complex, to an
unneeded, non-sustainable and dev-unfriendly way in which we are supposed to
use HTML tags inside JS scripts.

React is just a Facebook's own short-sighted solution to slow DOM
manipulation. The fact that it is OSS doesn't make it necessarily a good
thing.

React is not a product of love for a greatly engineered system, but obviously
just a product of FB's understandable necessity to work faster "today and
here", in order to keep bringing home their daily profit.

React is not a solution, it's a patch, a ugly one.

We are not forced to like it just because FB made it and made it OS.

~~~
mynegation
I wish you would start with this argument, instead of the one that looked very
much like trolling.

Can DOM be faster? Maybe so. Does that mean React is a bad idea? No. In fact,
React is Multiple Buffering[1] in the age of DOM. It is not that DOM is slow,
it is that change of DOM triggers the layout and layout is inherently slow,
because it is complex.

If you do not need re-layout on each DOM change (and most of the time you do
not), React allows you to batch changes in a very clean way.

[1]
[https://en.wikipedia.org/wiki/Multiple_buffering](https://en.wikipedia.org/wiki/Multiple_buffering)

~~~
throwaway41597
There isn't a relayout on each DOM change. Changes trigger layout when you
read DOM properties such as clientWidth or when the event loop loops.

