For small and scrappy projects, like a prototype or a proof-of-concept, testing an idea quickly is better than coding it perfectly. For other projects, it’s important to consider how the project’s architecture may positively or negatively impact the project over time.
Many small projects grow organically. As an organic project grows larger, some unwanted patterns start to emerge. I recognized one such undesirable pattern for how my library A2k handled icons.
I spent the next few weeks learning how to better serve icons to my end-users, to ultimately create a package that was easy to use and easy to manage.
Read the full article for a breakdown on how I used:
To improve my icon library in the following ways:
- A simpler API, one custom element to rule them all.
- Serving SVGs from a single file, which reduces network requests.
- Guaranteed constraints across all icons, for more maintainable and consistent code.