Josh Comeau has a new learning guide out for CSS grid: An Interactive Guide to CSS Grid. I like how Josh gets into the “mental model” right away, because that’s the biggest thing with big APIs like this: you need to get the basics of how it works in your head so you know when and why to reach for it. The niche details are less important. You can look them up. Mostly you need to understand that the thing exists and what it is capable of. Ideally you can write a basic setup from memory. Then the more niche stuff you reference. Josh’s guide, especially with the interactivity, loads you up with that mental model.
Josh has done the same before with an An Interactive Guide to Flexbox. The interactive bit goes a long way in locking in that mental model. In my CSS-Tricks days, our guide to flexbox was also decent at explaining the model I think, and also was a decent reference guide at the same time. But it didn’t have that interactivity so people were left to extracting the information to their own code to play. Once people are writing their own layout code, I’d wager that’s also a pretty big moment for locking in a mental model. CodePen editable embeds might be a good way to bring that to guides like this. I know that a very lot of people had their ah-ha moment with flexbox via Flexbox Froggy, and I think it’s that combination of interactivity and real code that made that so effective.
Speaking of Cool Josh Ideas, have you seen his operator lookup page? JavaScript has a pretty decent number of operators, and some of them you really have to look up to remember sometimes:
Sometimes my brain goes… what’s the one where you set the value, but if the value is null, provide a fallback. Which is this one.
Do you know about import maps yet? They aren’t some new niche thing, they are supported across the board. (Well, a little new, maybe).
I like Yoshi Huang’s article(s) on them, they do a good job of setting the stage.
My brain goes a little like this. This is really common code to see, but it’s actually invalid JavaScript:
import lodash from "lodash";If you see code like that, traditionally, it means that the JavaScript will be going through a processor of some sort that is going to resolve "lodash" to some actual location where that code can be found. If we wanted that code to be valid JavaScript, we’d either have to:
- Import from a relative file path (e.g. that string has got to start with a dot or a slash)
- Import from a URL
The latter being like:
import lodash from 'https://cdn.jsdelivr.net/npm/lodash@4.17.21/+esm'But now, the original import statement actually is valid. That is, as long as we use an import map. From Yoshi’s article, something like:
<script type="importmap">
{
"imports": {
"lodash": "/node_modules/lodash-es/lodash.js"
}
}
</script>Think of it like string replacement. The "lodash" in the import statement becomes "/node_modules/lodash-es/lodash.js" and a valid relative file path import. That could be a URL as well.
I like the idea that an import map can help orchestrate imports across an entire codebase from one place, and eliminate a lot of repetition, and be a tool in using less build processes.
I talk about them quickly in a video I did the other day if that’s helpful. There is some extra nuance to them, like an import map key can replace only part of an import path if that’s helpful.
It seems like a relatively small thing in the wide world of web development, but I think it has big implications. I know Baldur Bjarnason definitely thinks so, as he’s got a whole course called Uncluttered: Free yourself from Node with import maps and test-driven web development, which I’ve just started taking myself.
Shout out to Flavio Copes for the recent release of The Valley of Code which looks like a great reference, up from “first principles”, of web development work. Not a lot of guides like this are so comprehensive the start out with URLs and DNS before going on to higher level languages like HTML and CSS.
There is even a section on using CodePen so color me a little biased.
I shared a video of Szenia Zadvornykh’s Crowd Simulator the other day (just because it’s awesome). It’s just one image if you can believe that. Us early 2010’s developers remember sprite sheets.
It’s almost like those illustrated people are the result of some fancy drawing algorithm. Well, here’s something like that! CSS-PEEPS is “one CSS file, one <div>, and over 5 MILLION combinations” of people.
That’s me in 2 years when I inevitably need glasses and try hair regrowth techniques doing my “well actually” look.
A bit of a random add-on here, but I think I agree with Evert Pot when he says:
So while React/Next.js may be relegated to the enterprise and legacy systems in a few years, they completely transformed front-end development and created ripple effects in many other technologies. One of many great ideas stemming from this stack is JSX. I think JSX has a chance to stay relevant and useful beyond React/Next.
I’m maybe a little more bullish on Next.js because it does a lot really well, has a lot of momentum, support, and has some DX that is hard to match. But that’s a little besides the point. JSX, as an industry thing, might just end up having bigger influence over time than React itself. It’s just a pretty good HTML templating language.