DEV Community

Cover image for Tips to avoid legacy growth in your large scale web system (for frontend)
Leonardo Rafael Wehrmeister
Leonardo Rafael Wehrmeister

Posted on

Tips to avoid legacy growth in your large scale web system (for frontend)

Hi Devs!

I would to share some tips to avoid legacy growth in your large scale web system (for frontend). This is just my personal experience. Don't need to be the truth and all discuss are welcome.

By following some tips, you can keep your system always up to date, facilitating maintenance and framework/ecosystem changes. And this can also help keep your DX level high (most of the time):

1) Break your frontends into small repositories

2) Don’t bet on just one framework/ecosystem

3) Use a global CSS

4) Use semantic HTML

5) Don't create components for everything, only those that have some logic

6) Use only one router

1) Break your frontends into small repositories

Divide and conquer. Here repositories can be divided into parts of the system, such as a page or a group of pages. Breaking your frontends into small repositories, in addition to making deployments easier, can give you more freedom to try new things, refactoring or even using another stack. This approach allows you to try things without fear, as you won't be impacting the system as a whole. It also allows you to work with multidisciplinary teams from different squads and skills.

2) Don’t bet on just one framework/ecosystem

We currently have several fantastic frameworks and ecosystems that meet our needs. But their lifespan is always unknown. After a certain time, some items in the ecosystem begin to be depreciated. Then the dev's satisfaction with them starts to decline. From the moment you realize that you are trying too hard to do simple things, it may be time to do something about it. The important thing here is to try to keep the team's DX always high.

3) Use a global CSS

The global CSS is to prevent the system from having a "frankenstein UI". What is a "Frankenstein UI"? As we have several repositories, with several components, several stacks and several UIs, this can all result in a "moderately" different UI between one page and another. Here the tip is not to use different UIs. Avoid using UIs linked to some framework/ecosystem such as Material-UI, Vuetify, Quasar and others. Mixing these types of UIs together can generate severe differences between your pages.

4) Use semantic HTML

This is a very current point. Instead of having components for everything, why not directly use semantic HTML? You can have dialogs, buttons, cards among others, writing clean and unified HTML throughout the system. As semantic HTML is part of the web platform, it is independent of any framework/ecosystem, so you open up the range of options to use anything on your system. It's a blank page, ready to be colored however you want. I recommend a class-light approach as done at https://www.beercss.com. There are others too, just google it.

5) Don't create components for everything, only those that have some logic

This point is in line with the previous one. If you choose to use semantic HTML, you will realize that creating components for everything ends up being "pointless". Semantic HTML already has unique markup that you can use system-wide. Abstracting a button, card, nav, among others into a component no longer makes much sense. The tip here is to only create components when you have some type of logic within them, such as parts of a form or an autocomplete.

6) Use only one router

When we break our frontends into multiple parts, we need "glue". The "glue" for all these repositories, which were separated by page or group of pages, would be the router. It is important to have this unique router, so we can make the necessary initializations on each of our frontends. Avoid routers linked to a framework/ecosystem if you intend to use different stacks on your system at the same time.

Hope you enjoy and feel free to discuss about it!

Top comments (1)

Collapse
 
framemuse profile image
Valery Zinchenko

As for 5th one, sounds like you don't have much expertise in writing styles for UI components :)
As for me, using semantic button doesn't allow me to get rid of creating another Button component just for styling cuz' - it's simply convenient as it can have lots of customization points.