I recently did an AMA over on DEV. Just taking the opportunity to port over some answers here like a good indiewebber.
If you were starting out as a front end dev in 2020, what would you say is the first thing you would learn and why?
You need to put yourself in a position where it’s your job to create and take care of a website. Even if that feels like a stretch for you early on. Get the domain, get the website on the public internet. Put your name on it. Now you’ve given yourself stakes, and you’ll learn technology because you must make your ideas come to life.
For me, 650 years ago, that was putting up a website for the ol’ college band. We needed a website! That sounded like fun to me, and I managed to struggle through buying a domain, hosting, and putting up a WordPress website. Then, over time, I learned front-end web technologies because I wanted to change up the design, change up the templates, add cool features, etc.
Get yourself a project and learn through the project.
How do you determine what you want to turn into a blog post and what you leave as a simple Tweet?
I usually won’t avoid the tweet. The tweet is usually a good proving ground for the blog post anyway. If nobody cared, eh, maybe not that good of a post. If it does get good engagement, it’s like the conversation around it is useful in the creation of the blog post. Plus, tweets are so easy to kick out the door. Blog posts, for me, on purpose, have a longer schedule that includes editing and scheduling and such.
Here’s an example tweet. Just a silly little UI experiment. I didn’t feel like waiting to blog about it to drop the demo. But from the Twitter thread, I got some interesting technical feedback, info about what parts people were most suprised by, and some other related ideas. That will, hopefully, lead to a much more robust blog post.
I even treat DEV like that, honestly. I wrote this blog post reaction quickly here, but then refined it for my own blog with some of the feedback.
Do you have a favorite CSS-Trick, where you were just like “wow”?
I think “scroll shadows” in CSS is one of my favorite CSS tricks of all time. It’s originally by Roman Komarov, but explained and improved by Lea Verou. I saw a tool the other day around the idea by Stefan Judis.
It’s a real mind-bender involving four-layered gradient backgrounds, each positioned, sized, and colored differently, and then behaviorally different regarding scrolling.
It’s not just a neat trick because it has real UX implications. Showing a shadow of where you can scroll is important UX. Consider this story of a recent design update in iOS that led to complete confusion around UI actions hidden behind a place you could scroll to, but had zero affordance on how to get there. (Happens to me all the time in Spotify, for the record.)
What would be your top 3 pieces of quick advice for developers trying to follow a similar path to growing their influence and exposure?
I think writing is literally the only way.
I can’t think of a developer with influence who has that influence for anything other than writing. Or if it’s not writing, then it’s a YouTube channel or some other form of creating public stuff.
How much do you see yourself personally playing with Houdini APIs as they are released? Which API are you most excited about (Painting, Layout, Typed OM, …)?
This super-low level stuff sometimes feels over my head. It’s hard for me to picture the industry implications of stuff like this just by looking at specs, ya know?
To me, it seems the Layout API has the most powerful potential.
What I’m imagining right now is that Houdini doesn’t affect normal day-to-day front-end developers like me that much. I won’t be writing much Houdini code. But I’ll use fancy things that other people create, because it does something useful for me. Just like most people don’t write their own libraries or have published npm packages — they just use them.
It’s fun to be wow’d by Houdini. If anyone is looking for that, make sure to look at Vincent De Oliveira’s showcase website.
What is your favorite thing about working at CodePen and/or CSS-Tricks?
You know what I really like? I like getting into the office every day and having a pretty decent amount of freedom of what I’m going to do that day. I’ll probably have meetings. I’ll probably have some stuff on the ol’ calendar. I’ll probably have some team expectations I’m trying to meet. But I also usually have plenty of time to pursue things that are interesting to me at the moment.
Sometimes I’m in the moment to drill through some emails. Sometimes I want to tinker with some demo that sounds like fun. Sometimes I want to write up a thought or record a video. Sometimes I want to plan something out or document something. Sometimes I want to talk something out with other people or do some pair programming.
I’m fortunate that I’m the boss (lol) and I put myself in that position on purpose so I have that freedom.
What is something that you wish we could add in CSS?
I feel like every time someone asks this we all should take every opportunity to scream Container Queries! until we get them.
The idea is that we should be able to write CSS that says, “When this element is this wide, this CSS should take effect.” And not just width, but whatever media queries we have at the page level already.
The best demo of a use case out there is Philip Walton’s page.
I want to write a card component that shuffles itself around based on how wide it is, not how wide the page is, because there isn’t always a direct connection between those two things (e.g. a card component can show up in a narrow sidebar on a large screen, but be full-width on a tablet or something).
Every component can be in a situation like that, so for the love of CSS, let me write media queries scoped to those components. I echo a lot of other people when I saw that if we had this, the vast majority of media queries we write would be these, not page-level.
Do you think it’s worth suggesting a { position: above-fold; }?
I’m not sure I’ve ever made a big fold-based decision once in my career. Not a big fan of that thinking. THERE IS A LINE IN WHICH THIS IMPORTANT MODULE MUST NOT CROSS, haha. Prioritizing the most important stuff to be higher up the page, sure. Websites don’t fold like newspapers.
Plus, we’ve got viewport units now, so if you absolutely need to position something in the top visible viewport area, you can.
Since you’ve been writing blog posts for so long, have you developed a process for writing one?
Sorta! It still feels pretty casual to me (let’s call my writing medium quality), so it’s not like I’m renting a cabin in the wilderness and finding inspiration in the sunsets and cheap whiskey.
- I write down every blog post idea that comes to me. I try to keep that list fairly public but I also have a personal list where I can be even sloppier.
- I put as much context into those lists as I can, so I can hope to summon up the same emotion that made me write it down in the first place. If I revisit the idea a week later and can’t, it’s probably not a very good idea.
- I write up the post with as much context as I can. Light research is typically involved.
- We have a lead editor on CSS-Tricks, so it’s reviewed by at least one person before being scheduled.
CSS or CSS-in-JS?
I see a ton of cool stuff happening in CSS-in-JS. I think it solves a lot of interesting problems for certain websites. For example, I very much like the idea of having the option to write styles that are scoped to a component programmatically, and thus are tree-shaken when the component isn’t used automatically.
But the web is a big place, and dare I say most websites aren’t built with JavaScript-powered component models. Thus, CSS-in-JS isn’t necessary or appropriate for a lot of sites.
Although, two things to be clear:
- You can’t have CSS-in-JS without CSS. CSS-in-JS is still styles that are applied to elements. It doesn’t absolve you from learning CSS.
- The CSS-in-JS landscape is wide. It’s a little hard to talk about so vaguely. Each project in the bucket of CSS-in-JS handles things a bit differently and how the styles are applied to the site is even quite wide. I think it sometimes gets lost in the arguments that some of the approaches literally make a CSS stylesheet that you link up like you would any other CSS — even Sass-produced CSS — which there doesn’t seem to be much argument about anymore.