Rounak Jain
Engineering manager, iOS revenue
Tinder
400+ employees
Tara Feener
Senior director of engineering
Vimeo
600+ employees
Joscha Feth
Frontend infrastructure lead
Canva
800 employees
Barry Clark
Head of engineering, Trello
Atlassian
4,000+ employees
What frontend frameworks or technologies does your organization use?
We put a lot of thought into the details—UI, animations, interactions—so Tinder makes heavy use of UIKit, Core Animation, and Core Graphics. More than 80 percent of our codebase is Swift. Just like the broader iOS community, we’re fans of the language’s type safety, generics, protocols, enums, structs, and trailing closures, among other modern features. We use Core Data as our object graph and persistence layer because that’s how the app was first built and because we haven’t encountered any major issues with it. Our platform team wrote convenience wrappers around Core Data that make it easy to observe changes using closures, avoid read-write race conditions, and more.
— Rounak Jain, Tinder
We’re using ReactJS almost everywhere and are moving to TypeScript as quickly as we can. Vimeo has been around since 2004, so it’s been an interesting challenge to modernize the stack at scale over time. We’ve done this by migrating legacy pages (which map nicely to products, in many cases) to our app shell (which follows progressive web application best practices)—a process that’s seen an immediate return in terms of improved performance metrics. Vimeo has a really incredible frontend platform team who’s constantly assessing when to pull in new technology and tools, and integrating them into the development process in such a way that our product engineering teams can quickly take advantage of them.
— Tara Feener, Vimeo
All the usual suspects youʼd expect of a company of our age and size: TypeScript, React, MobX, CSS modules, RxJS, ESLint, Jest, WebdriverIO, Cucumber.js. Then, some more unconventional choices for a startup: Bazel, Closure Compiler, Protobuf. Most of these technologies and tools were carefully selected at the beginning of a massive product rewrite a few years back. One of the cornerstones of that selection was (and still is) that they can scale with Canva.
— Joscha Feth, Canva
When Trello was founded in 2012, the team selected Backbone.js, WebSockets, and CoffeeScript. This stack, along with Node.js and MongoDB on the backend, was then at bleeding-edge and a calculated risk—we bet on technologies we hoped we’d still be able to use two, or even five, years out. Fast-forward to 2020, and Trello (which became a part of Atlassian in 2017) continues to be comfortable pushing the latest and best technologies: React, TypeScript, and GraphQL.
— Barry Clark, Atlassian
What’s the relationship like between your company’s frontend developers and UX/design team?
iOS engineers and product designers work closely through the development life cycle, from early spec reviews, prototyping, polishing, to launch. The design team also has folks specializing in revenue-related product features, which has helped the engineering team build a collaborative relationship with them over time. In the past year, the engineering team has built motion blurs, complex emitter systems, advanced transitions, and more, working closely with the design team on polishing fine points like timing, sizing, and animation curves.
— Rounak Jain, Tinder
It’s a highly collaborative relationship: We have at least one designer on every product engineering squad, and it’s not uncommon to see design and engineering working through a problem side by side in the office. We’ve also invested a lot in design systems, including our in-house system (named Iris), which uses the React component library. Recently, we’ve been adopting component-driven development on our product teams. We’re using Storybook to help move the design and engineering feedback loop up earlier in the product-shaping process. We’re constantly working to improve our time to a deploy URL or sandbox environment, which gives us an easily shareable environment where design and engineering can interact with features and work through any needed states before deploying to production.
— Tara Feener, Vimeo
The designer who owns a feature’s UX/UI is usually on the same team as the engineer implementing it. We also have some designers who code, and a self-help system that can automatically generate self-contained, auto-expiring user-testing sandboxes. Engineers generally have access to Figma, so they can look at a design, colors, components, and measurements. Almost all building blocks in the pattern library have an equivalent in our frontend stack. We unified most of our metrics (e.g., the grid baseline, breakpoints, and text weights), colors (all named so we can change them without touching lots of code), fonts, paragraph styles, so that each componentʼs name and appearance in Figma matches the frontend implementation.
— Joscha Feth, Canva
At Trello—and this is also true across Atlassian—frontend developers and designers are part of nine to 12 person cross-functional teams, working together alongside product managers, engineering managers, and testers. We expect our frontend developers and designers to explore their own preferred way of collaborating. Developers often hack on smaller or more experimental features directly in code, collaborating with designers in code and in the browser. For bigger projects, designers will often mock up user interfaces using Figma, collaborating with product managers and developers to make sure we’re solving the user’s problem.
— Barry Clark, Atlassian
What key tools and tooling do your frontend developers use?
For managing external dependencies and internal modules, we use CocoaPods along with some custom Swift scripts. We use SwiftLint’s built-in rules along with custom regex rules to enforce our Swift coding conventions and best practices. We use SwiftGen to autogenerate typesafe code for our localized strings and images. We also have an internal tool that helps two people easily match with each other using QR codes, which is very useful during testing. (Fun fact: This was built as a hackathon project!) Along with unit testing, we also rely on snapshot tests to ensure our views render as expected, and have a very useful internal tool that lets us view all test failures with a keyboard shortcut.
— Rounak Jain, Tinder
We have a CLI utility to build and prerender React apps called Rendezvous, which uses optimization strategies described by the Google PRPL pattern. It also comes with support for internationalization, which is a must for us. It was heavily inspired by React Static, Next.js, Gatsby, and Create React App. Frontend engineers work across the entire stack to deliver new features to production, which sometimes involves writing a little PHP. To help here, we maintain and actively contribute to an open-source project called Psalm—a static analysis tool for finding errors in PHP that works incredibly well for large codebases and that’s a required pass for any Vimeo code making its way to production.
— Tara Feener, Vimeo
We are a massive user of Storybook. Storybooks contain components from our library as well as compositions of components. They’re automatically built, deployed, and linked to each pull request, allowing us to reference them when collaborating. Our storybooks also contain tools that show whether components (or component compositions) behave correctly in a right-to-left context, are localized properly, or can deal with dynamic data. Each pull request also produces and deploys a fully usable variant of Canva running in-memory. Because both storybooks and Canva variants are all automatically generated, persisted, and disposed of after a certain amount of time, there is virtually no overhead to collaborating asynchronously. Percy, an external service, tracks visual regressions in our components. We also use a library that generates a dependency graph of our frontend code. At the beginning of each CI run, we’re able to dynamically generate the steps necessary to test the changes in a pull request against the last successful baseline. That way we can, for example, reduce the number of test steps we have to run to the bare minimum.
— Joscha Feth, Canva
With more than 100 developers working on Trello, tooling and established patterns give our developers the freedom to build quickly. We use Prettier to keep our code formatting consistent, and ESLint for linting. We also disable any ESLint rules related to formatting (so we don’t step on Prettier’s toes), and maintain our own set of custom rules to help align our React, testing, folder, and package conventions. We stick to these widely adopted tools mainly because there’s such a huge community around them, and almost all new developers on the team have experience using them. We use Yarn workspaces to support a multi-package monorepo for our frontend, and we allow package conventions to evolve and deviate as important rules surface. By taking this approach, we’re aiming to avoid getting to a place where we say, “We’re not going to adopt this because applying it everywhere is too costly.”
— Barry Clark, Atlassian
How does your organization keep pace with the rapid evolution of frontend technologies?
Tinder tries to support the three most recent major iOS versions, so it’s hard to adopt the latest and greatest tech announced by Apple at WWDC—such as SwiftUI or Combine—given the lack of backwards compatibility. That said, we keep a close eye on these new technologies, and try to incorporate aspects of them into our codebase through custom-built solutions that are compatible with older versions of iOS. For example, we have a declarative way of building forms that mimics SwiftUI’s approach, as well as an asynchronous data processing library similar to Combine. Even with Swift adoption, we waited until version three, which gave the language some time to evolve and become more stable. Since then we’ve been relatively quick to adopt new Swift versions, motivated by all the cool new language features.
— Rounak Jain, Tinder
We have a culture of showing our work, and we’ll often share new ideas with the larger engineering team—including both user-facing product work and internal-facing tools and technology. The frontend platform team holds brainstorming sessions with the frontend engineering teams to learn about pain points and gauge interest in new tech. We make informed decisions based on data, paying special attention to the impact on teams and on production performance. The platform team also documents their research and decision-making process openly in GitHub.
— Tara Feener, Vimeo
We have an official proposal process, which is loosely modeled after FullStory’s great “prove-its” concept. Still, the majority of changes are introduced either through necessity or when engineers demonstrate in a pull request that a change can massively improve an important metric, such as performance or bundle size. Canva’s monorepo approach makes it somewhat harder to introduce changes unless all affected parties are on board. On the flip side, this means the maintainability of our codebase and lateral movement in the organization is stronger. It also means that once a change or new tool is accepted, thereʼs no awkward multiyear transition period—one sweeping change across the whole monorepo is all we need.
— Joscha Feth, Canva
Atlassian leverages perspectives and learnings from across all of the product and platform teams, including Confluence, Jira, Bitbucket, Opsgenie, and Statuspage. We have a frontend platform group that spans the company and provides a platform for us to learn about what’s working and what isn’t. We’ll often use prototypes to gain a better understanding of the benefits we might gain from adopting a new technology and test if the new technology sticks before making a decision. We’re also not afraid to make big bets on new technologies that will solve problems. At Trello, we recently completed a huge project: enabling our frontend developers to write code in React, TypeScript, and GraphQL.
— Barry Clark, Atlassian
How do you measure the effects and impact of frontend changes?
We have our own experimentation platform that helps us understand what impact our projects have on key business metrics. For performance tracking, we use a combination of Firebase and our own Analytics events.
— Rounak Jain, Tinder
Vimeo measures everything from feature impact to technology performance: It’s a huge part of our engineering culture. We’re actively putting tools in place to help measure against engineering KPIs that we’ve defined as well as to surface warnings to engineers as soon as possible during the development process to get out ahead of shipping regressions to production. Recently, we’ve been thinking about adding analytics to our design system to understand more about usage and performance on a per-component basis. We’re also investigating the Google Lighthouse CLI to measure performance. When we’re ready to go to production, it’s rare that anything goes out to 100 percent of users immediately. We have an internal tool for deploying A/B experiments (aptly named ABLincoln), so when we’re in the kickoff phase of any new feature we’re also discussing our strategy for deployment. We also use feature flags so that we’re constantly, incrementally shipping new work to a subset of our user base.
— Tara Feener, Vimeo
In terms of direct user impact, we have an extensive suite of tooling, a dedicated data team, and an observability team [to support] when we roll out a new feature. We will usually know quickly if something is massively successful—or not. In the rare cases where something slips past testing, we have an excellent customer support team to help users 24/7. In terms of performance, we have automations in place to prevent degradations. Sauce Labs runs integration tests in browsers that are not widely used by our team but are widely used by our users. (Safari, Iʼm looking at you!) We use visual regression testing to ensure that unintended changes don’t make it to the baseline in the first place. Our end-to-end tests, run against a local stack of Canva, guard every release as the last automated step. Lastly, we do use manual testing for things that are hard to test in an automated fashion. (Drag-and-drop interactions come to mind.) We are trying to automate these tests as they are currently preventing us from going from daily releases to continuous deployment.
— Joscha Feth, Canva
Individual teams at Trello define the metrics that determine whether a feature change is a success or not. We’re also tracking a number of broad metrics across the app, including apdex, error rates, and crash rates, and we frequently review trends. We’re currently developing end-to-end checks for the most important user flows in our app to ensure we’re accurately measuring Trello from a user’s perspective. We’re also working on anomaly detection for a broad range of business metrics, which will help alert us to regressions that testing didn’t catch.
— Barry Clark, Atlassian
What does the future of frontend development look like?
Given the popularity of React’s declarative style, SwiftUI seems like the future of iOS UI development—not only because it’s declarative in nature, but also because it focuses on rapid prototyping and development. I would love for Core Data, Apple’s persistence framework, to get a similar treatment, where it utilizes Swift value types with a focus on immutable models.
— Rounak Jain, Tinder
We’ll see design systems and accompanying tools continue to blur the line between engineering and design. I don’t think it’s no-code, exactly, but it’s definitely much less code. As a result, there’s going to be much more time spent focused on solving problems for users on the other side of the experiences and tools we create.
— Tara Feener, Vimeo
Frontend engineers have become much better at decoupling things. Increasingly we think in components and pattern libraries instead of intertwined functions and snippets. (Look at the transition from jQuery to React.) We’ve also started collaborating better with our designer friends. (See the likes of Storybook, Figma, and Percy.) We also have vastly improved tooling around performance (Lighthouse or Calibre, for instance), and are less likely to make it an afterthought. In the future, I hope frontend integration testing improves: Solving this problem would remove the last big source of pain.
— Joscha Feth, Canva
React continues to hit a high developer satisfaction rating and I expect it to continue to dominate over the next few years. I’m also keeping an eye on micro-frontends, for large engineering groups to break frontend monoliths into smaller, more manageable pieces; usage of no-code development platforms like Webflow and Shopify; native browser support for JavaScript modules (I’m hopeful that this will simplify frontend tooling like webpack and Parcel and allow for better sharing and caching modules across products and sites); and Jamstack for high-speed static sites, coupled with function as a service (like AWS Lambda) and third-party services for functionality (like search and authentication). It’s an exciting time to be a frontend developer!
— Barry Clark, Atlassian