Hacker News new | comments | show | ask | jobs | submit login
New React Developer Tools (facebook.github.io)
487 points by sophiebits on Sept 2, 2015 | hide | past | web | favorite | 126 comments

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?

One of the key differences between even modern web SPAs and traditional desktop GUIs is that there's no unified look, and often not even a unified feel. Actually, having something that looks exactly like something else is often seen as a detriment, just read some discussions about how "bad" Bootstrap is... (and if it isn't a webview, the same is often true for Material Design)

So a lot of the work that traditionally went into widget/VCLs/etc. is immediately not necessary and probably even unwanted. You basically have to reivent large parts of the wheel anyway. The rest is often largely component-independent, mostly event handling and data binding. So a very generic component often wouldn't help you that much, which is why a lot of the MVC libraries and frameworks available often seem to "skip" that part.

One noticeable exception is ExtJS, which seems the single remaining major toolkit aiming at desktop-like applications. There you've got your standard FormPanels, GridEditors and AbstractSelectionModels. There the tables turn, and HTML/CSS is often just used as the totally abstracted away presentation layer, and you just arrange widgets in JavaScript. That means a considerable payload, and more problems if you actually need to have something more "web-like" (boy, the horror of XTemplate).

For enterprise/intranet apps this matters less, of course. Which is why Ext is still rather common there and why they can afford to actually demand money for their library, despite all the competition.

But again, you probably wouldn't build gmail/instagram/facebook with Ext.

Ironically, the vast majority of the sites look exactly the same (just like mobile and desktop apps - although these tend to have visual guidelines to stick to)...

It's a mess, I agree, but it's something that Web Components are supposed to solve. You can really think of React, Angular, Ember, jQuery Widgets, etc. as poor polly-fills for Web Components; poor because they don't interop with each other easily (which is the pain you were experiencing). With Web Components, people can author components and anyone else can use them just like they would any built-in tag like <input> and <video>. This will give you exactly what you're wanting, which is a Bootstrap or Material Design implementation that you include in your project and instantly expand your library of DOM elements.

The problem with React is that the core team has explicitly stated that they are not worried about compatibility with Web Components, so if you stick with that framework over the long term you may find yourself shut out of that bright future. The Angular team re-wrote their framework mainly because they wanted to be compatible with the upcoming Web Components spec.

So, yes, it's a mess, but it's about to get a lot better. Hop over to https://www.polymer-project.org/1.0/ to get a glimpse of things to come.

Interop isn't just an issue between components, but an issue between the browser and components, crawlers and components, and of course all the thousands of JS libraries out there.

What's great about Web Components is that they don't need custom developer tools. The DOM tree _is_ your component tree, the browser naturally highlights custom elements, just like built-in elements. Editing the DOM and CSS just works. Placing an element into a temp variable and setting properties just works.

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?

No. This is the web. We must reinvent everything every 5 minutes.

I had the impression that React's primary audience is developers who want full control over resulting DOM. While custom components are possible, you are expected to write your HTML, not wire up things and be done.

You might want to check more enterprisy frameworks like extjs.

Currently that's the case, but I'd say React is a very good candidate for good component-based solutions; they're just not here yet.

One of the reasons I've seriously been considering React for even a lot of back-end stuff is that it's really easy to create an isolated component that combines markup, styling and behavior. Once done, I can simply require() the component on either the back- or front-end, or both, and reuse the component in other projects.

Granted, for styling there's still no solution that I consider optimal, but the advantages might be worth the 'impurity' of it all. And solutions are being worked on.

And granted, there are other initiatives like Web Components that are hopeful.

But already now React is a great option if you want to create 'independent' and re-usable components. I think it's just a matter of time before a proper, popular component-ecosystem arrives, and what with React Native, there might even be some degree of 'unification' across platforms.

That's assuming we won't abandon React en masse and switch to another even cooler solution in a few years, though :-/.

I found Semantic UI 2[1] to be a pretty good collection of components that I could just drop in to a project. I am also a backend person, and found it to be pretty easy to compose widgets into exactly the configuration I needed.

1: http://semantic-ui.com/

I'd suggest starting with Redux[1], React, redux-react-router[2], MaterialUI[3] and Webpack[4]... in terms of the React ecosystem... it's a little bleeding edge, but a good place to start.

[1] https://docs.reduxframework.com/core/getting-started/ [2] https://github.com/acdlite/redux-react-router [3] http://material-ui.com/ [4] https://github.com/erikras/react-redux-universal-hot-example...

In React, Redux as a container for "state". I think your first link is incorrect, and should instead be: http://rackt.github.io/redux/

You are correct, my bad... I was only up for about 25 hours at that point... still up, and really in need of a nap soon.

You're not looking to do web development - you're looking for a pre-assembled UI library.

React isn't that. That's fine - it's not supposed to be.

Hell Angular isn't that... but as it's a framework (React really isn't it's a View library) it has more of that. Angular + Bootstrap probably does most of what you would want...

... but it's an extremely narrow need. Not a general case.

It could very well be that I've completely misunderstood the intention of these frameworks then.

I was under the impression that at the end of the day you're creating either React components and/or Angular directives when you're building a web application. And the particular framework takes care of how the view changes when the model changes, it provides you with some abstractions like Resources (to talk to REST APIs) and Routers (for navigation). Even when you look at ExtJS I don't see why they couldn't provide ReactExtJS or AngularExtJS by just wrapping their widgets so that you're either creating them with "props" or by specifying the initial "scope" if you're doing it Angular directives, for example.

Creating standardized widgets which can be "wrapped" to expose a React (prop/state) or Angular (isolated scope directive) style interface, and then "skinned" (Bootstrap or Material Design or whatever) I would have thought would be the logical thing to do. As another poster commented, perhaps this is what people are calling "Components"? However, I'm pretty sure it could be done right now with what we currently have.

If you say it's an extremely narrow need, I understand because typically I end up facing problems no one else seem to have :)

Both React and Angular are quite new to the scene and there doesn't seem to be any sign of the industry settling on either (although the enterprise is currently betting on Angular). They are designed first and foremost to make the architecture of large sites/apps manageable, particularly where JS is heavily used. React succeeds at this aim. Angular fails miserably and actually makes everything worse (which is probably why the enterprise chose to go with it).

Toolkits of the kind you're looking for (ExtJS/Dojo etc) just haven't really taken off. ExtJS suffers from having an all or nothing approach to its usage, and last I checked its approach left much to be desired. Dojo is a bit more flexible in that sense but both libraries are big and complicated as they have to do a lot of work to achieve the behaviour they require of the browser.

Browsers simply aren't designed (still!) to provide the grid-like layouts required by apps. It's generally best to avoid the complexity required to do this unless you have no choice.

Flexbox promises to make grid layouts much easier. I have to admit, the last time I tried to work with it I found it quite difficult to get to work for me.

Web components promise to raise the number of available HTML elements by creating your own. The are indended to help you move from code like `$('.datepicker').datePicker()` to HTML like `<datepicker />`.

Fundamentally, there is not going to be a standard way of doing things on the web because there is no such thing as a standard website. When you visit a website today, you could be visiting an API, an RSS news feed, a database interface), a drawing package, a computer game, etc.

Such diversity of applications requires a diversity of tools and approaches, and that is what we are seeing a proliferation of today as we explore and discover the most successful ways of providing digital content.

The problem with these front-end frameworks is, that they don't have the same scope. ExtJS is probably the most QT-like web-framework.

I like your idea of writing generic code and then expose it to Angular/React/Ember.

Including something like Backbone/JQuery would probably be harder, since it uses direct DOM manipulation. But those other frameworks have livecycle-hooks that get called when a component is rendered and have to provide the framework with virtual-dom/handlebars/etc.-templates that get injected at the right position.

Since A/R/E don't have their own CSS (contrary to ExtJS) the styling code could be generic too (which it already is in most web-apps, with the help of Bootstrap).

I think angular bootstrap handles your use case nicely. I use it for a prod site that gets a lot of traffic.


Same goes for react-bootstrap


I tried react-bootstrap and it was great. Except when you get to the point where one of those components lacks a feature you need, like say searching on the table component (I'd just like to specify that as a prop value), or there is a component you need but is missing. Now you either have to build your own, or go google for "react bootstrap XYZ component" and hope it does what you need to.

Do we really need a R/A/E/*-bootstrap everytime a new framework comes out or can we build something more generic like this (R/A/E)-[general_component_library]-(Bootstrap/Material Design/Current Button Style Trend)?

And if a feature isn't built into a QT component, you don't have to compose your own?

If you're using MaterialUI, or React-Bootstrap, you should be able to compose what you want out of more primitive components... yes, there's work there, and it isn't magic... if you want something more polished, nobody is stopping you, or anyone else from writing/creating it or paying someone to do it for you.

The issue is that instead of the web community as a whole working to create one awesome table widget we are fragmented across X frameworks creating X table widgets that all do the exact same thing.

I'm trying really hard not to make a snarky comment here... the fact is there is, always has been, and always will be a lot of fragmentation with any web technology.

Just like there's fragmentation with desktop apps... QT, wx, GTK and that's just a handful for Linux alone. That doesn't include all the Windows and OSX UI packages over the years... The web is far more flexible and diverse in practice, and also more open, so you simple see more of the options.

MaterialUI, MaterializeCSS and Bootstrap are all decent starting points... depending on what you want to do. If what you want is a nice table widget, nobody is stopping you from making one... become part of the web community you're complaining about...

If you aren't part of the solution, what are you? In this case you're supposed to be a programmer, with an itch to scratch... scratch, and share.

So if my itch is to create a shareable component that interops with any framework that wasn't really possible until web components came around. And of course I'm all for many different takes on the same problem. The issue I have is that there's no way for any one take to rise to the top for a given component because it usually only works with one framework out of the box. After seeing table components be created for jquery, then ember, then angular, then react, with no significant improvement on each other other than working with their particular framework, I definitely long for a universal way of authoring components so we can cut down on the churn and focus on actually building our apps.

So, you can take a QT table component and use it in a GTK app without a lot of extra overhead?

I don't see how this is really all that different from components in any language/environment/platform... yes, there is fragmentation.. and yes, you can mash things together, doesn't mean you should, but you can.

That said, it's an itch that has been scratched, if it hasn't been scratched for your tool of choice, dig into that... the fact is that more people are working towards enhancement from phone to desktop, and being able to work with similar controls at different sizes/rendering... table controls don't really fit outside the desktop model, which is probably why there aren't more options for react, and probably more for angular than react at that.

> 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?

We "can", and maybe there are already quit a few. However, the thing about UI is that it's more than the sum of its parts; experience is holistic, and a UI should be conceived as a whole, not as something assembled by common components.

This is fundamentally a difference between disciplines. As a developer, you'll think that reusable and isolated/modular widgets are the way to go; a UI designer, on the other hand (and not forgetting consistency), will/should(!) adapt the UI to its users and contexts.

Its interesting you use the word "component" about ten times in this post, because that's more or less exactly what Web Components are about - a set of specifications that will (hopefully/theoretically) lead to much greater interop between all this stuff. Polymer is one of the first implementations of a library built on this spec.

Keep in mind though, the environment QT runs in is very different to the web, so most of us poor web devs are at the mercy of browser vendors, and as such we're often limited by the lowest common denominator.

Same background here, same frustration with Javascript frontend in general. I've been through projects that started in pure Jquery, went to Backbonejs, have a bit of Ember sprinkled at some pages, AngularJs for the most part and are not adopting React. The Javascript ecosystem is just insane...

If you need a pragmatic, complete and battle-tested gui kit for a business app, look at http://sap.github.io/openui5/

>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

This thing will never change, whether with React or Angular.

Web dev, due to custom design of pages, is not like using native (Cocoa, Windows Forms etc) widgets where one-size-fits-all. It's more like native apps with custom skins and widgets.

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).

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?

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.

From someone who can't necessarily spend much time keeping up with how things are evolving in the web world I really appreciate this reply. I think you have a really deep understanding of the problem and your predictions about a 3 year horizon seem on point.

> 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.

Thank you for posting this. I've been wondering if this was possible. Can you share any insights that might help someone that wants to do this?

The basic idea is to have your components take optional params that are themselves components. ESPseudoish code:

    // In your components...
    let DefaultListItem = (content) => <li className="foo">{content}</li>

    let DefaultList = (items, Li=DefaultListItem) => <ul>{items.map(Li)}</ul>

    let SortableItem = (content) => <li className="handle" on-drag={(e) => dispatch('dragStart', hash(content))>{content}</li>

    let SortableList = (items, Li=SortableItem) => <DefaultList {...this.props} />

    let EditableList = (items, List=DefaultList, Li=SortableItem) => {
      <div><List {...this.props} /><button>Edit</button></div>

    let SearchResultHighlighter = (text) => <span className="imagine-this-highlighted">{text}</span>

    // -- In use...
    let source = ['foo', 'bar', 'baz']
    render(<SortableList items={ source.map(SearchResultHighlighter) } />)

    let ImageItem = (url) => <li><img src={url} /></li>
    render(<EditableList items={ source.map(x => x + '.jpg') } Li={ImageItem} />)

There's a lot of design space to play around with. For a widely reusable library, I want something like Clojure's protocols or Rust's traits so I can indicate to people what the component needs/provides without them looking at the source.

Thanks. I've been thinking about the component provides/needs issue as well. I was thinking of wrapping any passed in sub-component in "polyfill / rewire" component created from a factory that can be passed the propTypes that the parent component expects it's child to support and a map from props it will be passed to the props it actually supports. Ideally I'd like to be able to do something like switch between react-material and react-bootstrap on the fly.

That exists, for vary degrees of "exists" anyway. all the good ones are commercial products for the most part. One of the nicer ones I've used is Webix: http://webix.com

Unless you're working on a big project you should stick with Jquery / Jquery UI. I suspect in a year or two React will come close to what you want.

Downvoted for a sensible pragmatic suggestion?

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.

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).

Chrome is a mature product; in its earlier days, it received tons of praise. Now it's like git or jQuery, with a long history of stability and accolades, and now it's just a cemented part of the ecosystem.

Also, Google builds tons of things for the developer community. Anguar, Google fonts, Material design, and more, are centerpieces of many modern websites.

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.

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

This is contradictory.

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/ [2]: https://github.com/facebook/react-devtools/tree/master/shell...

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.

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.

"built on" is not necessarily synonymous with "developed on".

he was making it straight that chrome is not some enabler of anything. it's actually still catching up.

I disagree that Chrome gets little praise from the developer community. What makes you say that?

Amusing? Perhaps because it worms on Firefox as well. And perhaps Safari down the road. Amusing?

>I also really appreciate the strong commitment to open source.

If anything they did a great disservice to the spirit of open source by including this in their oss


I honestly don't care about any of their oss, but this is setting a dangerous precedent .

Is the text there substantially different than the patent grant under the Apache 2.0 license? I see a patent grant as a good thing.

There was this explanation from an HN user: https://news.ycombinator.com/item?id=8901357

But Facebook made changes since then: http://www.infoworld.com/article/2908879/open-source-softwar...

I don't know much about it, just giving you links.

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!

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

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

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.

Also it locks you in, which makes the server part annoying again.

Something like GraphQL or JSON API might be the right choice in the future.

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.

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

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.

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

It's all local, sorry.

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


  python -m http.server 8000
did the trick.

In chrome://extensions there is an option that lets you give chrome extension to content served from the file:// protocol - maybe that's what you need?

Thanks for the report. spicyj created an issue to track this: https://github.com/facebook/react-devtools/issues/172

Python simplehttpserver's default address is/was You may want to check if you don't want to accidentally serve the whole world.

Same here, trying to isolate the issue in my project, since it seems to work fine on fb.com

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

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.

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.

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?

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.

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

>I spent a week doing a lot of React projects

That's not much -- and all the projects are probably toy projects, to fit all of them in a week's span.

>while it's nice, it is what it is- a view layer.

Sure, that's why you use Reflux, Redut and some other Flux architecture helper to frame your code, ReactRouter, etc.

Any idea who Reflux plays with a non-javascript backend such as Rails or Django?

Sure. The Flux-derived frameworks (such as Reflux) don't actually care about what your backend is -- they only deal with the internal data flow of your app. I haven't used Reflux, but I am pretty sure you have to implement the backend calls (AJAX or whatever) yourself.

Can't really tell, as I've never played with client/backend side helpers (for AJAX etc), always kelp my backend independent.

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.

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?

Yup! Try it on facebook.com.

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

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!

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

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

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.

Yes it does.

> 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".

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.

Great work on this Ben!

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.

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.

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

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.

Very nice, good work!

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

React is well designed and a nice work.

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

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

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.

> 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.

The virtual DOM is just an implementation detail. In my eyes, React's big feature is that it is a declarative, component-based UI model. Look at React Native or ComponentKit - they are not built around the idea that CocoaTouch is slow, but rather that there are simpler ways to do UI than the traditional imperative approach.

> 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.

In my experience, as I mentioned above, React actually provides a fantastic abstraction that makes it simpler to build UIs. I haven't found it to be dev-unfriendly at all, the opposite actually - I find that it is a highly pragmatic, productive and pleasant way to work. But I suppose that's a matter of preference. What do you find unfriendly about it in particular?

> 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.

This point I must disagree with absolutely. I have had many interactions with people who work on React and from my point of view it is indeed a labor of love as much as any I've seen on an OSS project. Do you have any examples that you can point towards to back up your assertion? Just watch presentations by any of the React team members and you'll see that there are real people behind it that care deeply about it. Better yet, talk to any of them in person and see how excited they are! This isn't a heartless top-down mandated project by a massive organization to squeeze more money out, but rather it started off as a skunkworks project by a single engineer in his spare time who thought that UI could be simpler, that caught on within the company because it turned out to be a great idea.

> 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.

Well, isn't the world beautiful, so many different opinions! I'm extremely curious what your preferred tooling is, or any suggestions you have to make React better. Maybe you could write a longer form essay to elaborate on your criticisms above?

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

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.

The DOM is slow meme confuses me. Yes, if one isn't careful, one can get into trouble. But the same is true for all platforms/frameworks/concepts/religions.

As it turns out, the fastest way to build + update DOM, is with the DOM... #mindblown (its also the only way ;))

I believe the actual pain felt, is one of ergonomics. This is largely related to what MrBra mentioned, it turns out a complex stack is complex I suppose we just need to keep fighting the entropy us developers like to add.

As others point out, this is provably false. React's use of a virtual DOM is merely an optimization. The same principle is used in many other areas: Double-buffered rendering in graphics engines, for example.

Facebook clearly chose HTML syntax (JSX) to be familiar with how developers are used to interact with HTML, thus lowering the learning curve. As others point out, the JSX syntax is still beneficial when not targeting the DOM, as in the case of React Native. JSX is just a preprocessor, and no different than writing, say, Mustache templates.

What React brings to the table is a framework for declarative UI components. Functionally, React components are no different than, say, Backbone views (indeed it's quite trivial to port a backbone view to a React component), but the data flow principles promoted by React (unidirectional MVC, immutability, declarativity, discrete state transitions) are different, and somewhat novel in the UI/MVC space.

React is definitely not just a "patch". If you think that, you've clearly not studied it closely enough.

Thanks for the effort :), but these points are simply unsound. Far from being a patch, React offers -one- standard model for writing UIs on any platform. Thus React at its core has nothing to do with the DOM (see React-Hardware, React-Blessed, React-Native, React-Canvas...React-DOM is just another rendering target). Also, in a real-world app React drastically simplifies actual code with the tiny tradeoff of adding a small amount of complexity onto "the web stack". If you actually care and weren't just trolling, you---or a reader who shares your uninformed intuition---might enjoy this wonderful high-level overview of what React is actually about: https://www.youtube.com/watch?v=H1vW1w8k7J0

I do not know where to start with this. Not one single part is true and all of them come from a very misinformed and misguided understanding of both the DOM (and what it is, why it's slow) and React.

It's hard to unpack all of it without writing an essay.

You don't have to JSX inside your render function. You can use React's built-in factories.

Other than that, getting around slow DOM manipulation is only one advantage of React. There are many others, such as making it super easy to reason about complex code, for example by not having to worry about the excruciating details of how multiple event handlers that are bound to the same element will behave.

Separating the state from the DOM itself is a brilliant idea and the elegance with which React accomplishes this disproves your claim that it is simply an "ugly patch".

>cached-like faster DOM access speed

I don't think they are caching DOM. Instead of deleting and adding new elements, they are just changing the old ones to reflect the changes. Adding new elements are expensive.

If anyone thinks I am wrong then please provide a documentation link to the correct material

[EDIT] Not sure why some people try to be rude here. Where is your zeal to ask and learn?

It's basically like creating a diff patch, so you're close.

It is like this:

1. Create full new version

2. Run a diff with the old version

3. Patch

Because of 1, it is bound to be slow (in a computational complexity sense). Based on the popularity of React and its wide acceptance, I wonder if people learn computational complexity theory anymore these days?

PS: yes I know there are tricks to make 1 faster, but these are really hacks (require extra thinking and are error-prone) and deviate from the original "React" philosophy (they are basically the old style of doing things), so these don't count.

Part of implementing an efficient React app is making sure that prop/state transitions are minimized. Coincidentally, this is also (abstractly) true about any UI technology, not just React. But React sacrifices a little bit of speed in order to make the UI declarative, as opposed to the finicky, error-prone and messy way we used to do it before with frameworks like Backbone.

Have you actually developed a large React app? Because you might be surprised at how fast React really is in practice.

Large React apps are actually no faster than large apps written in Ember or Angular, and I've personally been surprised by how slow React got on a large app. At some point, in every framework, you will run into bottlenecks and none of them provide silver bullets.

> Large React apps are actually no faster than large apps written in Ember or Angular

This is (more or less) true now. It wasn't when React first showed up. Angular is also only just as fast when you actively code your apps in the same way as React (basically using a prop/state system but in an Angular way). This isn't also the method generally championed in Angular (1.x anyhow).

Ember was always pretty fast but post-React it changed a lot of how it did it's rendering... influenced by React!

So claiming that React apps are no faster is a bit disingenuous as the reason for that is because the other frameworks saw what React was doing and agreed with it.

Actually, simply using "track by" in Angular puts it on par with React's performance regardless of whether or not you follow React's patterns. You do understand that Angular 1.x's $scope is essentially a virtual DOM inasmuch as it's a javascript representation of the DOM which provides a more efficient means of diffing (dirty checking in Angular's case). "Virtual DOM" is just a fancy buzzword for React's solution to figuring out what to change. React's requirement that the entire DOM tree be re-rendered any time any state changes meant that dirty checking would be prohibitively expensive, so they had to come up with a clever workaround which, to their credit, ended up being just as performant as Angular's dirty checking.

You can use Angular 1.x in exactly the same way you use React by only ever using 1-way binding and constructing your entire application out of directives scoped to elements. The only thing Angular 1.x doesn't let you do is use JSX, but then again, you could just use plain old javascript and imperatively build up your DOM elements (which is what JSX does under the hood anyways) if you really don't want to have .html files.

Sure, but the fact that React is as fast as those other frameworks, with none of the code overhead of having to manually patch the DOM, is a benefit. React doesn't need to be faster, it just needs to be comparably fast.

What do you mean by "none of the code overhead of having to manually patch the DOM"? None of the other frameworks make you manually patch the DOM, they all do it automatically in their own way.

I actually don't know Angular or Ember well — before React I was largely using Backbone, where DOM patching is manual unless you use templates, so that's really what I was referring to. The benefits apply to those frameworks, too, then, of course.

mmm not quite.

Step 1 would be slow if it created it in a real dom but as it's not (that's why it's called a "Virtual DOM") and is in fact just an object representation of the dom it's actually rather fast.

After all - it's just an object tree, and that's quite fast to parse.

The diff part is probably the slowest part in the React chain actually - because it actually has to compare to the other (virtual) representation of the DOM. Deep comparisons are just... well they'll never be trivial.

But no, it's really not extra thinking, it's not error prone, and it's basically due to it not really being what you're describing it as.

I think you totally missed the point.

Let's say that you have a page containing a billion little images. On every update, your React-enabled code needs to create a virtual DOM containing all those images. This takes time, regardless of whether the virtual DOM is fast. Hence my point.

And even if it may be only a few milliseconds for a hundred images, it will take seconds or even minutes for millions of images. And even if only 1 of the images changed. This is of course not acceptable.

Most programmers are already happy if it works for 100 images. However, imagine that the inventor of quicksort invented bubblesort instead, stating it is fast enough for 100 elements. From a CS point of view, this situation is just ridiculous.

What would it the the new style of doing things, for the non-academic rest of us ?

Succinct and to the point.

See my comment elsewhere in this topic.


Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact