[Robin]: Everything on the web is a rectangle. No matter what element you choose or what CSS you write, under the hood you’re always filling up the page with squares and rectangles of various shapes and sizes. You can make different shapes in CSS, yes, but for the most part that’s an edge case. And even then you’re not really changing the shape of the box the shape sits in. It’s really just a hack.
In the past, that technical limitation in CSS has bled into the visual design of websites. I think that’s why lately we’ve seen the Great Blobification of the web over the last year or so—super rounded corners and abstract shapes, pastel colors that swirl around on the page.
Perhaps this is a sign that folks are bored of everything being a rectangle?
Things are slowly changing though (technically, if not stylistically across the web). We’ve had clipping and masking in CSS for years now (although I don’t see these things used often enough) and we’ve had SVGs that we can do dazzling things that break the confines of those rectangle-based designs. The biggest change that I haven’t seen enough experiments with, and a tool that can help us break off from the shackles of rectangle-based design, is this: the CSS Paint API.
That’s why I was so excited to read about how Temani Afif made these funky little blob animations:
Temani wrote a while back about using this API to create this nifty fragmentation effect and all this reminds me to look into this API more. It feels like it unlocks a ton of exciting new possibilities in the land of CSS.
?
Speaking of which, when it comes to front-end development I’m always afraid of being behind. My thinking goes like this: “Hey, look at this cool thing someone made! Dang, I should learn all about that Florp Dorp framework, huh? Man, I am a garbage person for not knowing how to florp a dorp in 2021, aren’t I?”
I know, I know. This is an unhealthy way to approach my work, which is why it was so good to hear about how Rach Smith ignored the front-end scene for six months and everything was just okay:
There was a time when I would have thought that taking such a break from Front End wasn’t possible. That I had to be aware of all the new frameworks and language features to keep my career on track. I was misguided in my thinking and was placing importance on the results, rather than the process.
I feel this pressure constantly, too. And sometimes I worry that our newsletter here perhaps encourages that feeling of the front-end world swirling all around us, pushing us further away. But I always remind myself that front-end development isn’t a competition. It is (brace yourself) a craft. It’s not a collection of the fanciest tools, but instead a way to approach problems.
Just like Rach says here:
If there has been one consistency about my job, it’s that the tech is always changing. Although it can be frustrating to go back to being a complete beginner at something over and over, each time I pick up something new I further my expertise in being a lifelong learner…
?
Visualizing a codebase is a beautiful website by Amelia Wattenberger that’s one part visualization, one part interactive essay. Her argument here is that we’re very familiar with files and folders in a directory but perhaps there’s a better way to view code files and their relationship with other files.
Here’s the example Amelia shows:
The idea here is to make it easier to scan a codebase and get a better idea of what goes where and why:
Our main goal was to present a “bird’s eye view” of a codebase – a “fingerprint” that would give viewers a sense of what was in the codebase, but not overwhelm with data. Not to show all of the same information viewers can get from the folder/file view of the codebase, but to supplement that.
I like this idea a whole lot and Amelia even built a tool to visualize your own repos in this way, which is ever so neat. Scroll down the page, input your repo name, and bam—see all the code spread out just like that example above.
?
Here’s a fun web component called web-vitals-element that you can throw into a project and see a breakdown of web vitals like Largest Contentful Paint on the page. I love little tools like this:
????
Speaking of performance, I enjoyed this chat on HTTP203 about the top 10 performance pitfalls. There’s lots of small things to remember about the critical path and how assets are loaded by browsers, but going back to that note from Rach above, I think it’s real important to remember that this stuff is what’s worth learning for the future.
Performance is an evergreen problem.
That’s because everything that Jake and Surma walk through in this video are likely to be true of web performance ten years from now; reducing asset sizes, limiting the total number of asses (like fonts or images) that are downloaded, etc. These front-end constraints don’t ever change.
Take this issue that they show for example, where it doesn’t matter if you set a div to display: none, the image below will still be loaded and block initial rendering:
?
I’ve used this trick a bunch of times in side projects and full blown serious web apps, so I’m annoyed that S. Shahriar beat me to the punch here. He made this great little demo, showing how to change a plain ol’ <ul> into a comma-separated list with CSS pseudos:
Shahriar even adds the and at the end of the list, which is neat. But riffing off this, Geoff then wrote this piece that goes into depth about it all; how to make sure that things are nice and accessible, as well as how to do the fun CSS part.
Also—side note—make sure to drop what you’re doing right now and scroll through the rest of Shahriar’s pens because they are gobsmackingly good. Take a gander at this beauty, for instance; a lovingly created animation with CSS and a light touch of JS:
Bonkers, right?
?
This piece by Michelle Barker about front-end development and learning in public is very good:
Over the years I’ve tried out a lot of different ways of learning CSS and JS: books, online courses, articles, video tutorials… But for me, there’s really no substitute for learning by doing. In fact, I’d do so far as to say that this is probably the best way for anyone to learn front end coding (and perhaps most other disciplines too!). That’s not to say that the above resources aren’t useful — I still use of them frequently. But I consider them supplementary to actually learning “on the job”. Here I’d like to share what’s been successful for me when learning new front end skills, and some things that might help you too.
Perhaps the worst bit of advice I hear about writing is that “you should write what you know.” I disagree. Instead, you should write about what you want to know. Want to wield the CSS Paint API with ease? Or do the coolest animations with Framer motion? Then write about it!
It sure might sound like the scary and slow way to learn something but it’s guaranteed to help you figure things out in the long run.
(This is advice from me, to me, about me. Thank you for your time.)
?
This idea from Hayk An is snazzy: he recommends setting the line-height proportionally to the font-size of an element with calc, just like this:
h1 {
line-height: calc(0.25rem + 1em);
}I feel like I’m constantly fighting the line-height property across our large codebase, because ideally the line-height of some text should take the font-size into consideration but also the width of the text, too (fancy typographers call this the measure). Either way, I’m going to steal this idea and start to set type with a proportional line-height in my CSS.
Oh also, ranting aside, Hayk even made a neat tool called Doppler that lets you play around with all these values to create the perfect combo pairing of font-size and line-height:
Smart stuff.
Sponsor
Algolia Plugin for Netlify
Automatically index your Netlify apps using the Algolia Crawler to deliver a great user experience.
Sponsor
Six No-Code Tips That Anyone Can Use to Speed Up WordPress
WordPress.com sites are already hosted on super-speedy servers (and feature the world-class CDN coverage of Jetpack built right in), but there are all sorts of ways to boost performance even further for a blazingly fast site — and many of them are no code required!
[Chris]: I bookmarked this article the other week:
The Hustle, July 26, 2021: Corporations want to shake Microsoft Excel. It’s not so easy.
I thought this was a juicy little tidbit:
Excel is regarded as the world’s most popular “programming language” with ~750m global users (in comparison, there were only 10.7m Javascript users as of 2018).
Daaaaang.
Excel isn’t just, like 10✕ more popular than the world’s most popular programming language, it’s closer to double that.
We should try to find this information for real though right? That article on The Hustle quotes the source of that information to a newsletter:
Not Boring by Packy McCormick, March 8, 2021: Excel Never Dies
… while it’s hard to know exactly how many people use Excel regularly, estimates put it at 750 million users. By comparison, as of 2018, there were only 10.7 million Javascript developers and 7 million Python developers.
That links to this very bloggy article:
Seven reasons why Excel is still used by half a billion people worldwide by Simon Cocking, December 12, 2017
Excel is used by an estimated 750 million people worldwide and Satya Nadella has proclaimed it as Microsoft’s most important consumer product .
That links to an industry rag kinda thing:
Microsoft Excel Versus Apple’s Numbers: Who prevails? by Marc Zao Sanders, Vinit Patel and Chris Littlewood, May 25, 2017
There are now a variety of spreadsheets available, with Microsoft’s Excel leading the market share with over 750 million users worldwide.
They link to a rumor blog, which is offline now, but archive.org has it:
Microsoft Office is US #1 selling software product with one copy sold every second by Tom Warren, January 9, 2011
Office is currently used by more than 750 million users worldwide according to Microsoft.
They don’t directly quote the source there, but in other places link to this URL which is Microsoft-owned but now totally dead and archive.org doesn’t have it:
http://blogs.office.com/b/office_blog/archive/2011/01/06/office-2010-success-in-numbers-and-people.aspxSo from the horse’s mouth January 6, 2011… probably. But also at best just a number of people that use Excel, not that program within Excel, which seems like an important distinction. Not to mention, ya know, being a over-10-year-old bit of information.
Anyway — just amazing how a detail like that can poke its way through online publishing with precious little context or even a definitive source.
