Update frameworks.md to suggest using React #201
Conversation
| @@ -5,6 +5,14 @@ layout: docs | |||
| sidenav: js | |||
| --- | |||
| # Frameworks | |||
|
|
|||
| **We recommend using [React]() for projects when possible.** As a team, we enjoy using React because it has a strong component model, enables easy server side rendering, and faciliates debugging by making the UI elements a function of the application state. React is most akin to the "view layer" in an MVC (Model-View-Controller) architecture and is frequently used with some other libraries. In our projects, we tend to use: | |||
There was a problem hiding this comment.
I'd feel more comfortable if rather than recommending one privately-owned framework, we instead suggest react-like frameworks, encompassing Preact and others built on the same-ish APIs.
I also think whole-heartedly endorsing redux may be overkill, and possilby bad advice. I think the current advice is usually "Use redux if you need to, and not if you don't"
There was a problem hiding this comment.
One of the purposes of the guide is to document and suggest what tools we are currently using at 18F, and I think React falls within the scope of that. If there are other projects we can point to that actively support Preact then I feel we should add that in, but if we aren't using it then I don't think we should be supporting it as guidance.
There was a problem hiding this comment.
I see what you're saying, and it makes sense, but perhaps We recommend using React for projects when possible. is just a bit too strong.
While I like React quite a bit, and think it's perfectly fine, I have two issues with it as a recommendation:
- Given Facebook's ethical and privacy issues and questionable trademark history, I'd be hesitant to hitch my wagon so directly to them.
- Due the well-documented APIs, there are a whole host of React-like alternatives, many of which are drop-in replacements with much smaller footprints. Preact is only one of many, and I just mentioned it because it's among the best known (although some others are catching up quick) More info: https://hackernoon.com/the-react-is-dead-long-live-the-react-e97eea715f1c
My suggestion would be something along the lines of We recommend a React-compatible framework. We use React, but Preact, Inferno and others may be viable alternatives for your needs.
There was a problem hiding this comment.
I agree with @xtine, @tbaxter-18f. This is a recommendation and not an enforcement. We only recommend xyz lib because that's what a majority of our projects are built with. We aren't using those other libraries here, but this is just guidance. It's not trying to enforce anything.
|
|
||
| **We recommend using [React]() for projects when possible.** As a team, we enjoy using React because it has a strong component model, enables easy server side rendering, and faciliates debugging by making the UI elements a function of the application state. React is most akin to the "view layer" in an MVC (Model-View-Controller) architecture and is frequently used with some other libraries. In our projects, we tend to use: | ||
|
|
||
| * [Redux](https://www.npmjs.com/package/redux) for managing state |
There was a problem hiding this comment.
Can I suggest adding "optional" as simpler webapps may not need to rely on Redux?
| @@ -5,6 +5,14 @@ layout: docs | |||
| sidenav: js | |||
| --- | |||
| # Frameworks | |||
|
|
|||
| **We recommend using [React]() for projects when possible.** As a team, we enjoy using React because it has a strong component model, enables easy server side rendering, and faciliates debugging by making the UI elements a function of the application state. React is most akin to the "view layer" in an MVC (Model-View-Controller) architecture and is frequently used with some other libraries. In our projects, we tend to use: | |||
There was a problem hiding this comment.
| **We recommend using [React]() for projects when possible.** As a team, we enjoy using React because it has a strong component model, enables easy server side rendering, and faciliates debugging by making the UI elements a function of the application state. React is most akin to the "view layer" in an MVC (Model-View-Controller) architecture and is frequently used with some other libraries. In our projects, we tend to use: | |
| **We recommend using [React](https://reactjs.org/) for projects when possible.** As a team, we enjoy using React because it has a strong component model, enables easy server side rendering, and faciliates debugging by making the UI elements a function of the application state. React is most akin to the "view layer" in an MVC (Model-View-Controller) architecture and is frequently used with some other libraries. In our projects, we tend to use: |
| **We recommend using [React]() for projects when possible.** As a team, we enjoy using React because it has a strong component model, enables easy server side rendering, and faciliates debugging by making the UI elements a function of the application state. React is most akin to the "view layer" in an MVC (Model-View-Controller) architecture and is frequently used with some other libraries. In our projects, we tend to use: | ||
|
|
||
| * [Redux](https://www.npmjs.com/package/redux) for managing state | ||
| * [Webpack](https://www.npmjs.com/package/webpack) and [Babel](https://babeljs.io/) for compiling our Javascript |
There was a problem hiding this comment.
Does react-router belong on this list, in a similarly "optional" bullet as Redux? Do we have a different routing library we like to use? Do we tend to roll our own (please no)?
There was a problem hiding this comment.
Also curious if we want to recommend something like create-react-app to help bootstrap a new React project. Goodness knows setting up Webpack by hand is no fun. 😄
We use React (and it seems like we really enjoy doing so!) so let's make our framework guidance reflect that.