[m0dc]

The problem with coalescing around React is that it's not really a framework. The lack of a default Rails-like monolith encourages every dev to assemble their project from a la carte pieces - so every React app has a different project structure, a different data library, a different build tool, etc. Even worse: since everyone wants to build their app "the right way", there's constant churn as new best practices and micro-libs are introduced every couple of months.

I'm really hoping that one of these React dialects will win out soon, as it's not really a "common language" until everything is mutually intelligible.

[brightball]

I'm not an expert in this area, but the impression that I've gotten from the React front is that one of the benefits and reason for traction it isn't a framework as much as a very good way to handle the view layer that's flexible enough to let people take liberties with the rest of their application design...and the way that it handles it works very smoothly with server side rendering as well.

Much like jQuery being able to work with other JS libraries smoothly was a big selling point, React seems to be providing a modular approach that's flexible enough to work with many of the more opinionated options out there without having to dictate everything about the application.

One of the biggest churn points around JS frameworks wanting to do things this way or that way, full single page app or hybrid server side / client side, integrate to existing site or build from scratch.

End of the day, the browser is the view layer. Most of the other frameworks that try to make it significantly more than that are always going to lose when being applied to existing systems or server side heavy systems.

The React approach is basically just simplifying and removing pain points. It's easier for Rails to define some standards on the server and database side because the server side is where the core logic of every application lives. You're not going to try to apply Rails to an existing application, so it doesn't have to worry about fighting that battle. That is a major consideration of client side code, which is why you're seeing more wide spread usage of React. It fits more use cases instead of trying to be Rails in the browser.

[EdSharkey]

React is a UI component framework. The testing-in-isolation and composition you can do with React makes it very productive. It's good for reasoning about the fine details in a UI.

Yeah, it would be good to get a router and couple that with React. React is not a total solution for making a web app, and anyone that picks it up seriously will learn that very quickly.

We need lots more libraries like React that focus on one area of development and do that well rather than all these own-the-world frameworks that have both shiny and awkward parts. I want devs to do their front-end library selections very carefully and build a mosaic that fits together well for their app's particular use cases.

[sotojuan]

Doesn't seem like it will ever be that way for React to be honest. If you want a JS monolith try Ember. Angular 2 may also be that way since it uses Ember's CLI tool.

[m0dc]

I love Ember - and one of the best things about it is its emphasis on convention over configuration. React is the exact opposite. While it's an amazing library, it only makes up one part of a front-end stack, which causes everyone to waste tons of time deciding on what the other parts should be.

A set of sane, accepted defaults would help the community tremendously. Personally, I'm hopeful that that's what React/Redux/Webpack turns out to be.

[brightball]

I'm going to take a leap and assume you've done some Rails work because Ember tends to have a lot of Rails users.

In Rails, there's a default view layer handled by ERB but it can be mixed and matched with HAML, Slim or any other view layer. Likewise, you can use ERB, HAML and Slim outside of Rails entirely.

There are frameworks like Meteor that let you have an interchangeable view layer. There are others that build the entire full stack framework around THEIR view layer.

If Meteor made React the default view layer...that would be a step towards unifying the fronts. One full stack system with a shared layer that can be use inside or outside of that particular framework.

[greggman]

This seems to be what meteor is trying to be. A fullstack. Crossing my fingers. Some devs want to pick and choose. I just want it all decided. Let me get to my app.

[brightball]

Yep. Meteor is taking the flexible approach. With React taking the View only approach it makes it easier to just plug in with Meteor.

https://www.meteor.com/tutorials/react/creating-an-app