Principles for Scaling Frontend Application Developments

Today I decided to note and review the principles that was discussed by Malte UBL from Vercel

Scaling web apps is harder than it seems, both technically and in terms of team growth and iteration.

Technical aspect of making the application performant when reaching millions of users is challenging.

He thinks a lot about scaling and just did a talk on scaling frontend app development on react summit:

Here are six essential principles for scaling applications:

1. Tear down the barriers
2. Make it easier to delete code
3. Migrate incrementally
4. Always get better, never get worse
5. Embrace lack of knowledge
6. Eliminate systematic complexity

Now lets deep into each principle:

Principle 1: Tear down the barriers

The first principle discussed in the video is to tear down the barriers that can slow down development. This includes things like silos between teams, slow build times, and manual processes that can be automated. By removing these barriers, teams can work more efficiently and focus on delivering value to users.

Good example : go migrate to a mono repo that could save a lot of times and removes some barriers

Principle 2: Make it easier to delete code

The second principle is all about making it easy to delete code. This means creating a style system where teams can keep their codebase clean and maintainable.

Good example 1: if you use css-in-js or tailwind, because you have co-location of the css with the code you can easily remove the component with high confidence.
Good example 2: data fetching inside of components in NextJs 13

Principle 3: Migrate incrementally

The third principle is to migrate incrementally. This means moving from old APIs to new capabilities in a gradual way, By taking an incremental approach, teams can avoid breaking changes and minimize risk.

Indeed he believes there are only 2 types of migrations:

• incremental migrations
• failed migrations

Good example 1: Next.js 13 app router
Good example 2: trpc

Principle 4: Always get better, never get worse

The fourth principle is all about continuous improvement. Teams should always be looking for ways to improve their codebase and processes, rather than letting things stagnate. This includes introducing new rules for new code rather than migrating old code, seeking approval for code changes.
It also reminds me the uncle Bob sentence about having clean code: “Always leave the campground cleaner than you found it”

Good example: introducing lint rules gradually

Principle 5: Embrace lack of knowledge

The fifth principle is to embrace a lack of knowledge. This means being comfortable with not knowing everything and seeking out answers when needed. It also means being willing to ask questions and challenge assumptions in order to improve outcomes.

Some Good examples:

• To reduce any fear of embarrassment, the team establishes an anonymous question submission system
• Encouraging employees to ask dumb questions helps create a culture of openness and comfort by doing it yourself
• Mentorship and Guidance

Principle 6: Eliminate systematic complexity

The final principle is to eliminate systematic complexity. This includes things like versioning APIs and introducing new fields, which can add unnecessary complexity. The speaker proposes using serverless deployment to eliminate this complexity altogether. By simplifying the system, teams can focus on delivering value to users rather than managing complexity.

Good example: versions Skew

original talk: https://youtu.be/tqhLK0Fb5_4?si=Ql-dj-x5w443dEK9

let me know in the comments what's your opinion about these principles and if you have and good examples of each one

All the best
HASH