Post

Michael G
@g12n.de

Nice. 🎃 the scary words are „being able to ignore 95% of the codebase when implementing a feature …“ These can cause so many code bases to bloat up. This works if your project is small and short term. It adds up over time. And changes on the design system level become harder. (1/2).

Andreas Møller
@andreasmoller.dk

I did consider making this the central theme of the post but it probably warrants a second one. The difference is that we are scared of different things. You are scared of bloat, and duplicating code which makes it much more work to make changes to the design system.

0 reposts0 likes

Andreas Møller
@andreasmoller.dk

I am scared of complexity. Having a code base where you need to hold too much information in your head just to make a simple style change. I am so scared of this, that I am more than happy to accept a code base that is much less DRY.

Andreas Møller
@andreasmoller.dk

I don’t mind that it is more work to update a design system. I worry about people updating it by mistake. With scoped styles you are trading efficiency for simplicity. On smaller projects that is not that useful. On large projects it is essential.

Michael G
@g12n.de

I would actually argue that this only works on smaller and contained projects. A large project (in my definition) is not defined by the number of users or devs. They become big the same way business grows: the second brand, that kreeps in, the next partner to support, the large campaign, the …

Andreas Møller
@andreasmoller.dk

The reason why scaling is so hard is because it is almost impossible to predict what problems you are going to have. Problems don’t scale linearly.

Michael G
@g12n.de

… shifting regulatory framework and so on. As you said: for multi-brand sites you lay a solid foundation that supports multiple themes, looks and animations. This also supports regular a/b testing (at least when having to rely on external tools).