The Layout Team

For the last couple of months I've had this idea spinning in my head, which I'm calling:

The Layout Team

Is a work in progress and I'll try to update it when new things come to my mind. The topic can be discussed forever, I will try to formalize the idea while keeping it short.

I see how the frontend industry is led mostly by hype, and this time I'm not fond of the direction we are going, specifically with micro-frontends. This pattern, spite of its benefits, I don't think it can be implemented properly by most teams, and it's not an idea we should keep suggesting.

Instead, I'm going to propose an alternative, mostly in the middle. And as you probably guessed... it's "The Layout Team".

As far as I'm concerned, the ultimate goal of a frontend is to deliver a good user experience, and this includes being fast.

Micro-frontends, make this target hard to achieve.
If you pull parts from all around it will take longer than pulling from a single place. Of course some teams can accomplish this (out of the question), and they may need it, but most of the time, is not required, but... what do we do then?

The main issue to me, is that a frontend application has to be glued together at some point, or somewhere. Whether you use a micro-frontend architecture or a monorepo, the final user has to experience one cohesive app, this is different to backends, there's no UI there, mostly machines talk with APIs. Your frontend talks with the API, but the human interacts with the frontend.

Hence the introduction of "The Layout Team" (I'm giving it a formal name).

This team could have many different flavours. But ideally, it should be an independent team, holding ownership of the layout of the app.

Yes, there's nothing fancy here, and the title is self-explanatory.

The Layout Team maintains the layout, and checks that everyone operates inside the boundaries created by this team.

Its responsibilities include:

• Monitor styles to prevent overlapping components or breaking issues
• Review Pull Requests
• Train other developers, whether through quarterly presentations or one-to-one coaching, but do it consistently over time. Not fire and forget.
• Maintain some shared state (logged user or is_authenticated or any other herbs). But most of the times teams should be able to add and manage their own global state
• Write tools to assist other teams, like linters to prevent CSS or JS
• Identify CSS or JS code that may affect the whole app, and potentially code them into the linters. Example:
  • Do not use fixed/absolute because... (unless approved to do so)
  • Do not use negative margins because we found that no one knows who to...
• Write tests for the layout

One easy way to do this, is by having a monorepo. The layout for the different pages is defined by "The Layout Team", and the rest of the teams write components, which can be later placed in the places designated by the layout team.

By doing this, it becomes very easy to produce a small bundle. Because the dependencies are shared. It's then potentially easier, to identify shared code and cache it in a separate bundle across the application.

One of the "benefits" of micro-frontend is supposed to be the freedom for teams to choose what framework to use, but you end up sending bigger assets to the end user.
This goes against optimizing for the best user experience. So ideally, stick to a single framework, and deliver it once.

If you are using React in your monorepo, it means everyone will stick to that version. If you have multiple repos, even if everyone uses the same framework, you may end up with different versions, or even the same and still delivering them as part of each apps bundle!

Finally, The Layout Team leverages the use of flex and grid heavily.
They shape the app over time. And create slots for each team.

Let's see an example:

<div class="box grid grid-cols-2">
  <div maintainer="teamA">
    <ComponentFromTeamA/>
  </div>
  <div>
    <div maintainer="teamB">
      <ComponentFromTeamB/>
    </div>
    <div maintainer="teamC">
      <ComponentFromTeamC/>
    </div>
  </div>
</div>

- Hey! It's almost the same example as a micro-frontend!

- Well... yes, what did you expect?

Each team now has a space to place their components, and there's full visibility over who maintains what.

It is very important, that the people, that are part of this team, understand flex and grid very well.

Useful layout resources

• guide to flexbox
• 1linelayouts
• csslayout

I would very much like your feedback.

• What has been your experience with micro-frontends?
• Do you think "the layout team" would work?
• What do you think of this proposal?

Thanks for reading