Principles for Scaling Frontend Application Development

Spanish audio is available in the player settings
Rate this content
Bookmark

After spending over a decade at Google, and now as the CTO of Vercel, Malte Ubl is no stranger to being responsible for a team’s software infrastructure. However, being in charge of defining how people write software, and in turn, building the infrastructure that they’re using to write said software, presents significant challenges. This presentation by Malte Ubl will uncover the guiding principles to leading a large software infrastructure.

Malte Ubl
Malte Ubl
26 min
02 Jun, 2023

Comments

Sign in or register to post your comment.

Video Summary and Transcription

This Talk discusses scaling front-end applications through principles such as tearing down barriers, sharing code in a monorepo, and making it easy to delete code. It also emphasizes incremental migration, embracing lack of knowledge, and eliminating systematic complexity. The Talk highlights the use of automation in code migration and the importance of removing barriers to enable smoother code migration.

Available in Español

1. Introduction and Background

Short description:

How's everyone doing? This is actually my first conference, back from a break. I used to build large JavaScript applications, now it's TypeScript. React has evolved and is now available to everyone. I joined Brazil and found an internal Dex team. We turned it into a product team to solve common problems. We announced Versell Spaces to implement the discussed concepts.

How's everyone doing? Yeah, thanks for talking about JSConf and stuff. We made the wise decision not to have a 2010 event because it wouldn't have happened anyway, this is actually my first conference, at least if you're counting community conferences, back from this bigger break in everyone's life. I'm coming from San Francisco. I was actually in Germany before, still a little bit jet-lagged but I'm trying to bring up the vibes here a little bit.

So in this sense of reminiscing a little bit, five years ago at JSConf Australia, I gave a talk and I started with this sentence, Hello, I used to build very large JavaScript applications. I was still at Google at the time and I was stepping into kind of an executive role. So I wasn't really actually building stuff myself, but I learned some stuff and so I thought it would be a good idea to give a talk about it. But that was then. I'm back. I'm actually back to building things in JavaScript, very large applications. Obviously, nobody today actually does that anymore. It's TypeScript applications and here we are.

Another slide from that talk was that I thought React was good. And the context there was that back in the day, 10 years ago, I built a JavaScript framework at Google called Wiz and I was thinking about whether to open source it and so just around that time, React comes out and it looks really good and I think the world does not need this. I'm going to keep this to ourselves. I think now that it was a bit of a mistake because there were some good contributions around scalability of applications that could have been actually valuable to the ecosystem even if just kind of shown around. But now I'm at Brazil, I can kind of help a little bit push React along and I think with the stuff around server components, et cetera, some of this situation that we thought about at Google back in the day, has come around and is now available to everyone, which is amazing. Cool. All right.

So I joined Brazil, I talked to all the teams and I find that we have an internal Dex team. And so I talked to them, you know, what are you guys doing? They explained to me what they're doing. I think that seems like a really good idea. And then I go talk to customers. our customers are like telling me that their problems are the problems that our internal Dx team is solving. And so I was like, why don't we turn this into a product team and actually make this available to everyone so that not everyone has to go over and over again, solve the same problems. Now, this is in a way relevant because the talk I gave back in the day, it was so like such theory heavy stuff, because, you know, I didn't have anything open source. I could only tell folks, like, this is what I learned. But you have to figure out how to like take this learning into something real by yourself. Now, I'm going to be doing similar stuff today and more power to you if you want to build yourself. You know, we did announce a product called Versell Spaces a few weeks ago that's trying to implement some of the stuff that I'm going to talk about in like a reusable fashion.

2. Scaling Front-end Applications

Short description:

So let's go ship software like Google or Vercel because it's 2023. But I think this one is actually true, iteration velocity solves all known problems. What I mean is that when we make software, we are going to make mistakes over time, and we have to deal with that fact professionally. The rest of this talk is about how you can scale beyond yourselves, but through software that you've built, and through mechanisms that you establish in your teams that make the whole team better. I want to talk about principles for scaling front-end applications. I got six. Let's start with this one: tearing down the barriers.

All right. So let's go ship software like Google or Vercel because it's 2023. But kind of going to Google, there was this like guy called Eric Schmidt, he was the CEO for a long time and he, at least internally, maybe I'm leaking something, sorry, always used to say revenue solves all known problems. Basically saying, if you just make more money, it really doesn't matter what else you're doing. And I think that's wrong.

Like certainly, we don't, you know, have infinite money, you don't have infinite money. I think Google no longer has infinite money. So that's not really, it's not such a good mantra. But I think this one is actually true, iteration velocity solves all known problems. What I mean is that when we make software, and it was actually the first talk today had a similar point, we are going to make mistakes over time, right? That's the only thing that we know is that the future is uncertain and we have to deal with that fact professionally. And the way how you do that professionally is by being able, at the moment when you make that mistake to react to it and iterate and do it right the second time around. So with that, let's think a little bit about our role in this, and for the rest of this talk.

So the senior engineer, or really what I mean is like the lower case senior engineer, right? We've been around for a little bit. What do we do, right? You might have, there's a session later today around career advice, and they might tell you something like, you know, if you want to have more impact, you need to scale beyond yourself, and what people kind of usually associate with this is something along the lines of kind of either having management responsibility or at least telling other folks what to do. It's a people thing, right? And so the rest of this talk is kind of about something very different from that. It's about how you can scale beyond yourselves, but through software that you've built, and through mechanisms that you establish in your teams that make the whole team better, but through the software that you're building. And so for the rest of these slides, basically, consider yourselves as like the hypothetical lead of the hypothetical platform team for your hypothetical, I don't know, 12, 50, 100 person engineering team, right? You're that person and your job is to make that team scale better. Cool. That was a long intro. Anyway, I want to talk about principles for scaling front-end applications. I got six. I have a bonus one, but I think I'm too slow. So I'll do six. All right. Let's start with this one. Tearing down the barriers. So this is actually something that is—was not clear to me how big of an effect it would have. As I was mentioning, I was like at Google for the longest time. I was not like using the tools everyone else was using but I was doing this conference, JSConf. I was going to these meetups myself and I would hear folks on stage being incredibly excited about small modules, right? And there was a company called NPM, Shouter NPM, who created something called private modules.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

Don't Solve Problems, Eliminate Them
React Advanced Conference 2021React Advanced Conference 2021
39 min
Don't Solve Problems, Eliminate Them
Top Content
Humans are natural problem solvers and we're good enough at it that we've survived over the centuries and become the dominant species of the planet. Because we're so good at it, we sometimes become problem seekers too–looking for problems we can solve. Those who most successfully accomplish their goals are the problem eliminators. Let's talk about the distinction between solving and eliminating problems with examples from inside and outside the coding world.
Using useEffect Effectively
React Advanced Conference 2022React Advanced Conference 2022
30 min
Using useEffect Effectively
Top Content
Can useEffect affect your codebase negatively? From fetching data to fighting with imperative APIs, side effects are one of the biggest sources of frustration in web app development. And let’s be honest, putting everything in useEffect hooks doesn’t help much. In this talk, we'll demystify the useEffect hook and get a better understanding of when (and when not) to use it, as well as discover how declarative effects can make effect management more maintainable in even the most complex React apps.
Design Systems: Walking the Line Between Flexibility and Consistency
React Advanced Conference 2021React Advanced Conference 2021
47 min
Design Systems: Walking the Line Between Flexibility and Consistency
Top Content
Design systems aim to bring consistency to a brand's design and make the UI development productive. Component libraries with well-thought API can make this a breeze. But, sometimes an API choice can accidentally overstep and slow the team down! There's a balance there... somewhere. Let's explore some of the problems and possible creative solutions.
React Concurrency, Explained
React Summit 2023React Summit 2023
23 min
React Concurrency, Explained
Top Content
React 18! Concurrent features! You might’ve already tried the new APIs like useTransition, or you might’ve just heard of them. But do you know how React 18 achieves the performance wins it brings with itself? In this talk, let’s peek under the hood of React 18’s performance features: - How React 18 lowers the time your page stays frozen (aka TBT) - What exactly happens in the main thread when you run useTransition() - What’s the catch with the improvements (there’s no free cake!), and why Vue.js and Preact straight refused to ship anything similar
TypeScript and React: Secrets of a Happy Marriage
React Advanced Conference 2022React Advanced Conference 2022
21 min
TypeScript and React: Secrets of a Happy Marriage
Top Content
TypeScript and React are inseparable. What's the secret to their successful union? Quite a lot of surprisingly strange code. Learn why useRef always feels weird, how to wrangle generics in custom hooks, and how union types can transform your components.
A Framework for Managing Technical Debt
TechLead Conference 2023TechLead Conference 2023
35 min
A Framework for Managing Technical Debt
Top Content
Let’s face it: technical debt is inevitable and rewriting your code every 6 months is not an option. Refactoring is a complex topic that doesn't have a one-size-fits-all solution. Frontend applications are particularly sensitive because of frequent requirements and user flows changes. New abstractions, updated patterns and cleaning up those old functions - it all sounds great on paper, but it often fails in practice: todos accumulate, tickets end up rotting in the backlog and legacy code crops up in every corner of your codebase. So a process of continuous refactoring is the only weapon you have against tech debt.In the past three years, I’ve been exploring different strategies and processes for refactoring code. In this talk I will describe the key components of a framework for tackling refactoring and I will share some of the learnings accumulated along the way. Hopefully, this will help you in your quest of improving the code quality of your codebases.

Workshops on related topic

React Performance Debugging Masterclass
React Summit 2023React Summit 2023
170 min
React Performance Debugging Masterclass
Top Content
Featured WorkshopFree
Ivan Akulov
Ivan Akulov
Ivan’s first attempts at performance debugging were chaotic. He would see a slow interaction, try a random optimization, see that it didn't help, and keep trying other optimizations until he found the right one (or gave up).
Back then, Ivan didn’t know how to use performance devtools well. He would do a recording in Chrome DevTools or React Profiler, poke around it, try clicking random things, and then close it in frustration a few minutes later. Now, Ivan knows exactly where and what to look for. And in this workshop, Ivan will teach you that too.
Here’s how this is going to work. We’ll take a slow app → debug it (using tools like Chrome DevTools, React Profiler, and why-did-you-render) → pinpoint the bottleneck → and then repeat, several times more. We won’t talk about the solutions (in 90% of the cases, it’s just the ol’ regular useMemo() or memo()). But we’ll talk about everything that comes before – and learn how to analyze any React performance problem, step by step.
(Note: This workshop is best suited for engineers who are already familiar with how useMemo() and memo() work – but want to get better at using the performance tools around React. Also, we’ll be covering interaction performance, not load speed, so you won’t hear a word about Lighthouse 🤐)
React Hooks Tips Only the Pros Know
React Summit Remote Edition 2021React Summit Remote Edition 2021
177 min
React Hooks Tips Only the Pros Know
Top Content
Featured Workshop
Maurice de Beijer
Maurice de Beijer
The addition of the hooks API to React was quite a major change. Before hooks most components had to be class based. Now, with hooks, these are often much simpler functional components. Hooks can be really simple to use. Almost deceptively simple. Because there are still plenty of ways you can mess up with hooks. And it often turns out there are many ways where you can improve your components a better understanding of how each React hook can be used.You will learn all about the pros and cons of the various hooks. You will learn when to use useState() versus useReducer(). We will look at using useContext() efficiently. You will see when to use useLayoutEffect() and when useEffect() is better.
React, TypeScript, and TDD
React Advanced Conference 2021React Advanced Conference 2021
174 min
React, TypeScript, and TDD
Top Content
Featured WorkshopFree
Paul Everitt
Paul Everitt
ReactJS is wildly popular and thus wildly supported. TypeScript is increasingly popular, and thus increasingly supported.

The two together? Not as much. Given that they both change quickly, it's hard to find accurate learning materials.

React+TypeScript, with JetBrains IDEs? That three-part combination is the topic of this series. We'll show a little about a lot. Meaning, the key steps to getting productive, in the IDE, for React projects using TypeScript. Along the way we'll show test-driven development and emphasize tips-and-tricks in the IDE.
Designing Effective Tests With React Testing Library
React Summit 2023React Summit 2023
151 min
Designing Effective Tests With React Testing Library
Top Content
Featured Workshop
Josh Justice
Josh Justice
React Testing Library is a great framework for React component tests because there are a lot of questions it answers for you, so you don’t need to worry about those questions. But that doesn’t mean testing is easy. There are still a lot of questions you have to figure out for yourself: How many component tests should you write vs end-to-end tests or lower-level unit tests? How can you test a certain line of code that is tricky to test? And what in the world are you supposed to do about that persistent act() warning?
In this three-hour workshop we’ll introduce React Testing Library along with a mental model for how to think about designing your component tests. This mental model will help you see how to test each bit of logic, whether or not to mock dependencies, and will help improve the design of your components. You’ll walk away with the tools, techniques, and principles you need to implement low-cost, high-value component tests.
Table of contents- The different kinds of React application tests, and where component tests fit in- A mental model for thinking about the inputs and outputs of the components you test- Options for selecting DOM elements to verify and interact with them- The value of mocks and why they shouldn’t be avoided- The challenges with asynchrony in RTL tests and how to handle them
Prerequisites- Familiarity with building applications with React- Basic experience writing automated tests with Jest or another unit testing framework- You do not need any experience with React Testing Library- Machine setup: Node LTS, Yarn
React at Scale with Nx
React Summit 2023React Summit 2023
145 min
React at Scale with Nx
Top Content
Featured WorkshopFree
Isaac Mann
Isaac Mann
We're going to be using Nx and some its plugins to accelerate the development of this app.
Some of the things you'll learn:- Generating a pristine Nx workspace- Generating frontend React apps and backend APIs inside your workspace, with pre-configured proxies- Creating shared libs for re-using code- Generating new routed components with all the routes pre-configured by Nx and ready to go- How to organize code in a monorepo- Easily move libs around your folder structure- Creating Storybook stories and e2e Cypress tests for your components
Table of contents: - Lab 1 - Generate an empty workspace- Lab 2 - Generate a React app- Lab 3 - Executors- Lab 3.1 - Migrations- Lab 4 - Generate a component lib- Lab 5 - Generate a utility lib- Lab 6 - Generate a route lib- Lab 7 - Add an Express API- Lab 8 - Displaying a full game in the routed game-detail component- Lab 9 - Generate a type lib that the API and frontend can share- Lab 10 - Generate Storybook stories for the shared ui component- Lab 11 - E2E test the shared component
Next.js 13: Data Fetching Strategies
React Day Berlin 2022React Day Berlin 2022
53 min
Next.js 13: Data Fetching Strategies
Top Content
WorkshopFree
Alice De Mauro
Alice De Mauro
- Introduction- Prerequisites for the workshop- Fetching strategies: fundamentals- Fetching strategies – hands-on: fetch API, cache (static VS dynamic), revalidate, suspense (parallel data fetching)- Test your build and serve it on Vercel- Future: Server components VS Client components- Workshop easter egg (unrelated to the topic, calling out accessibility)- Wrapping up