Following on from that excellent blog post about removing jQuery from gov.uk, here are the performance improvements in charts and numbers.
It may sound like 32 kb of JavaScript is nothing on today’s modern web with quick devices and fast broadband connections. But for a certain cohort of users, it makes a big difference to how they experience GOV.UK.
This is a great thorough description of the process of migrating gov.uk away from jQuery. It sounds like this guide was instrumental in the process—I love that they’re sharing it openly!
Removing jQuery means that 32Kb of JavaScript has been removed from the majority of pages on GOV.UK. GOV.UK is already quite fast to load and for many users this will make no noticeable difference. However, the change for users on a low bandwidth connection or lower specification device will be much more noticeable, resulting in significantly improved page download speed and performance.
Oh, this is smart! You can’t target pseudo-elements in JavaScript, but you can use custom properties as a proxy instead.
Excellent in-depth research by Tim on how the major frameworks affect performance. There are some surprising (and some unsurprising) findings in here.
I wish with all my heart that this data would have some effect but I fear there’s an entire culture of “modern” web development that stick its fingers in its ears and say “La, la, la, I can’t hear you.”
This is such a well-written piece! Jay Hoffman—author of the excellent History Of The Web newsletter—talks us through the JavaScript library battles of the late 2000’s …and the consequences that arose just last year.
The closing line is perfect.
You really don’t need jQuery any more …and that’s thanks to jQuery.
Here, the Github team talk through their process of swapping out jQuery for vanilla JavaScript, as well as their forays into web components (or at least the custom elements bit).
Another deep dive into web history, this time on JavaScript. The timeline of JS on the web is retroactively broken down into four eras:
Nice to see “vanilla” JavaScript making a resurgence in that last one.
It’s 2017, the JavaScript ecosystem is both thriving and confusing as all hell. No one seems to be quite sure where it’s headed, only that it’s going to continue to grow and change. The web’s not going anywhere, which means JS isn’t going anywhere, and I’m excited to see what future eras bring us.
Well, well, well …following on from my post about container queries, it turns out that Eric has also been thinking about wrangling custom properties. He’s even written some code.
Thanks to jQuery, you probably don’t need jQuery. Just look at all these methods that started life in jQuery, that are now part of the standardised DOM API:
remove()prepend()before()replaceWith()closest()A really great overview of using prefers-reduced-motion to tone down CSS animations.
This post was written by James Craig, and I’m going to take this opportunity to say a big “thank you!” to James for all the amazing accessibility work he has been doing at Apple through the years. The guy’s a goddamn hero!
I love, love, *love, traintimes.org.uk—partly because it’s so useful, but also because it’s so fast. I know public transport is the clichéd use-case when it comes to talking about web performance, but in this case it’s genuine: I use the site on trains and in airports.
Matthew gives a blow-by-blow account of the performance optimisations he’s made for the site, including a service worker. The whole thing is a masterclass in performance and progressive enhancement. I’m so glad he took the time to share this!
A new media query that will help prevent you making your users hurl.
This is a really great short explanation by Chris. I think it shows that the really power of JavaScript in the browser isn’t so much the language itself, but the DOM—the glue that ties the JavaScript to the HTML.
It reminds me of the old jQuery philosophy: find something and do stuff to it.
Another dive into the archives of the www-talk mailing list. This time there are some gems about the origins of the input element, triggered by the old isindex element.
In many ways, moving to vanilla JavaScript highlights the ugliness of working with the DOM directly, and the shortcomings of native Element object — shortcomings which Resig solved so incredibly eloquently with the jQuery API.
Having said that, the lessons I’ve learned over the last year have made me a better developer, and the tools built in the process have opened my eyes and given me enough confidence and understanding of vanilla JavaScript that the only scenario where I would personally consider using jQuery again would be a project needing IE8 support.
From the people who brought you youmightnotneedjquery.com comes youmightnotneedjqueryplugins.com.
Don’t get me wrong—jQuery is great (some of the plugins less so) but the decision about whether to use it or not on any particular project should be an informed decision made on a case-by-case basis …not just because that’s the way things have always been done.
These sites help to inform that decision.
This is a fascinating bit of web archeology: John has annotated the code from one of the earliest versions of jQuery.
The tone is a bit too heavy-handed for my taste, but the code examples here are very handy if you’re weaning yourself off jQuery.
Tim’s been running the numbers on how long it takes various browsers on various devices to parse JavaScript—in this case, jQuery. The time varies enormously depending on the device hardware.
This looks like it could be a great book for anyone looking to get starting with JavaScript.