Monday, March 29th, 2021
Thursday, April 23rd, 2020
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.”
Tuesday, April 2nd, 2019
Thursday, February 21st, 2019
A tiny lesson in query selection
We have a saying at Clearleft:
Everything is a tiny lesson.
I bet you learn something new every day, even if it’s something small. These small tips and techniques can easily get lost. They seem almost not worth sharing. But it’s the small stuff that takes the least effort to share, and often provides the most reward for someone else out there. Take for example, this great tip for getting assets out of Sketch that Cassie shared with me.
querySelector to get a reference to an element in the DOM:
var someElement = document.querySelector('.someClass');
Before going any further, check to make sure that the reference isn’t falsey (in other words, make sure that DOM node actually exists):
if (!someElement) return;
That will exit the script if there’s no element with a class of
someClass on the page.
The situation that tripped us up was like this:
var myLinks = document.querySelectorAll('a.someClass'); if (!myLinks) return;
That should exit the script if there are no
A elements with a class of
As it turns out,
querySelectorAll is subtly different to
querySelector. If you give
querySelector a reference to non-existent element, it will return a value of
null (I think). But
querySelectorAll always returns an array (well, technically it’s a NodeList but same difference mostly). So if the selector you pass to
querySelectorAll doesn’t match anything, it still returns an array, but the array is empty. That means instead of just testing for its existence, you need to test that it’s not empty by checking its
if (!myLinks.length) return;
That’s a tiny lesson.
Sunday, September 9th, 2018
You really don’t need jQuery any more …and that’s thanks to jQuery.
Sunday, June 3rd, 2018
I’ve come to believe that the goal of any good framework should be to make itself unnecessary.
The ultimate purpose of PhoneGap is to cease to exist.
That makes total sense, especially if your code is a polyfill—those solutions are temporary by design. Autoprefixer is another good example of a piece of code that becomes less and less necessary over time.
But I think it’s equally true of any successful framework or library. If the framework becomes popular enough, it will inevitably end up influencing the standards process, thereby becoming dispensible.
querySelector without jQuery. The library proved the need for the feature. The same is true for a whole load of DOM scripting features.
The same process is almost certain to occur with React—it’s a good bet there will be a standardised equivalent to the virtual DOM at some point.
When Google first unveiled AMP, its intentions weren’t clear to me. I hoped that it existed purely to make itself redundant:
As well as publishers creating AMP versions of their pages in order to appease Google, perhaps they will start to ask “Why can’t our regular pages be this fast?” By showing that there is life beyond big bloated invasive web pages, perhaps the AMP project will work as a demo of what the whole web could be.
Alas, as time has passed, that hope shows no signs of being fulfilled. If anything, I’ve noticed publishers using the existence of their AMP pages as a justification for just letting their “regular” pages put on weight.
Worse yet, the messaging from Google around AMP has shifted. Instead of pitching it as a format for creating parallel versions of your web pages, they’re now also extolling the virtues of having your AMP pages be the only version you publish:
In fact, AMP’s evolution has made it a viable solution to build entire websites.
On an episode of the Dev Mode podcast a while back, AMP was a hotly-debated topic. But even those defending AMP were doing so on the understanding that it was more a proof-of-concept than a long-term solution (and also that AMP is just for news stories—something else that Google are keen to change).
But now it’s clear that the Google AMP Project is being marketed more like a framework for the future: a collection of web components that prioritise performance …which is kind of odd, because that’s also what Google’s Polymer project is. The difference being that pages made with Polymer don’t get preferential treatment in Google’s search results. I can’t help but wonder how the Polymer team feels about AMP’s gradual pivot onto their territory.
If the AMP project existed in order to create a web where AMP was no longer needed, I think I could get behind it. But the more it’s positioned as the only viable solution to solving performance, the more uncomfortable I am with it.
Which, by the way, brings me to one of the most pernicious ideas around Google AMP—positioning anyone opposed to it as not caring about web performance. Nothing could be further from the truth. It’s precisely because performance on the web is so important that it deserves a long-term solution, co-created by all of us: not some commandents delivered to us from on-high by one organisation, enforced by preferential treatment by that organisation’s monopoly in search.
It’s the classic logical fallacy:
- Performance! Something must be done!
- AMP is something.
- Now something has been done.
By marketing itself as the only viable solution to the web performance problem, I think the AMP project is doing itself a great disservice. If it positioned itself as an example to be emulated, I would welcome it.
I wish that AMP were being marketed more like a temporary polyfill. And as with any polyfill, I look forward to the day when AMP is no longer necesssary.
I want AMP to become extinct. I genuinely think that the Google AMP team should share that wish.
Friday, September 22nd, 2017
- the early era: ~1996 – 2004,
- the jQuery era: ~2004 – 2010,
- the Single Page App era: ~2010 - 2014, and
- the modern era: ~2014 - present.
Thursday, July 20th, 2017
Friday, July 14th, 2017
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:
Wednesday, May 31st, 2017
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!
Friday, May 26th, 2017
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!
Sunday, February 12th, 2017
A new media query that will help prevent you making your users hurl.
Friday, November 25th, 2016
It reminds me of the old jQuery philosophy: find something and do stuff to it.
Tuesday, August 9th, 2016
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
Sunday, June 12th, 2016
Thank you, jQuery
I also did a bit of spring cleaning, refactoring some CSS. The site dates to 2008 so there’s plenty in there that I would do very differently today. Still, considering the age of the code, I wasn’t cursing my past self too much.
querySelectorAll, and objects like
Of course, the reason why half of those handy helpers exist is because of jQuery. Certainly in the case of
jQuery turned ten years old this year, and jQuery version 3.0 was just released. Congratulations, jQuery! You have served the web well.
Monday, March 7th, 2016
Tuesday, July 21st, 2015
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.
Tuesday, April 7th, 2015
This is a fascinating bit of web archeology: John has annotated the code from one of the earliest versions of jQuery.
Wednesday, December 17th, 2014
You Don’t Need jQuery! – Free yourself from the chains of jQuery by embracing and understanding the modern Web API and discovering various directed libraries to help you fill in the gaps.
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.
Saturday, October 4th, 2014