Jargon Buster for a Frontend Architect in Technology & IT – UK
So, you’ve made it. You’re either stepping into the shoes of a Frontend Architect or you’re navigating the complex digital landscape of the UK’s thriving tech hubs from London’s Silicon Roundabout to Manchester’s MediaCity. But let’s be honest: even at the senior level, the sheer volume of acronyms and buzzwords can feel like a bit of a muddle.
As an architect, your job isn’t just to write code; it’s to build the blueprint for scalable, performant, and maintainable systems. You need to speak the language of stakeholders, developers, and designers alike. To help you stay ahead of the curve, we’ve put together a definitive jargon buster. Whether you’re refining your web performance strategies or pitching a new stack to the CTO, these 20 terms are your new best friends.
1. Micro-frontends
Think of this as the frontend equivalent of microservices. Instead of one massive, monolithic codebase that’s a nightmare to deploy, you break the UI down into independent, loosely coupled fragments. This allows different teams to work on different parts of the site using different frameworks if necessary, without treading on each other’s toes.
2. BFF (Backend for Frontend)
No, we’re not talking about your best mate. In architecture, a BFF is a design pattern where you create a dedicated backend layer specifically tailored to the needs of a particular frontend. It acts as a shim between your UI and your complex downstream microservices, ensuring your mobile app or web app gets exactly the data it needs—nothing more, nothing less.
3. Hydration
In the world of React and Next.js, hydration is the process where client-side JavaScript “takes over” the static HTML sent by the server. It attaches event listeners and makes the page interactive. If your hydration is slow, your users might see a “dead” page that looks ready but doesn’t react to clicks—a major UX no-no.
4. Core Web Vitals
These are the specific factors that Google considers important in a webpage’s overall user experience. As an architect, you’ll be obsessed with LCP (Largest Contentful Paint), FID (First Input Delay), and CLS (Cumulative Layout Shift). Optimising these is essential for SEO and user retention.
5. Tree Shaking
Imagine your codebase is a literal tree. Dead leaves (unused code) shouldn’t be there. Tree shaking is a form of dead-code elimination typically handled by bundlers like Webpack or Vite. It ensures that only the code actually being used in your application ends up in the final bundle sent to the browser.
6. Atomic Design
Coined by Brad Frost, this is a methodology for creating design systems. You break things down into Atoms (buttons), Molecules (search bars), Organisms (headers), Templates, and finally, Pages. It’s a brilliant way to ensure consistency across your entire UK-wide enterprise application.
7. Island Architecture
Popularised by frameworks like Astro, Island Architecture aims to reduce the amount of JavaScript sent to the browser. You serve mostly static HTML, but “hydrate” small “islands” of interactivity (like a shopping cart or a live ticker) only when they are needed.
8. Headless CMS
A “Headless” system is a content management system that provides content as data through an API, rather than being tied to a specific frontend “head.” This gives you, the architect, the freedom to use whatever frontend tech you fancy—be it Vue, React, or Svelte—while the marketing team manages content in a familiar dashboard.
9. SSR vs. SSG vs. ISR
These are your rendering strategies. SSR (Server-Side Rendering) generates HTML on every request. SSG (Static Site Generation) builds it all at compile time. ISR (Incremental Static Regeneration) is the “magic” middle ground where you update static pages in the background after they’ve been deployed.
10. PWA (Progressive Web App)
PWAs use modern web APIs to provide an app-like experience directly in the browser. We’re talking offline support, push notifications, and “add to home screen” capabilities without the faff of the Apple or Google app stores. For many UK businesses, a PWA is a cost-effective alternative to native development.
11. Design System
A design system is more than just a UI kit; it’s a single source of truth for your brand’s digital language. It includes components, tokens (colours, spacing), and documentation. As an architect, you ensure that the design system is scalable and correctly implemented in code.
12. Bundle Splitting
Instead of forcing your user to download one giant 2MB JavaScript file, you split it into smaller chunks. Users only download the code needed for the specific page they are visiting, which drastically improves load times, especially for users on patchy mobile data in rural parts of the UK.
13. Polyfill
A polyfill is a piece of code (usually JavaScript on the Web) used to provide modern functionality on older browsers that do not natively support it. While we’re mostly past the days of IE11, you might still need them for specific legacy enterprise environments.
14. TTI (Time to Interactive)
TTI is a non-standardized lab metric that measures how long it takes for a page to become fully interactive. It’s a key performance indicator (KPI) that you’ll likely report back to your product owners when discussing the “snappiness” of the site.
15. Throttling and Debouncing
These are techniques used to control how many times a function is executed over time. Debouncing waits for a pause in activity (like a user typing in a search bar), while Throttling ensures a function is called at most once in a specific time window (like on a scroll event).
16. CI/CD (Continuous Integration/Continuous Deployment)
This is the heartbeat of modern DevOps. For a Frontend Architect, it means setting up automated pipelines that test your code, build your assets, and deploy them to staging or production every time you push a change to GitHub or GitLab.
17. Web Components
Web Components are a suite of different technologies allowing you to create reusable custom elements—with their functionality encapsulated away from the rest of your code—using standard HTML, CSS, and JS. They are framework-agnostic, making them a safe bet for long-term architectural stability.
18. State Management
This refers to how you handle data across your application. Whether you’re using Redux, Zustand, or React’s Context API, your job as an architect is to decide how “truth” flows through your app without creating a tangled “prop-drilling” mess.
19. Shims
Often confused with polyfills, a shim is a library that brings a new API to an older environment, but it often has its own API. A polyfill, conversely, intercepts calls to a standard API that doesn’t exist yet and provides a fallback that behaves exactly like the standard.
20. Technical Debt
The “interest” you pay when you choose an easy, quick-fix solution now instead of a better approach that would take longer. As a Frontend Architect, you’re the gatekeeper. You decide when it’s okay to take on debt and when it’s time to pay it back by refactoring.
There you have it—the essentials. Mastering this terminology is about more than just looking smart in meetings; it’s about having the tools to evaluate new technologies and lead your team toward better builds. If you’re looking to dive deeper into architectural patterns, check out our other guides on Clean Code for Frontend Teams or explore the latest State of JS survey to see where the industry is heading.
Keep building, keep refining, and don’t let the jargon get in the way of your vision!