Keeping the Front End Boring
This is my daily work as a lead, not one single project. I decide how we build the frontend and write the guidelines for it, review the code against them, watch performance and accessibility, and keep dependencies up to date so we never get stuck on an old version.
- Client
- Calida Group Digital GmbH, in-house
- Engagement
- The part of the job that never ends
- Role
- Frontend Lead
- Year
- 2024 to present
- Stack
- DebugBear, Web Vitals, ESLint, Stylelint, Prettier, Twig
- pages I watch, desktop and mobile
- 10Five templates, home, category, product, cart and checkout, each on desktop and mobile. DebugBear collects the numbers and I go through them as part of my week.
- linting errors on the main branch
- 0CI runs the linting for JavaScript, Twig and CSS. I set that up, including rules that check whether a component uses our custom properties instead of hard coded values.
- dependency updates
- WeeklyI update in small steps every week instead of once a year. That keeps us close to the current version and security fixes do not sit around waiting for a big release.
A lot of this is deciding something once so the team does not have to decide it again: how we build a component, what belongs in the design system, when a library is worth adding, what a review should block on. I write it down, we agree on it, and I follow it in my own pull requests too.
The other part is watching the shop. I check Web Vitals, accessibility and security myself instead of waiting for someone to report it, and if something gets worse I fix it or bring it into the sprint. Most of these improvements start as my own idea and not as a ticket. Nobody sees this work directly, but it is the reason we can still build new features quickly.