Today’s Readings

Convert inline JS to a data-uri and add async to the script element to bypass CSS blocking… Well that’s one of the odder topics I’ve ever seen, and is certainly not for all use cases (but then again, neither is inline JS), but ‘s technique is solid!

Speaking of Stoyan, I recently pointed to his article Plugging memory leaks in your app. Well, the lovely folks on the Edge team are here to help you find, and plug, your app’s memory leaks

Aaannddd, lest we be lulled into loving a Microsoft browser, something like this rears its head… With so much good will going for them lately, shame to see something unnecessary like this pop-up…

CSS’ aspect-ratio has been bouncing around for a li’l bit now, but it looks like it is pretty much ready for prime time!

Anyone taken a test-drive (or more) with Django? Looks tempting!

Speaking of (possibly) new stuff, writes about her experience with JS frameworks, and then dives into a little teaser for esbuild. Again, tempting!

offers a quick bit on what is for most of us probably pretty obvious, and yet something that is easily missed: scope caching.

Serve local file system folders instead of server-based files for dev work, without any local server running! Pretty f-ing slick! Thanks to and Service Workers!

I really like the idea of approaching performance refinements from a high level, rather than page-by-page. writes about how her agency approached this.

Quicky from to help position: sticky work on a grid column

asks Why would a business push a native app over a website? I read Chris' points sort of like "what can we do to make our PWAs (or just websites) better, so users do not need/want/desire an app over the web", but to me the biggest hurdle is still the user mentality that "if I pick up my phone/tablet and it is not to search for something on the web, then I must need to use an app"... And to me, this is all thanks to Apple, for creating the mindset with their store, and for restricting browser capabilities for so long (partially by blocking any other real browser on their device at all... And how do they still get away with this? Wasn't Microsoft in lots and lots of courtroom battles all over the world about this very thing on Windows PCs???). So, how to we get around that mindset?

async and defer are great, for what they do:

  • async tells the browser "carry on while I download this"
  • defer tells the browser "let everybody else go first, then come back to me"

async files can thus finish loading in any random order, based on how fast they each download, while defer will retain its loading order, but that loading will start, and thus finish, some time after DOM Interactive (or performance.timing.domInteractive, or $(document).ready(...), whichever helps). But in both cases, these files could, and likely are, blocking other assets from loading. So what if want something even later than that?
has a nifty little JS function that delays loading to window.load.

Speaking of delaying JS `til later, in a recent Vanilla JS podcast, spoke with about using requestIdleCallback to delay JS loading until the browser has time to take a breath. I was pretty excited about this idea, until I realized that IE Safari doesn't support it yet... :-/

And finally, wonders are we our worst enemies?, and in the same vein, reminds us of an old paper written by and encourages us to embrace The Rule of Least Power... I like it, a lot. It is easy, perhaps even natural, for us to find one way of doing something, and simply rinsing-and-repeating that forever, until something forces us to do it differently. No one is saying go back to all of your old projects and update them for these new ways (though, wouldbe good practice!), but certainly going forward, we can do better!

Happy reading,

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.