I love how Remy explains front-end development to his kids:
The bones are the HTML. Each bone has a name, we call them tags (or elements).
…the skin and the paint on the skin, this is CSS.
Finally, the brain and behaviour, the way the website can be interacted with is using the third layer: JavaScript.
Mike sees the church of JS-first ignoring the lessons to be learned from the years of experience accumulated by CSS practitioners.
As the responsibilities of front-end developers have become more broad, some might consider the conventions outlined here to be not worth following. I’ve seen teams spend weeks planning the right combination of framework, build tools, workflows and patterns only to give zero consideration to the way they architect UI components. It’s often considered the last step in the process and not worthy of the same level of consideration.
It’s important! I’ve seen well-planned project fail or go well over budget because the UI architecture was poorly planned and became un-maintainable as the project grew.
Like a little mini CSS Zen Garden, here’s one compenent styled five very different ways.
Crucially, the order of the markup doesn’t consider the appearance—it’s concerned purely with what makes sense semantically. And now with CSS grid, elements can be rearranged regardless of source order.
CSS is powerful and capable of doing amazingly beautiful things. Let’s embrace that and keep the HTML semantical instead of adapting it to the need of the next design change.
Are many of the modern frontend tools and practices just technical debt in disguise?
Ooh, good question!
Backend logic? JavaScript. Styles? We do that in JavaScript now. Markup? JavaScript. Anything else? JavaScript.
Historically, different languages suggested different roles. “This language does style.” “This language does structure.” But now it’s “This JavaScript does style.” “This JavaScript does structure.” “This JavaScript does database queries.”
The value you want form a CSS expert is their CSS, not their JavaScript, so it’s absurd to make JavaScript a requirement.
Absolutely spot on! And it cuts both ways:
Put CSS in JS and anyone who wishes to write CSS now has to know JavaScript. Not just JavaScript, but —most likely—the specific ‘flavor’ of JavaScript called React. That’s gatekeeping, first of all, but the worst part is the JavaScript aficionado didn’t want CSS on their plate in the first place.
Chris Ferdinandi has a good rule of thumb:
If something I want to do with JavaScript can be done with CSS instead, use CSS.
Makes sense, given their differing error-handling models:
A JavaScript error can bring all of the JS on a page to screeching halt. Mistype a CSS property or miss a semicolon? The browser just skips the property and moves on. Use an unsupported feature? Same thing.
But he also cautions against going too far with CSS. Anything to do with state should be done with JavaScript:
If the item requires interaction from the user, use JavaScript (things like hovering, focusing, clicking, etc.).
‘Sfunny; I remember when we got pseudo-classes, I wrote a somewhat tongue-in-cheek post called :hover Considered Harmful:
Presentation and behaviour… the twain have met, the waters are muddied, the issues are confused.
A terrific piece by Rob that is simultaneously a case study of Pro Publica work and a concrete reminder of the power of separating structure and presentation (something that I worry developers don’t appreciate enough).
Don’t get stuck on what different types of information are “supposed” to look like. They can take whatever shape you need them to.
I share the concerns expressed here about the “sizes” attribute that’s part of the new turbo-powered img element (or “the picture element and its associates”, if you prefer). Putting style or layout information into HTML smells bad.
This is a concern that Matt Wilcox has raised:
Change the design and those breakpoints are likely to be wrong. So you’ll need to change all of the client-side mark-up that references images.
I can give you a current use-case: right here on adactio.com, you can change the stylesheet …so I can’t embed breakpoints or sizes into my img elements because—quite rightly—there’s a separation between the structural HTML layer and the presentational CSS layer.