The folks at Voorhoede share how they integrated the actions/cache@v2 build step into their GitHub Workflow so that it caches npm install results.
JavaScript performance beyond bundle size
Nolan Lawson, on how we might focus too much on JavaScript bundle size:
Performance is a multi-faceted thing. It would be great if we could reduce it down to a single metric such as bundle size, but if you really want to cover all the bases, there are a lot of different angles to consider.
He digs into other factors that have an influence:
- Parse/compile time
- Execution time
- Power usage
- Memory usage
- Disk usage
Launching the Facebook Map
Jodah Adkins from Stamen Design:
For the past year and a half, it’s been our privilege to work on one of our largest and most ambitious undertakings ever: collaborating closely with a team of Facebook engineers, designers, and data experts to roll out a global, multi-scale base map for all of Facebook’s billions of users. In late 2020, this map went live, and we’re extremely proud of the results.
Always in for a good map, so definitely for this behind the scenes look!
Via Thomas Steiner
Diving into the ::before and ::after Pseudo-Elements
Extensive article by Will Boyd on the ::before and ::after Pseudo-Elements.
This article starts on the ground floor, explaining these pseudo-elements and how to use them. We’ll dive into saucier topics as the article progresses. We’ll also be talking about the CSS content property a lot, since it’s very much related.
Before You React.memo()
Dan Abramov shares 2 techniques to try before resorting to optimize with React.memo()
In this post, I want to share two different techniques. They’re surprisingly basic, which is why people rarely realize they improve rendering performance.
These techniques are complementary to what you already know! They don’t replace memo or useMemo, but they’re often good to try first.
Covered Solutions:
- Move State Down
- Lift Content Up
SYMPHOSIZER – Playing with SF Symphony’s new Visual Identity
At first sight the new visual identity for the San Francisco Symphony (pictured below, on the right) looks a bit off …
Those letters sure look a bit oddly sized, no? Turns out there’s a dynamic drive behind them:
Leveraging new creative technology including variable font design, our new visual language (of which the logo is just the beginning) will use typography itself to bring the essence of sound and music to life.
Bringing typography to life through sound? The SYMPHOSIZER website let’s you do exactly that.
Let the site have access to your microphone and start making some noise!
Lifting up the hood using view-source: they use p5 to capture the audio and after some processing pass the resulting numbers to font-size, font-variation-settings, and transform: skew().
splitChars[wornum].chars[i].style.fontSize = fontSize + 'px';
splitChars[wornum].chars[i].style.fontVariationSettings = "'vrsb'" + isTop + ", 'hght'" + smoothH[i] + ", 'ital'" + smoothI + '';
splitChars[wornum].chars[i].style.transform = 'skew(' + smoothSkew + 'rad)';SYMPHOSIZER →
San Francisco Symphony – Visual Identity →
The possibilities of this new identity are endless. Take these posters for example, which look really great:
Mars 2020 Entry Descent Landing
Relive the whole Mars 2020 Entry Descent Landing in your browser, in 3D, powered by Three.JS/WebGL 🤯
Here’s a few pointers to use:
- Use the ⏪ ⏩ at the bottom to speed up / slow down the animation
- Scroll over the pane on the left to jump between phases of the landing
- You can click and drag around as you see fit, zooming also possible
front-of-the-front-end / back-of-the-front-end
Late 2019 Brad Frost already pondered about The Great Divide and introduced the terms “front of the frontend” and “back of the frontend”. In a new post he gives the easily-shareable overview that lists the differences between both.
A succinct way I’ve framed the split is that a front-of-the-front-end developer determines the look and feel of a button, while a back-of-the-front-end developer determines what happens when that button is clicked.
- A front-of-the-front-end developer is a web developer who specializes in writing HTML, CSS, and presentational JavaScript code.
- A back-of-the-front-end developer is a web developer who specializes in writing JavaScript code necessary to make a web application function properly.
Imo this separation also is present in backend development, where you have the “front-of-the-backend” people and “back-of-the-backend” people. Hear me out:
- A Front-of-the-backend person writes PHP/JS/etc. scripts which perform the required actions such as inserting records into a database, sending off an e-mail, etc.
- A Back-of-the-backend person provisions and maintains the infrastructure.
You might already know these two parties as “backend devs” and “ops”, so nothing new there. Thanks to things like Docker and CI/CD the line between both has become more and more vague, with overlaps in responsibilities between both.
front-of-the-front-end and back-of-the-front-end web development →
An Interactive Guide to CSS Transitions
Putting libraries like GSAP and Framer Motion and React Spring aside, Josh W. Comeau digs into the transition property — “the CSS motion workhorse”
as he calls it — and easing functions.
I especially like the sandbox at the very end of the post that lets you play the various easing functions and framerate
