-
Notifications
You must be signed in to change notification settings - Fork 36
[WIP][Experiment] Make the guide as a tool for decision-making, rather than a set of opinions #213
base: master
Are you sure you want to change the base?
Changes from 3 commits
959b87a
a97947a
c619f55
e16afb5
2735116
90795d9
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -4,6 +4,14 @@ permalink: /javascript/frameworks/ | |
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: | ||
|
||
* [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 | ||
|
||
However, we are not dogmatic about React - we just vastly prefer it. Here are some other popular frameworks that have been used at 18F and some of their key characteristics. | ||
|
||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Brought this over from the ancient PR that never got merged, just to have something to work with. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I still think, especially given people's concerns about Facebook, that we should say "React or React-like" frameworks. I'd also feel comfortable being more dogmatic about it, and say "Use a react-like framework unless you have a compelling reason not to, such as the partner already using another framework". I just think the ramp-up time for developers diving into one person's fave framework from six months ago is much greater than any benefit from that framework in most cases. Unless we have a strong second choice, I'd be happy dropping the angular and Backbone sections, too. |
||
## Angular | ||
AngularJS (commonly referred to as "Angular") is an open-source web application framework maintained by Google and by a community of individual developers and corporations to address many of the challenges encountered in developing single-page applications ([Wikipedia](http://en.wikipedia.org/wiki/AngularJS)). | ||
|
||
|
@@ -61,7 +69,6 @@ Backbone.js is a JavaScript library with a RESTful JSON interface and is based o | |
- Since it has very little structure, inexperienced programmers can easily create unmaintainable code with Backbone. | ||
- Designed primarily for REST data. | ||
|
||
|
||
## React | ||
React (sometimes styled React.js or ReactJS) is an open-source JavaScript library for creating user interfaces that aims to address challenges encountered in developing single-page applications ([Wikipedia](https://en.wikipedia.org/wiki/React_(JavaScript_library))). | ||
|
||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm torn about deleting this. On one hand, we haven't had front end designers at 18F for nearly two years. On the other hand, it feels valuable to define what we expect from front end developers (and what we don't expect). Perhaps that definition process is one that we should go through again new, though?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should keep the bit about front-end developers.