Framework in the works?

[chrisvfritz]

Are there any plans to build a framework that ties redux, react, react-hot-loader, and webpack together? That in and of itself would be rather simple, but then the (also relatively simple) inclusion of generators would save thousands of collective hours and also help these tools gain popularity (Rails, for example, became quite famous for the "5-minute blog").

I also see the potential for built-in debugging tools (maybe via a plugin system), for truly Bret Victor-esque development, even beyond what @gaearon has demoed so far. Is this already in the works or should it be developed independently?

[gaearon]

I don't have such plans but feel free to build one!
I'd be wary of fragmenting the community though.

I also see the potential for built-in debugging tools (maybe via a plugin system), for truly Bret Victor-esque development, even beyond what @gaearon has demoed so far.

This doesn't require a framework. Check out redux-devtools issues.

[ForbesLindesay]

I am working on something almost exactly like this (with the minor exception of browserify instead of webpack). When finished it will be called "moped" it will combine:

• express - although it will probably work with any node.js web framework
• browserify - via browserify-middleware extended to add hot-loading via browserify-react-live and browserify-patch-server
• react
• redux & react-redux
• react-router
• babel - with source maps supported by default

It will support seamlessly writing universal apps and have built in support for doing "Flux over the wire" style communication. I also plan to build a plugin for real time using primus and another plugin for doing declarative queries via an @query decorator. The @query plugin will also have full support for real-time.

It should then be possible to do a nice job of the "5 minute twitter clone" or the "5 minute chat room" or the "5 minute collaborative task list".

Although it's a little broken at the moment, and running on an out of date version of moped, you can see an example of what an app developed using this technology might look like at https://github.com/ForbesLindesay/chat-example/tree/master/app.

[cesarandreu]

I do think that having a "framework" that shows you how to glue together a bunch of libraries can be useful. One of the big problems right now is that you need to sorta figure out how to glue em all together just to get a more complicated app up and running.

I know of at least one project that seems to be trying to tackle this: esex.

[ghost]

Rather than a framework, I might suggest an open-sourced production
application built using the ecosystem. Or better, several of them.
What worries me about a framework is that it locks in a certain
configuration of components from the ecosystem.

Getting real applications out in the open that use these awesome
innovations along with great zero-to-production walk-throughout/ tutorials
for building them is going to be one of my major goals.
On Mon, Aug 10, 2015 at 3:35 PM Cesar Andreu [email protected]
wrote:

I do think that having a "framework" that shows you how to glue together a
bunch of libraries can be useful. One of the big problems right now is that
you need to sorta figure out how to glue em all together just to get a more
complicated app up and running.

I know of at least one project that seems to be trying to tackle this:
esex https://github.com/esex/esex.

—
Reply to this email directly or view it on GitHub
#450 (comment).

[ForbesLindesay]

My thinking is that a "framework" should never be more than a couple of hundred lines of code, and it should be an explicit goal that a user could rip out that framework and change to doing things manually with only minimal effort.

[chrisvfritz]

Thanks for the update @gaearon! And thanks @cesarandreu and @ForbesLindesay for sharing some existing work towards a framework.

@danmartinez101 An advantage of a framework over an open-sourced application is that you don't have to figure out where to start. You have generators to implement all the boilerplate for you, as well as sane defaults. It's a lot easier to dive in, get something minimal working, then keep learning as you go.

Since this issue doesn't require any further action or answers, I'll close this (which doesn't mean folks can't still contribute to the conversation).

[calesce]

My personal preference for a "framework" here would be a starter kit/generator for each combination of React ecosystem libraries (using/not using Redux, React Router, RX, etc) that just gives enough boilerplate to glue stuff together without having too many opinions. Luckily there's already a bunch of these out in the wild 😄

I guess a single generator could let you make these decisions step-by-step, but I had a bad experience with previous Yeoman generators when trying out Angular stuff, so I'm kind of scarred from that, haha.

[sergey-lapin]

Yeoman generator would be great actually as it is awesome entry point for newbies but I agree with @calesce on his concerns. I guess it is harder to maintain generator that some seed project. Because of that generators start to make some outdated stuff. And for the same reason if a generator behaves slightly different that you expect it is very hard to customize it.

[nhagen]

Yeoman has its benefits, but fur redux, how much effort would it really
save anyone? There's really only one type of thing to generate (actions),
and the code output would probably be less than 10-15 lines of code. That's
my initial guess at least; I'd be interested to know what would actually be
possible there.
On Aug 12, 2015 7:05 AM, "Sergey Lapin" [email protected] wrote:

Yeoman generator would be great actually as it is awesome entry point for
newbies but I agree with @calesce https://github.com/calesce on his
concerns. I guess it is harder to maintain generator that some seed
project. Because of that generators start to make some outdated stuff. And
for the same reason if a generator behaves slightly different that you
expect it is very hard to customize it.

—
Reply to this email directly or view it on GitHub
#450 (comment).

[sergey-lapin]

There also a lot of plugins and related packages that yeoman can handle, there could be react-router or not, lots of usage cases..

[davidjnelson]

I think the big benefit would be being able to get up to speed faster. For instance, with angular, everything is there for you, and the documentation explains everything you need to know. With react, redux, babel, webpack, etc. there is a lot of up front time involved in getting everything configured and choosing best practices. Although I must say a lot of these individual projects have great documentation, especially redux!

Boilerplates are useful, but not nearly as much as if everything was packaged into a framework of some sort.

It's tricky because everyone has different use cases and different library and best practice preferences. If there were one framework that had sane defaults for libraries and best practices you could swap out if needed, that could be really great. There might be room for one that does universal rendering, and one that is client side only for folks who are migrating from a legacy / non node app as well.

The biggest productivity boost for getting started would be comprehensive documentation of using the sane defaults for libraries and best practices. Then there could be a standard way to integrate all these great libraries.

Would anyone else find something like this useful or interesting?

[nhagen]

I think the benefits you're describing--quick startup, sane defaults, etc.--are well covered by using projects like react-redux-starter-kit. `reduxframework init` is less verbose than `git clone https://github.com/davezuko/react-redux-starter-kit.git project && cd project && rm -rf .git && git init` but I'm not sure a framework project would provide enough benefit to justify the additional abstractions. Redux is so simple I don't think that generators are even going to add a benefit. What are examples of things which the starter packs are not sufficient for?

[davidjnelson]

React-redux-starter-kit looks pretty sweet. But compare it's documentation to angular's. I guess the biggest hurdle is comprehensive documentation of how all the pieces fit together, and best practices for the most common use cases.