New React Developer Tools

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

http://angular-ui.github.io/bootstrap/

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.

    // 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} />)

This is contradictory.

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.

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

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.

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.

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.

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

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

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.

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

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?

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

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?

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.