diff --git a/source/standards/programming-languages.html.md.erb b/source/standards/programming-languages.html.md.erb index 7e4e3c34..711f5268 100644 --- a/source/standards/programming-languages.html.md.erb +++ b/source/standards/programming-languages.html.md.erb @@ -26,7 +26,6 @@ This should make it easier for developers to: The Service Manual has information on [using client-side JavaScript][manual_js]. For server-side JavaScript we use [Node.js][nodejs]. - [nodejs]: https://nodejs.org/ [manual_js]: https://www.gov.uk/service-manual/technology/using-progressive-enhancement @@ -45,11 +44,11 @@ You can use Node.js to render a web interface for your service. For example, GOV.UK Pay has created thin, client-facing applications that do not store data (although they may retrieve data from an API). -You can use [TypeScript](https://www.typescriptlang.org/) when teams think it's +You can use [TypeScript](https://www.typescriptlang.org/) when teams think it’s appropriate. For example, the GOV.UK PaaS team uses TypeScript because they are used to working with a statically typed, compiled language, and they think the compilation and static-analysis tooling is better for -their workflow. There's more information about TypeScript on the +their workflow. Ther’s more information about TypeScript on the [Node.js page](/manuals/programming-languages/nodejs/). ## Backend development @@ -59,18 +58,16 @@ Our core languages for backend development are: - [Java](/manuals/programming-languages/java.html) - [Python](/manuals/programming-languages/python/python.html) - [Ruby](/manuals/programming-languages/ruby.html) +- [JavaScript / Node.js](/manuals/programming-languages/nodejs/index.html) -We've chosen these languages because they are successfully used by +We’ve chosen these languages because they are successfully used by teams at the moment, and we are confident in how to host and operate applications written in them. You should carry out new development in one of these languages. -We are also currently exploring the use of Node.js in the backend for -serverless systems, particularly in the Digital Identity programme. - ### Python -You should write new Python projects in Python 3. +You should write new Python projects in Python 3. [Python 2 reached end of life in 2020][PEP373]. Python 3 is now well-supported by application frameworks and libraries, and is commonly used in production. @@ -98,23 +95,41 @@ source tool available. ### Languages we do not use for new projects We used Scala in the early days of GDS. GOV.UK Licensing is the only remaining -application written in Scala but we've found it hard to support because of a lack +application written in Scala but we’ve found it hard to support because of a lack of skills in GDS. Do not use Scala for new projects. +## Mobile Development + +For developing mobile apps, we use Swift for iOS and Kotlin for Android. + +These languages have been chosen over using frameworks such as Flutter or .NET MAUI so that the apps +feel like a native Android/iOS app without writing extra code to account for the specific OS in Flutter, for example. + +### Swift + +The Swift version is generally tied to the version of Xcode you're using. As long as the Xcode version supports the minimum targeted iOS version +of your team's app, you can use the most recent version if desired. + +// TODO: Do we need to mention minimum iOS targets for DI / GOV.UK? + +### Kotlin + +// TODO: Fill in specific Kotlin/Android Studio versions/ OS targets? + ## Using other languages There will be sensible reasons to not follow the above guidance on languages. -For example when you're: +For example when you’re: - extending an existing codebase or ecosystem - scripting in a particular environment -- experimenting during an alpha (with an expectation that it's replaced by something we have more confidence in for beta) +- experimenting during an alpha (with an expectation that it’s replaced by something we have more confidence in for beta) - working in a very specific or unusual problem domain, like heavy use of WebSockets -The set of languages we're comfortable supporting will change over time. +The set of languages we’re comfortable supporting will change over time. If you want to use a new language, talk to your Head of Technology and then create a prototype. If it goes well you can [open a pull request](/standards/pull-requests.html) to change this document. -If you're having problems using one of the languages we support, open a pull request to +If you’re having problems using one of the languages we support, open a pull request to document the issues.