Frontend Engineering Best Practices at TenX

Published in

Official TenX Blog

7 min readApr 30, 2019

Recently we wrote about our experience migrating our native iOS and Android apps to React Native. Since successfully launching the TenX app, we’ve been pursuing an initiative to standardize the frontend engineering practices company-wide to establish consistency and uphold quality across our different frontend codebases. This is our take on the best practices for frontend engineering:

1. Set main outcomes for your team ✅

Here are some of the main outcomes we wanted to achieve at TenX Frontend Engineering:

Provide a clear template, structure, and configuration for future projects to share common tooling, libraries, and organization.
Improve developer experience and reduce the cost of context switching between different codebases.
Provide best practices guidelines to maintain code quality standards.
Provide helpful reference documentation for on-boarding future engineers.
Improve the ability to share code between different codebases (HOCs, UI components, helper methods, mock test data, etc.)

2. Identify your data sources and trends 📈

Recent hiring trends (source: https://www.hntrends.com/)

In the last several years there has been rapid change in the world of frontend software development. New technologies, libraries, frameworks, and design patterns emerge every few months and the landscaping is changing so quickly it’s hard to know if the library or tool your team is adopting will be quickly outdated by something new a few months later.

However, we think this dynamic change has started to stabilise into more dependable trends. We tried to base our review of frontend standards on an analysis of these trends. Specifically, we looked at these three data sources:

State of JavaScript Survey: A thorough analysis of trends in the JavaScript ecosystem, which included over 20,000 developers in the 2018 survey.
Stack Overflow’s Developer Survey: The “largest and most comprehensive survey of people who code around the world” which included nearly 90,000 participants last year.
Hacker News Hiring Trends: A monthly analysis of hiring trends by technology based on job postings on the Hacker News whoishiring thread.

We used the trends identified in these datasets and the experience and observations of our engineers to inform our decision making process for frontend technologies and standards. Here, we’ll provide an overview of the technologies, tooling, testing, and best practices we decided were important enough to codify into actual guidelines for our teams to follow.

3. Pick scalable technologies for the long haul ⚒️

React

TenX is fully invested in React and it’s ecosystem, with several applications relying on React running now in production. React has overtaken every other technology on the hiring trends from Hacker News in recent years, and the trend remains strong. Furthermore, it’s the most widely used frontend framework according to the State of JS survey and the “most loved” web framework according to the Stack Overflow survey results. React Native exhibits a similar trend in the mobile application space. We expect that React will continue to grow and be a leading innovator in UI development in the coming years.

TypeScript

There are many benefits to using a statically typed programming language and typed alternatives to JavaScript are becoming more and more prominent in the realm of frontend and NodeJS development. We’ve chosen TypeScript as the best option for us for it’s combination of ease of use, tooling, build system, community support, and widespread adoption. TypeScript is the third “most loved” language according to the Stack Overflow survey results, the most widely used “flavour” of JavaScript according to the State of JS survey, and quickly rising to surpass JavaScript based on hiring trends data.

GraphQL

GraphQL is one of the most disruptive technologies in software development in recent years, and poses to potentially replace so-called “traditional REST APIs” entirely. We have very successfully adopted GraphQL in all of our client facing applications and observed many benefits, including:

Typed GraphQL APIs provide high code confidence, reduce runtime errors, and improve type coverage in client codebases.
Client side state management and network request logic can be encapsulated by a GraphQL client library like Apollo, dramatically improving developer productivity and resulting in smaller, more manageable codebases.

GraphQL received the “Highest Interest” award by the State of JS survey: nearly 90% of developers who have heard of GraphQL want to learn it, and it has risen quickly out of nowhere in hiring trends data, now appearing in over 5% of posts.

CSS-in-JS

While it’s a little hard to find data supporting this trend, the evolution toward “CSS-in-JS” seems to be a sustained movement in frontend UI development. In general, the primary benefit is the co-location of styles with the UI they describe (rather than in separate CSS files). Overall, we prefer this approach using popular libraries like styled-components or emotion over traditional approaches to implementing CSS in an application. Here is a good article giving some more background context.

4. Establish clear standards for developer experience & tooling 🔧

We wanted to establish clear standards for developer tooling which could enhance developer experience and productivity across our teams. With that in mind, here are some of the specific tools we adopted:

VS Code

Visual Studio Code has been gaining a lot of traction in recent years and integrates very well with TypeScript, making it a great choice for us. It received the “Special Award” by the State of JS survey for the “leading JavaScript text editor”. Using VS Code is not required, but its integrations with our tooling make it very convenient.

TSLint

Many languages have linting tools to perform static code analysis checks for readability, maintainability, and functionality errors. We chose to adopt TSLint here because it integrates very well with TypeScript. We use TSLint to apply a number of linting rules automatically to our frontend applications. Incidentally, we’re aware that TSLint will be deprecated and migrated toward ESLint, at which time we will follow that migration path and adopt ESLint as our linter of choice.

Prettier

Prettier is an “opinionated code formatter” for JavaScript which has become popular in recent years. We use prettier to enforce consistent code formatting which improves code readability, developer experience, and developer productivity. Developers can simply write code, hit save and watch it instantly become formatted and readable.

5. Pick the right tools for testing and automation ⚙️

DangerJS recommending an author add tests for a new util function

It’s important to standardize and automate as much of the software development process as possible. This means adopting modern CI/CD best practices, but there are also several additional tools we’ve found specifically useful for JavaScript codebases:

Jest: Jest is a fantastic test runner for JavaScript code which integrates well with TypeScript. We use it to write all our unit tests, and have even built an end-to-end testing framework which relies on Jest. It is the most used testing framework according to the State of JS survey.
DangerJS: DangerJS is a relatively new tool which allows you to automate certain code review chores in CI. We use this to recommend authors to add tests or perform other tasks, rather than relying on manual code review for this purpose.
Husky: Husky is a tool for easily adding git hooks to a project, to automate certain tasks after git push or git commit. This can be used to run linting tasks or tests, for instance, so developers don’t have to remember to do this manually.

This is our take on the current world of frontend engineering at TenX and how we are trying to establish best practices to build maintainable, scalable applications. We’re sure other teams will find different tools, libraries, and approaches which are a better fit for their own needs, and this is all perfectly valid as well.

Open sourcing our UI regression testing tool 🔭

Moving forward from here, we are also planning to officially announce open sourcing the UI regression testing tool we mentioned in our previous article on migrating to React Native. This tool allows our teams to automatically generate screenshots of all the app screens in our React Native app which we use for quick reference and for UI regression testing.

We’ve found this tool very useful in the development of our app, and we hope open sourcing it will allow others to benefit as well. In addition, its design embodies all of the best practices we described here. Keep an eye out for an official announcement very soon!