4 ms·
The way we tried to open source our front-end stack at Facebook is to release a collection of standalone libraries. This strategy worked very well to integrate
by vjeux 12y ago
The way we tried to open source our front-end stack at Facebook is to release a collection of standalone libraries. This strategy worked very well to integrate with existing codebases but we're missing a very large audience: people starting new projects. It's not trivial at all to glue all those projects together. So while it's tempting to reject "framework"-type projects, that's actually what a lot of people want and our most common request.
- React: http://facebook.github.io/react/ http://facebook.github.io/react/
- Flux: http://facebook.github.io/flux/ http://facebook.github.io/flux/
- Jest: http://facebook.github.io/jest/ http://facebook.github.io/jest/
- Immutable-js: http://facebook.github.io/immutable-js/ http://facebook.github.io/immutable-js/
- Flow: http://flowtype.org/ http://flowtype.org/
- JSX: http://facebook.github.io/jsx/ http://facebook.github.io/jsx/
- illumen 12y agoFramework groups are larger as a group than the many small groups that use collections of libraries. However if you add up all the smaller groups using smaller collections, maybe they are just as big or larger?
- MrBuddyCasino 12y agoThis looks like a good opportunity to point people at Mercury: https://github.com/Raynos/mercury https://github.com/Raynos/mercury It is similar to Mithril, but with a strong focus on modularity. To quote the website: "mercury is a small glue layer that composes a set of modules that solves a subset of the frontend problem." You can basically swap out things that you don't like, use it with Backbone or JSX etc. Its weak point currently is documentation, which is of course a biggie.
- vkjv 12y agoI don't think a "framework" is necessary here, though. An example boilerplate project that glues all (most?) of the libraries together is all that is needed.