Projects
-
Why I Switched to git switch
When I first learned1 git, I learned that to stop working in the current branch and to start working in a new branch, the command was
git checkout branchname. Or to create a new branch,git checkout -b branchname.All the way back in 2019, though, the git team released
git switch, which is supposed to replacegit checkout. (Don’t worry,checkoutisn’t going anywhere.) And finally, this year, I retrained my muscle memory to usegit switchinstead ofcheckout. Why is switch better?-
checkouttries to do too many things.git checkout <branchname>is valid, as isgit checkout <hash>, as isgit checkout -- path/to/file. These all do different things. Checking out a *branch means “start working on this branch.” Checking out a commit hash puts you in “detached HEAD” state, the source of many a developer’s footgun.2 Checking out a file reverts it to a previous state (usually to the state of the last commit).I’ve used all these use cases! Usually on purpose! But you have to admit it’s kinda confusing.
Also, if you have a file and a branch that have the same name, git has to decide which one you meant when you use
checkout. I’ve never come across this particular collision myself but I can imagine there are a non-zero number of git branches calledreadmeout there, which could lead to really unexpected results if you just typedgit checkout readmewithout looking closely at the output. -
The way to create a new branch with
switchis to use the-cflag, which means “create.” The way to create a new branch withcheckoutis to use the-bflag, which means “branch,” which is a tautology.
Basically, as I understand it, the git team felt that
checkoutdid too many things and was confusing for new users. All good reasons to split the command into two.Most important to me, however, is
git switch -which switches back to the previous branch, similar to other Unix-y commands, such ascd -, which takes you back to your previous directory.As always, saving like two keystrokes is the only thing I care about. Efficiency!
-
-
TIL: Cleaner Log Output When Using 'Concurrently'
If you’ve ever used the package
concurrentlyto run more than one thing at the same time while developing, you probably have seen how the logs are a little jumbled together. All output is logged to the console, by default, with a number representing the process that created the output. As an example, here’s a Vite frontend and a toy websocket server in the backend that logs every message received from the FE:[0] VITE v7.3.0 ready in 220 ms [0] [0] ➜ Local: http://localhost:5174/ [0] ➜ Network: use --host to expose [1] received: { 'message': 'hi' }This is…fine? But it’s easy to miss the [0] or [1], it’s just one number and honestly if you’re not looking for it it just sort of fades into the background.
But by passing the
--namesflag in you can call your processes anything you want.concurrently --names frontend,backend 'vite' 'node src/server.js'turns the above output into:[frontend] VITE v7.3.0 ready in 220 ms [frontend] [frontend] ➜ Local: http://localhost:5174/ [frontend] ➜ Network: use --host to expose [backend] received: { 'message': 'hi' }And of course you can use more descriptive names, although these are plenty for me.
I wasn’t able to find the official documentation on this, although there is documentation on how to interact programmatically with concurrently and pass in the names options. I’m not sure how to incorporate that into a development pipeline but that’s a me problem. For now, the command-line flag is all I need.
-
Making This Blog Even Faster With Speculation Rules
Browsing the HTMHell Advent Calendar I learned about a completely new-to-me browser API called “speculation rules.” This poorly-named (according to me) feature allows browsers to prefetch or even pre-render content speculatively, basically predicting what a user is going to click on. Currently, this feature is available in Chromium-based browsers, but Safari and Firefox are working on it, and in the meantime, including it doesn’t harm the experience for Firefox and Safari users.
In its most basic form, adding the following to a page:
<script type="speculationrules">{ "prerender": [{ "where": { "href_matches": "/*" }, "eagerness": "moderate" }]}</script>is all it takes to pre-render the destination link when a user hovers their mouse over it, making the load almost instantaneous from the user’s perspective.
The author of the blog post, Barry Pollard, who works on Chrome at Google, goes on to explain some of the quirks of
speculationrules. For example, how do you handle mobile users, where “hover” isn’t a thing? What about Javascript that you don’t want to execute before the page is actually viewed? (What about analytics where you don’t want to count page views before the user actually looks at the page?) These are problems that are “actively being worked on,” which means not solved just yet. I would not use this feature on a production site where I cared about any of those things.This is a progressive enhancement to
<link rel="prefetch">which is more widely supported. But the old way seems harder to implement as, at least by my read of MDN, I would have to consider exactly what links are most likely to be loaded next by the user on what pages, whereas the speculation rules API decides for me based on the user’s actions.To sum up, this is a pretty neat option that is definitely not yet ready for use on all sites. There are a lot of questions that need to be answered. But in the meantime, I think speculation rules are a perfect fit for a static, no-JS site like this blog. Which is already pretty fast, by dint of it being a static, no-JS site. 🤷
If you’re using Chrome and want to check out the new behavior for yourself, simply open Devtools, navigate to the Network tab, then hover over any link on this site. You’ll see a little blip of activity before you click. Neat!