[Hot] React Compiler is out. Zed - The fastest editor in town? What's MVP Tester?

Welcome to our 147th edition!

🔥 Top Stories

1. React Compiler is no longer a research project. There are tonnes of new features and changes added to the latest version of React.

2. Another code editor for development. Zed? Zed is created by the creators of Atom Editor. Hmm, that rings a bell. Will it replace VScode? Meh :|

3. [Self Promotion] I recently launched the initial version of MVPTester. A perfectly validation-focused application for quick idea validations. Give it a try and share your feedback.

🌟 Spotlight

Let’s talk about Micro-Frontends today.

Hmm, what are they?

Think of them like backend microservices but for the frontend.

Ok, I’m thinking. But what I’m thinking exactly? 🤔 

Alright, let’s start with a simple sketch.

This essentially means the Home page could be handled by the Home Team and the Products page can be handled by the Products Team or even there could be 100s of teams working just on the Home Page where each of them can be responsible for a single feature (eg. Menus, Shopping Cart, Address book, …)

Now, can you see the problem? If you go with the monolith architecture as above, every team needs to work on the same Frontend project, middleware, and backend. Releasing features, scaling features, and in general maintainability becomes a nightmare considering the scale at which Amazon operates.

This bottleneck needs to be addressed sooner than later. Enter “Microfrontends” (Speaking from just the frontend’s perspective).

You decided to decouple the experiences into atomic levels where each atomic item (shopping cart, menu items, …) can be owned and operated by their respective small teams. All of them cohesively build up to form the Amazon.com that you see as a customer.

This approach provides some amazing benefits within it:

1. None of the teams need to operate on a single codebase anymore.

2. None of the teams need to depend on the releases of the other teams.

3. Each release cycle, deployment cycle, issue cycle, and in general the entire software development lifecycle stands independent for each team.

While there are amazing benefits, you will most certainly have some disadvantages:

1. It’s complex to set up (although just for one time). You need to have a Shell (Platform team) that hosts all the smaller micro frontends.

2. Reusability is not very easy in this architecture as every team has its deployments and hosting.

3. It’s not easy to test every change unless the platform teams and other teams enforce strong integration testing rules to fail the bad deployments.

Hmm, ok. You’re giving me a mixed signal now. Should I use this or not?

Well, that’s the most commonly asked question by anyone starting with a new project.

While there is no clear guideline, you can use a rule of thumb. Whenever you feel that your use cases can span more than 1 or 2 teams, it is time to consider the “micro frontends”.

If you’re working as a single team, then you shouldn’t be using micro frontends as it unnecessarily complicates the development for no additional benefit.

So, are you going to talk about how this can be implemented?

Nah. I won’t talk about that here. I would add some links that should guide you in the right direction.

This is a pretty good website to get started to know more about the concepts in-depth. What’s even better when you can look at the ones who coined this term (micro frontend). Maybe an example for you to get started quickly?

Explore, and play around with this architecture. Compare and find the differences between traditional architecture vs this one. Share in the comments or directly reply to this email with your interesting findings. Happy to learn from you all.

📚 Popular Articles

💬 What do you think about this?

Just hit reply and let us know your thoughts!

📢 Calling for contributions

This newsletter thrives on community contributions. Your expertise, insights, and experiences matter to us! We're open to featuring articles written by our readers.

If you have a valuable perspective, a TypeScript tip, or a frontend engineering story to share, we welcome your submissions!

Just hit reply, and we will connect!

🌻 Your support matters! 🌻

Researching and writing high-quality articles demands considerable time and effort. As this newsletter is offered for free and managed alongside a full-time commitment, your support can help sustain its quality and growth.

If you enjoy the content and find it valuable, please consider supporting my efforts by visiting this link. Every contribution helps in maintaining and enhancing the newsletter's content and reach.

Thank you for being part of this journey!