Tags: jquery

55

sparkline

Sunday, September 9th, 2018

Removing jQuery from GitHub.com frontend | GitHub Engineering

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).

Sunday, June 3rd, 2018

AMPstinction

I’ve come to believe that the goal of any good framework should be to make itself unnecessary.

Brian said it explicitly of his PhoneGap project:

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.

jQuery is the classic example of this. There’s very little reason to use jQuery these days because you can accomplish so much with browser-native JavaScript. But the reason why you can accomplish so much without jQuery is because of jQuery. I don’t think we would have 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:

  1. Performance! Something must be done!
  2. AMP is something.
  3. 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

CloseBrace | A Brief, Incomplete History of JavaScript

Another deep dive into web history, this time on JavaScript. The timeline of JS on the web is retroactively broken down into four eras:

  • the early era: ~1996 – 2004,
  • the jQuery era: ~2004 – 2010,
  • the Single Page App era: ~2010 - 2014, and
  • the modern era: ~2014 - present.

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.

Friday, July 14th, 2017

(Now More Than Ever) You Might Not Need jQuery | CSS-Tricks

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()

Friday, May 26th, 2017

traintimes.org.uk performance notes

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, June 12th, 2016

Thank you, jQuery

I turned Huffduffer into a progressive web app recently. It was already running on HTTPS so I didn’t have much to do. One manifest file and one basic Service Worker did the trick.

Getting the 'add to home screen' prompt for https://huffduffer.com/ on Android Chrome.

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.

After that, I decided to refactor the JavaScript too. There, I had a clear goal: could I remove the dependency on jQuery?

It turned out to be pretty straightforward. I was able to bring my total JavaScript file size down to 3K (gzipped). Pretty much everything I was doing in jQuery could be just as easily accomplished with DOM methods like addEventListener and querySelectorAll, and objects like XMLHttpRequest and classList.

Of course, the reason why half of those handy helpers exist is because of jQuery. Certainly in the case of querySelector and querySelectorAll, jQuery blazed a trail for browsers and standards bodies to pave. In some cases, like animation, the jQuery-led solutions ended up in CSS instead of JavaScript, but the story was the same: developers used the heck of jQuery and browser makers paid attention to that. This is something that Jack spoke about at Render Conf a little while back.

Brian once said of PhoneGap that its ultimate purpose is to cease to exist. I think of jQuery in a similar way.

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

A Year Without jQuery

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.

Tuesday, July 21st, 2015

You might not need jQuery plugins

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

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

JS Parse and Execution Time - TimKadlec.com

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.

Tuesday, July 1st, 2014

Learn JavaScript & jQuery - a book about interactive front-end web development

This looks like it could be a great book for anyone looking to get starting with JavaScript.

Thursday, January 30th, 2014

You Might Not Need jQuery

A handy resource if you’re used to using jQuery for everything but you want to try going JavaScript commando.

Don’t get me wrong: jQuery is great, but for a lot of projects, you might not need 90% of the functionality it provides. So try starting with vanilla JS and only pulling in jQuery if and when you need it.

Thursday, January 16th, 2014

A Dive Into Plain JavaScript

A nice introduction to writing vanilla JavaScript, especially if you’re used to using jQuery.

Friday, April 26th, 2013

I know jQuery. Now what?

A terrific piece by Remy—based on a talk he gave—on when he uses jQuery and, more importantly, when he doesn’t. His experiences and conclusions pretty much mirror my own, but of course Remy is far more thoughtful and smart than I.

Really good stuff.

Wednesday, January 16th, 2013

Implementing off-canvas navigation for a responsive website by David Bushell

This off-canvas demo is a great practical example of progressive enhancement from David. It’s also a lesson in why over-reliance on jQuery can sometimes be problematic.

Thursday, November 1st, 2012

Trimming the Fat — Paul Robert Lloyd

A great in-depth description by Paul of how he optimised his site. More of this please!

Wednesday, October 17th, 2012

digitalBush » Masked Input Plugin

This looks like a handy way of enhancing forms to have input masks (Luke W. would approve). Right now it’s a jQuery plug-in but I’m sure someone as smart as you would be able to create a standalone version, right?

Thursday, September 20th, 2012

Responsive Measure: A jQuery plugin for responsive typography

Here’s something that Josh debuted at Smashing Conference: a script for responsive designs to adjust font-sizes based on a desired line-length.

Inevitably, it’s a jQuery plugin but I’m sure somebody could fork it to create a standalone version (hint, hint).

Wednesday, March 21st, 2012

Kicksend/mailcheck · GitHub

A handy little script that attempts to check email inputs for misspelled domain names. I’m pretty sure it doesn’t need to be written as a jQuery pug-in, though: anyone want to fork it and create a non-jQuery version too?