[Robin]: One of the nifty things about VS Code is that you can run tasks when you open up a project. So instead of having to open up the command line and also have VS Code open at the same time, you can configure VS Code to run tasks like Gulp automatically. Chris wrote about this very thing and how he got a Gulp task running. This had me thinking, why don’t I do this for my own little site, too?
So, first up I opened the workspace for my site in VS Code. Then I selected the default task by hitting
P and selecting
Tasks: Configure Default Build Task
After clicking this, VS Code rather smartly shows that there are a bunch of different options from the scripts section from within my
package.json which looks something like this:
gulp dev & eleventy --serve? That’s what runs when I type
npm start into the command line and it’s what boots up my local environment for my website. Anyway, once I selected
Configure Default Build Task I selected
Like I said,
npm start runs every task within
gulpfile.js and kicks off the Eleventy build process. Once that’s done now I can hit
b on a Mac and that task will pop off and start running in VS Code’s command line. Neat! That’s much faster than having to load two separate apps to build something on my personal blog.
Now, if I head to
tasks.json, we can see this default task that we’ve setup. But I want to have this command run every time I open up this workspace (I’d prefer not to have to manually do it each dang time). So! I edited the task that looked like this:
"label": "npm: start",
"detail": "gulp dev & eleventy --serve",
And then from here I can add the
runOptions property and set
"label": "npm: start",
"detail": "gulp dev & eleventy --serve",
Once I’ve selected
Allow and Run in the popup that appears after I save this file, I can now just open up this workspace and
gulp dev & eleventy --serve will run automatically! The command line at the bottom will pop up and things will get started automagically. That’s pretty neat and saves me having to open up another command line app and type yet another command.
Effective Skeleton Screens
I enjoyed this post by Tim Kadlec on making effective skeleton screens. He looks at a bunch of examples in apps and websites today and how to make the best use of them.
What I particularly like about the post is this bit, where Tim has some great advice for any performance hot tip you might’ve heard:
One of the healthiest and most important things we can do is continuously challenge ourselves to question why a “best practice” is labeled as such. When we understand why and how it works, we put ourselves in a much better position to know how to properly apply it in our own situations, and when it makes sense to do so.
Container Queries Update
It looks like there’s some good news on the horizon for container queries. I’m glad we haven’t forgotten! The Blink team has made an Intent to Prototype which sounds like this has some serious effort being put into it now from at least one browser. That doesn’t mean anyone is about to ship container queries any time soon but it’s great to see some form of progress here.
I’m told that this went public about a month too early and there wasn’t time to form a more cohesive message. So if you’re thinking “why doesn’t the CSS Working Group appear to be involved?” they apparently will be — just caught everyone off guard. There are a number of links involved here far:
- The Google Group post that is the “Intent to Prototype” thing. I can quite tell who the person is. You can only see part of the email address of the person who posted it.
- The “bug” in the Chromium tracker. Starring that is helpful for signaling interest. That should have, like, thousands of stars if you ask me.
- A Google Form for letting the Chrome team know you’re interested and would like to try them.
- David Baron’s original proposal, which Miriam Suzanne tweaked and seems to have kicked off this whole thing. It’s the
containproperty that has opened up doors to making this all possible.
It will be very interesting to see this evolve. Particularly the syntax and possibilities. If those are good, this is life changing stuff. If the syntax is obtuse and and the possibilities are limited, it won’t be the big bang we’re all hoping for.
Also fascinating: like so many of new web features, this is coming right from Google and will be prototyped and probably-eventually shipped in Chrome. What will the cross-browser web story be? What if Safari objects? Are there enough platform people left at Mozilla to implement it even if they like it? Can it become a standard if only one browser is involved anymore? We’ll find out.
Chris wrote about this extremely nifty trick that you can pull off with the
picture element — switching out a gif with a static image when add a media query like this:
<source srcset="no-motion.jpg" media="(prefers-reduced-motion: reduce)"></source>
<img srcset="animated.gif" alt="brick wall">
Pretty neat, huh? That also reminds me that there’s this punk rock technique to do something similar with the
summary elements by effectively adding a pause button to a gif.
Building a Commenting Engine with Next.js and Sanity
Sanity is a CMS and Next.js is the newest hotness so it’s great that Bryan Robinson wrote about how to build a commenting engine with these new tools:
Why Sanity? Sanity.io is a flexible platform for structured content. At its core, it is a data store that encourages developers to think about content as structured data. It often comes paired with an open-source CMS solution called the Sanity Studio.
We’ll be using Sanity to keep the author’s content together with any user-generated content, like comments. In the end, Sanity is a content platform with a strong API and a configurable CMS that allows for the customization we need to tie these things together
I haven’t used Sanity yet on any projects but it sure looks great. One thing I always do when I look at a new service is check out the docs, and Sanity’s sure don’t disappoint. Good docs typically mean a great product.
Want to understand how visitors are really experiencing your site? Hotjar makes it easy. Sign up for a 15-day free trial and start collecting and learning from real user behavior today!
My go-to code font at the moment is IBM Plex Mono which is featured in our collection, partly because it’s great, but also because the website for IBM Plex is remarkable, too. Each section zooms into the letters so you can see how and why it works:
Anyway — back to bragging — our coding font site is great because you can compare and contrast how typefaces feel which is pretty hard to do when you’re looking through all the different type vendors that sell them. In fact, this site has already worked it’s magic on me — after looking at an early version of the site I went ahead and refactored Sentry to use IBM Plex and I think it looks weird and cool and fun. Even at small sizes, I think it has a lot of charm:
It’s difficult to see in a picture, but these are tags in Sentry, which are little bits of information that are helpful when trying to debug a problem. And if you can make a typeface work at this size and also make it look a tiny bit charming, then you can rest assured that you’ve picked a pretty darn good typeface.
No matter which stack you use, or where you’re deploying your app, FaunaDB gives you effortless, low-latency and reliable access to your data via APIs familiar to you. So unleash your creativity and build fearlessly, without boundaries.
[Chris]: Using an emoji as a favicon is a cool little trick. Emojis already look pretty good small, so just picking one for a site feels like a much less arduous task than trying to design something from scratch. I made a microsite for it one time, but this one is way better. It gives you the code, allows you to customize it, and does letters as well as favicons.
I tossed on on my personal site, what the heck.