Bespoke Frontend Web Dev

The word “bespoke” is often used to describe “custom-made” products. Within the context of web design and development, it is easier to associate the word bespoke with UI design (the visual appearance of a website) than it is for front-end development (the underlying source code used to render the website in the browser) and therefore brings up some interesting questions, such as, “does it matter if it is not seen?” I would argue that it does matter because while it may not be visually seen, it can be “felt” by users due to its direct impact on the UX and performance.

3rd Party Frameworks?

One example that illustrates this notion of a bespoke frontend is the developer decision to use a third-party frontend framework or not? Popular existing frameworks include Bootstrap, Foundation, and many others. The pros are that they are easy to customize with the key benefit of saving time (and money). The cons are that they come with a K size cost (for the required dependencies), they require an ecosytem buy-in and learning curve (unique markup such as utility classes), and due to their very nature of offering out-of-the-box solutions for reusable components (design patterns) they come with the risk of looking like other websites if UI elements are not customized to a degree to differentiate them from the framework defaults.

Custom Frameworks?

How about in-house custom frameworks? That’s how bootstrap started (for Twitter) and this is a common approach for many in-house organizations with pre-defined brand guidelines and design systems (e.g. style guides, pattern libraries, etc.). But what about agencies that create unique (bespoke) websites for each of their clients?

One approach is to have an in-house framework is custom-made by the in-house team and used internally as starter frameworks for bespoke projects.

Chris’s Examples:

[ incomplete ]