Friday Frontend: Middle of Summer Edition
KBall from ZenDev
P.S. I will be traveling the next 2 weeks. Don’t worry, the newsletter will still go out! But I may be slow to respond to any emails or inquiries. Cheers!
CSS & SCSS
Third in a great series going through different parts of CSS grid. I found this super helpful, particularly the parts discussing the interactions of explicit placement and auto placement of items.
“Intrinsic Responsiveness”, also sometimes called fluid design, is one of my favorite new areas of web design/development. This is the ability to create sites and applications that respond to screen size without having explicit media queries and breakpoints. I don’t think everything fits into this paradigm, but the more things that can the better.
A short, handy little trick showing you how to assert multiple “not” clauses in CSS by chaining
:not. Careful about specificity though -- this can add up fast!
Ok so it’s more about loading CSS rather than writing CSS, but I thought this was a nifty trick, and one that is super simple to apply, assuming you have CSS that you actually want to load async.
I don’t think I’ve ever worked on a frontend project where I wasn’t fitting within Number, but I’ve definitely worked on some backend projects where this could be an issue, and I can definitely imagine it being a problem for some frontend situations. Luckily, we have a new type: BigInt to the rescue!
Service workers are incredibly useful, but they also have a very different lifecycle than anything else we’re used to dealing with in the web world. Definitely worth reading & thinking through… especially important to keep in mind that if you have a buggy one, you’ll need to explicitly deregister it when you do a rollback!
If you’re super comfortable with promises, this may feel relatively simple, but if promises are still confusing for you this is a great article to look through. It walks through the example of chaining together multiple asynchronous tasks (in this case API calls) where subsequent tasks depend on the results of first.
Great set of common gotchas to avoid when building with React. Most of these are React specific, but some of them apply to other frameworks as well.
This took me a couple of readthroughs to fully understand, but I’m glad I invested the time because this pattern is super useful. In fact I think I’ve previously stumbled into it without fully understanding it.
The original React course from TylerMcGinnis.com launched in 2016 and has since been taken by over 80K students with an avg rating of 4.8/5. Today, they’re excited to launch its successor. Built from the ground up, their new React and React Hooks courses will teach you everything you need to know about writing React in 2019. Get 25% off this week only
In classic Dan Abramov style, this post breaks down a very complex obscure topic and makes it make sense, blowing your mind completely along the way. Love it!
This is a wonderful post. I agree 110% with what the author Brad Frost is saying here - we have a tendency in our world to get caught up in which tools we like and try to apply them to every situation and rarely ask what the right tools are for any particular job. It’s not always trivial, and the learning curves associated with different tools can make this hard, but we should think about our learning as building up a portfolio of tools that can apply to multiple situations, and have part of our learning be focused on which tools are appropriate to which situation.
Fascinating look behind the scenes at both the process of rewriting a massively used application and the particular architectural choices made along the way. The approach used was at once incremental and all-encompassing, rewriting a piece at a time into a gradually growing “modern” section of the application that utilized React and Redux. And the results? 50% reduction of memory use and 33% improvement in load time… not too shabby.
“I have a senior engineer I’d love to promote, but he’s not good enough at listening.” This is a direct quote of a manager I spoke to while researching material for tech leads. Listening is a super valuable skill for developers, especially as you move up the ladder, or if you want to go independent/freelance. And while this article claims to be targeted at managers, I’d argue that getting good at listening will help you no matter what stage of your career you’re at.