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 Stoyan Stefanov‘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, Julia Evans writes about her experience with JS frameworks, and then dives into a little teaser for esbuild. Again, tempting!

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

Lots of variations to this concept, like:

// instead of this:
for ( let i = 0; i < arr.length; i++ ) {
    // some coding magic
}
// you can cache both the `i` and the `arr.length`
let i = 0;
const len = arr.length;
for ( ; i < len; i++ ) {
    // some coding magic
}
// caching the `i = 0` doesn't really save you anything, 
// but if you are moving stuff, might as well move that too.
// the real juice comes from moving the `arr.length` out of the loop:
// when it is inside the `for` statement, it has to be calculated *on every loop*,
// whereas doing it before, means it is only calculated once.

Or:

// instead of this:
arr.forEach( item => {
    // something like:
    document.querySelector('#root').innerHTML += `<p>${item}</p>`;
});
// you can build your HTML as a variable and reduce touching the DOM
let html = [];
arr.forEach( item => {
    // something like:
    html.push(`<p>${item}</p>`);
});
document.querySelector('#root').innerHTML = html.join();
// by creating a variable to hold your new HTML *before* the loop,
// then pushing new items into that variable *inside* the loop,
// we allow the new HTML to be built detached, which is fast.
// then we only touch the DOM once,
// and insert the joined the HTML

Lots of other similar approaches, basically look for anything that happen inside of a loop, like touching the DOM or doing some form of calculation, and try to move it out of the loop, creating "caches" to which you can append or refer.

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

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

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

Chris Coyier 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?
Robert Boedigheimer has a nifty little JS function that delays loading to window.load.

Speaking of delaying JS `til later, in a recent Vanilla JS podcast, Chris Ferdinandi spoke with Jeremy Wagner 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, Anna Migas wonders are we our worst enemies?, and in the same vein, Bramus Van Damme reminds us of an old paper written by Sir Tim Berners-Lee 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,
Atg

Top⇪

Aaron T. Grogg

Thoughts, Findings, and Rants…

Today’s Readings

Related

Leave a Reply Cancel reply

Contact

Meta