diff --git a/content/engineering/languages-runtimes/language-selection.md b/content/engineering/languages-runtimes/language-selection.md index a7386a44..63a4a840 100644 --- a/content/engineering/languages-runtimes/language-selection.md +++ b/content/engineering/languages-runtimes/language-selection.md @@ -37,11 +37,28 @@ Looking at this same data and applying preferences from the guiding factors belo ## Frequently-used frameworks The following are used widely at 18F: -| Purpose | Tool | -| ---- | ---- | -| CSS framework | [_More info_]({{ "/engineering/languages-runtimes/css/#frameworks" | url }}) | -| Infrastructure/configuration as code | [Terraform](https://www.terraform.io/) | -| Static site generator | [Jekyll](https://jekyllrb.com/) (with the [uswds-jekyll](https://github.com/18F/uswds-jekyll) theme) or Hugo | + + + + + + + + + + + + + + + + + + + + + +
PurposeTool
CSS frameworkMore info
Infrastructure/configuration as codeTerraform
Static site generator{% include "engineering/tag-default.html" %} 11ty/Eleventy
## Project scope Perhaps the most important factor to weigh when considering languages is the estimated project scope. If we anticipate a large, long-standing project which will be handed off to our agency partners, we should be conservative in our language selection. These projects warrant our most standard approach, which generally translates to the selection of one of our primary languages. On the other hand, if writing a one-off script or small internal project, we have significantly more latitude to try experimental languages.