We’ve written 46 blog posts about Front-end Development. View all topics »
At Happy Cog, we work on a sprint-based cadence. Designers and developers are allocated to open projects for a specific number of hours in each sprint, and we try to keep our team members planned up to 6 months into the future. Priorities, allocations, and assignments always change during that timeframe, but having a baseline plan in place helps us forecast hiring needs and prepare early for larger engagements.
You may have heard that container queries are coming. Let’s take a quick look at what they are, why they are needed, and — if you stick with me to the end — a quick and simple container query solution that you can use today if you need them before they are ready for production.
A version of this article was originally published in 2019 but has been updated to reflect the most recent advancements in headless technology for Craft CMS as of April 2021.
What is a headless CMS? A headless CMS is a major shift from the traditional model for delivering web content. It is not a single technology, it is an approach for serving web pages and data to your users. Rather than have a single codebase handle both content management and presentation of that content, a headless CMS is only concerned with content management, leaving presentation up to other parts of the tech stack.
I am very excited for the upcoming adoption of web components. They provide a number of improvements to the developer experience of managing large codebases. If you’re not up to speed there’s a good article over on CSS-Tricks covering all the basics. It’s a bit dated but the core concepts haven’t changed too much.
I’ve had a love-hate relationship with grid systems over the years. Every system I try to standardize on becomes bloated, forgotten, or yesterday’s news. I find myself constantly switching to the next best thing. What follows isn’t a proclamation that this new system is the best, or that you should drop everything and switch. Instead, allow me to walk you through my grid system evolution so that we may all learn from it.
I have spent close to 7 years as a front-end developer at Happy Cog and in that time I’ve seen our discipline go through many great changes— from spacer gifs to responsive web design, we’ve all iterated quite a bit. This rate of change is one of the things I most love about frontend— the collaborative, communicative community that pushes us all forward whether we like it or not. As process has evolved, so too has it improved.
Why are doctors sometimes considered “cool under pressure?” Is it because their personality is one that doesn’t get riled up when faced with a challenge? Is it because they have an ingrained character trait that allows them to remain calm when everyone else is completely losing it? Have you ever noticed that web developers are sometimes labeled the same way? Is it the same thing? Are web developers saving the world too? Probably not.
How many times have you been coding a navigation and found yourself overriding the default padding on a list? Or, have you ever dove into a teeny tiny “product meta block” only to find that all your paragraphs have this ridiculous default font-size of 16px? What do you do? Well, you do one of two things… you override everything or you set more simplistic defaults.
Guys I figured it out! I figured out how to code type on the web.
I kid. However I have been really digging my approach to type in the template-build phase as of late. It’s super simple, saves you tons of time, makes your files smaller, and communication both with your teammates and the client more focused. I’m not selling CSS snake oil here, I’m just that into it.
Over the last year, I have been using Brad Frost & Dave Olsen’s PatternLab for many projects. In doing so, I have learned about building systems rather than web pages. Most of what I’ve learned is that I’ve been doing wrong out of habit.
Copyright 1995-2024 Happy Cog™
