Welcome to Season 2 of The Drunken UX Podcast! We’re thrilled to have you back, and we kick the season off by having a discussion about the value in learning jQuery today, and what the future looks like for the library in your development.

Followup Resources


Once you get the clap one time, that’s all you need?


You learned your lesson. No more clap.

And I can click to my heart’s content after that.

intro music

Well rise and shine everybody! You are listening to the Drunken UX Podcast, and we are kicking off season two over here, on – well I don’t know, in my office? I was about to say, you know, out here in podcast land, whatever. I’m your host, Michael Fienen, and with me on the other microphone is your friend, and mine, the late, great Aaron Hill.

I’m not, I’m not – well I am always late. Hello! We need to sample that air horn sound *imitates air horn* right at the beginning.

Why do you – why do you hate me, so much?

*laughing* I hear that a lot!

We’ve worked so hard to get so far into this show, and become popular and you just want to drive everybody away. Oh my lord.

Maybe like a vuvuzela?

Vuvu- I don’t know. What?! Venezuela?

No, no, no – vuvuzela! That was the thing, at the Olympics the one year? Everyone had one, you like whip it around in the air and it sounds like droning bees.

Uh, I hate to tell you this, but I’m wearing pants I can’t do that right now. That’s a whole other show.

Look it up – vuvuzela.

I’m not gonna do that. Folks! If you want to follow along with us all the places, be sure to check us out on the Facebook or Twitter, we are at /drunkenux, on Instagram at /drunkenuxpodcast or you can hop into Slack with us and have a chat anytime. Give us some thoughts, suggest a show topic, or whatever the case may be – go to drunkenux.com/slack and track us down any of the ways that you feel like.


It’s Drunken UX Podcast time! That means only one other thing –

I bought a bottle of – okay, I have to backpedal here – Tanqueray is my favorite gin. It’s a family choice thing, and I usually get just the regular, run of the mill, Tanqueray, green bottle stuff. But I picked up a bottle of the Tanqueray number 10, just to try it out, and I gotta say it does taste different. I was expecting it to be like – oh, it seems like it tastes different because I paid more for it, but it actually does taste a bit cleaner and crisper, so I’ve got that in it with some tonic. It’s green and red, like, seasonal.

I feel like that is the sort of gin I should probably try, because I don’t like gin.


But – I don’t like gin. And so I have no real desire to hunt out a better gin, you know what I mean?

Yeah, it’s – I like it. The juniper flavor throws people off sometimes. And I suppose maybe that’s an acquired taste, like learning to like coffee or something.

Yeah. I think where you are in your life the first time you experience it, is a determining factor.

I will say though, like if you drink it by itself it’s – I mean, you can – but if you balance it with a good bit of tonic, the two of them cancel the bitterness out of each other. Anyways, I know you are drinking something special, and we should tell everyone.

Yes. I ended the season special, I’m starting the season special. Every year, a buddy and I, we go in together and we go buy like a really expensive bottle of scotch to enjoy amongst ourselves, and so I’m breaking it out to start the show. We picked up a bottle of the Glenmorangie Signet, which is basically Glenmorangie’s top line bottling. It is a gorgeous highland single malt, the bottle is beautiful, the box is beautiful, the cork on this thing – you pull the cork out of the bottle and, here –

It’s like five pounds, right?

We’ll start it this way, we’ll do a hand-to-heart here, just go –


Yeah the stopper on it is like, cast steel or something, it’s cork but –


the top of it is solid metal and it is hefty. But it is a beautiful, rich, it’s a very sweet highland malt. It’s got a very chocolatey, sort of almost coffee kind of finish to it. Oddly enough I tried it with some water, not as good with water, water actually, I think, makes it a little worse, which I didn’t expect. Usually a little water helps open up your scotch, helps gives you access to some of the lighter flavors and stuff that are in it –


but this, it just didn’t, it just made it taste more alcohol-y.

How do they get the richness, is it like aged in like oak barrels or something?

So with Glenmorangie, they have a whole line. Their normal bottling is a ten year bottle. It’s very good, it’s very mellow, it’s a nice, accessible highland scotch –


They’ve got a series of three more, the Quinta Ruban, The Lasanta and Nectar d’Or which are all aged in different types of casks. So the Quinta Ruban, I believe, is done in port casks, I always get – Quinta Ruban and Lasanta are port and sherry and I can never remember which one is which off the top of my head. But, imparting different, like that deep red wine, that sweet wine, flavor. Nectar d’Or is aged in sauternes? It’s a wine word that I don’t – I think it’s French, I don’t speak French.

Okay. *laughs*

But it’s a beautiful, light, whereas The Lasanta is a very strong, rich, in your face kind of flavor the Nectar d’Or is this beautiful, deliate, sweet flavor. And so they use these different approaches. The Signet is like their top, top end, and it’s a blend from two different whiskeys and they use two different types of barley. At this point I’m reading for anybody at home, I don’t know this off the top of my head, it’s made from “a single estate Cadboll variety, and a malted chocolate barley.”.


And I don’t know what a Cadboll estate barley is, all I know is that when you put the two together it makes fucking incredible scotch.

*laughs* Excellent.

The only thing that makes me sad about it is, it is the kind of thing that you enjoy a glass of, and then you put the bottle up for a while because –

Right, right.

it’s not, I split the cost of this bottle. But I thought it was a beautiful way to kick off the show for the season, and I’ll probably switch to something throughout and for the end of it. But that’s where I’m at because –


only the best for our listeners, although I’m going to drink it on your behalf. And smile the whole time.

That’s a nice looking color right there.

It’s beautiful, I don’t think it’s artificially colored.

Yeah! No, that’s gorgeous. That’s like a nice, light brown.

There are some, like Dalmore, I love Dalmore don’t get me wrong – but like Dalmore actually darkens their scotch, they color it.


And I think – Dalmore is one of them too, depending on where they’re bottled and whatnot they don’t have to disclose that they color it.

That seems like, why would you – I don’t know – it seems silly to –

Because a beautiful, dark scotch just looks really nice you know? So –

But it seems like, if you’re going to have that color you should earn it, you know? Or, I don’t know, it just seems –

Welcome to marketing.

Yeah, yeah. *laughs*

Uh, let’s see here. Well, I want to talk about some stuff, because we are kicking things off. And, I think, what better way to get back into the future than to start looking at the future? And if you run by the show notes, we’ll have a link there to a video that’s on a page, or maybe we’ll just put the video in there – how about we just do that? We’ll just embed the video in the show notes. We can do that, we build websites, we know how to do that!

Yeah! Well they’re embedding it, it’s like a YouTube video, right?

Right yeah, it’s a YouTube video.

So, we’ll totally just do the same thing.

We’ll save you a click. You’re welcome.

Take that Nielsen-Norman group.

Yeah, so the Nielsen-Norman group. Jacob Nielsen put out a video, it’s just a little, two minute video, so it’s a quick watch, it’s nothing super crazy or in depth. And he’s answering the question: ‘Will people be more tech savvy in ten years?. And, I thought it was just a neat little question, and he goes into it very lightly – and the summary is basically no, we won’t be. And I agreed, but I thought the rationale was interesting on it. You know we could explain a little but as to why that is, because it plays into UI, it plays into user experience design, it plays into human-computer interaction. You know, all of this stuff that we’re doing and building, relies on understanding how people react to it, right?

I disagree with him somewhat, but I wanna hear your thoughts on this first.

So my argument comes back this idea of the Model T, and I tell this story, and I‘ve even got it worked in a little bit later in the show. This idea that cars if never advanced, if all we did was drive Model T’s, and all we had, then everybody would be a mechanic. Because the understanding of that car would become a piece of our own culture that, you know, is handed down. There would be no secrets about it, there would be no myth behind how the Model T works.

That was kind of what happened with the Volkswagen right? Like with the Beetle, and the Bus, and the Rabbit, and everything?


Those were built to be accessible and repairable by normal people, so yeah.

But the thing about it is that’s not what happened right? Cars advanced. They became more complicated. We discovered things like automatic transmissions, and air conditioning, and radios. The technology advanced, but the drivers really haven’t.


You know, driving a vehicle still amounts to the same process. Now if you’ve ever driven a Model T, you know driving a Model T is nothing like driving a modern car. But it didn’t take long for us – you know – about 1927-8 in there, we finally kind fell into this modality of like, brake, clutch, gas.


Oh, no. Clutch, brake, gas, right? Yeah. That’s what it is.

*laughs* I mean.

Even I don’t know anymore!

And that has carried through though, all the way up to today, and you know, people can drive cars and we understand them, but we don’t understand what’s going on underneath them, and there are still –

We dont need to.

We don’t need to.

We don’t – right.

But there are also still incredibly bad drivers out there too. You would think that after a century of driving cars, humans would be really good at it, but we aren’t.

Well, I, but I mean that’s sort of – you don’t have to know how the car works to know how to operate it.

Right. In a basic way.


But that’s what we see.

And maybe that’s what he’s saying too.

Yeah that is sort of what they’re getting at, which is: people can use websites. We can use a computer, mostly, you know? People are more capable than they used to be in that area certainly. But, the underlying technology has advanced more quickly than our ability to use it. As a general populous, is kind of, the point there.

I suppose. Alright.

In ten years – the person that is using the website in ten years, is the same person that’s using it today. And their understanding, and ability is not going to change dramatically in that timespan. You know, their knowledge, their muscle memory and things like that will be relatively the same.


All the way down. Think about other technologies, maybe not cars, let’s say VCRs. From VCRs to DVD players, we continued the same basic experience design in them, from the remotes, to play buttons, rewind. We still have the constant of the rewind button. Well, DVDs don’t rewind, but we had to stick to that method, and that tune, because that’s what people knew and understood.


So, there you go – that’s user experience in action. You’re laughing, but you know I’m right!

No, I’m laughing at the *laughs* I knew someone. Okay – I knew someone whose mom got a DVD player, after having a VCR for a very long time. And the first time she rented a DVD from the local video rental place, she asked if she had to rewind the DVD and my friend told her yes, so she did. *laughs*

That’s just mean.

*laughing* I know, that’s why I laughed.

Well, we broke Aaron, so at least we got that going for us.

So I’m gonna give you a counterpoint to that.

You disagree.

I do agree with most of the things you just said and I think that, the operator versus mechanic aspect is definitely a thing. However, okay. So, twenty years ago I was in college. And we had a 100 level class called ‘PCs and their usage’ which – the first lesson in that was how to turn it on. So that was a 100 level, college level, class about how to turn on a computer. And then ten years ago, we have YouTube, like YouTube started existing – right? 2008, right?

YouTube. 2006, I believe.

Okay, well roughly 2008.


So ten years ago we had YouTube, and now school curricula. My son’s middle school curriculum, they have a regular class that teaches the kids how to do code through the San Francisco coding program, which we mentioned in the previous episode – or two episodes ago, and – I think that learning some of the mechanics, just to extend that analogy, is becoming a little more widespread, and I think that we can make some more assumptions about our user base. Although, I guess it also depends on what Jacob Nielsen like what users, what demographics he‘s referring to, because –

He was talking, in a very broad general sense.

Well, in ten years kids who are eight years old right now are gonna be adults. They’ll be 18, they’ll be going into college and I – I guarantee that – well, I can’t guarantee, but I have a very strong suspicion that those kids, in ten years from now, will have far more tech savviness than they do now, or ten years ago, or twenty years ago. I mean, partly because the ability to transfer knowledge is so much faster and easier and more accessible. You have Khan Academy, you have YouTube, you have all these different online e-learning courses that middle schoolers and high schoolers can go and access on their own for free. And so like the ability to learn stuff about tech and about what is going on under the hood, so to speak, is going to be a lot easier.

I think though like what he’s arguing is not so much that the world in ten years won’t have some radical differences, because I agree i think you know, everything you say is right –


that kids are learning things at different times, in different ways than what you and I certainly did or whatnot, but that world is not going to be radically different. And the way in which that is accomplished –


Won’t be.

Won’t it? Ten years from now? I mean, like ten years from now – think about it. We already have the capability to do VR using Oculus Rift and the Vive? Right? And the other one?

I have PSVR now, I got it for Christmas. I’m sorry, I gave it to my wife for Christmas –

*laughing* Excellent.

I happen to have used it a lot more.

*laughs* So like, these are already like, consumer level electronics, in ten years I imagine it will be like what smartphones are now, where it’s just sort of something that – or like what flat screen TVs are, it just becomes more ubiquitous. And so the way we interface with computers might be completely different. I don’t know that, I guess maybe I’m circling back to what your conclusion you had, that maybe the tech savviness is irrelevant. Like, do we need to design things any differently?

Right. Here’s, I think, maybe the perfect analogy because it’s one that goes back, I don’t know, what fifty years?


The keyboard. We’ve had the ability to not have keyboards for a decade and a half?


Laser project something onto a flat surface?


Voice interaction, voice to text. Or – if nothing else – better keyboard designs. And yet, by and large, the keyboard has never changed.

We’re still using QWERTY.

Yeah, you know, mine is a little curved with a cutout in the middle and the got rid of the cord, but it’s still a keyboard.


And I think that’s, you know, there’s this grounded nature in terms of learning and things like that. And I had fun with a talk about this several years back, about the way people learned and how it applied to online education at universities. and the thing is technology doesn’t change the way people learn. It changes how they can learn.


And what they can learn. But the way in which we learn as a species doesn’t flex with that. And there certainly –

I can agree with that.

Like yes, we can get access to all of the stuff on YT, and Wikipedia, and Khan Academy and all these places.


But there is an upper limit to how much you can consume, and process, and retain.


That has no bearing on technology at al, and I think that’s where this idea of – in the end – our tech savviness does have an upper threshold a little bit because we can’t g pout ad completely revolutionize things in ten years. Because you have to cycle out generations for that to actually happen.

Yeah. I think that we definitely saw a huge acceleration in tech savviness between 1998 and 2008, for example. You know, computer literacy, in general, became a lot more prevalent as the internet became more prevalent and because there was more of a reason for people to want to learn how to use it. And I think the same thing in the last ten years too.

And think about how part of that happened too. Like think about early IOS design and the way it was influenced by skeuomorphism –

Right. Yeah.

And you know, part of the way it succeeded is by making its ui translate what we knew in the analog.

You know, honestly, like, flipping this on its head, I think that if we, as developers and designers, are really like doing our job and pushing the envelope on this, I think that users should become less tech savvy in ten years. Because they’re – well they should have, in the same way that – going back to the Volkswagen analogy – in the 60’s, you know, people – there was a reason to learn how to like, you know, fix your own carburetor or like, take care of minor issues, you know with your oil changing and small spark plug changes, and all that other stuff. But we don’t have to do that anymore! Because cars are more resilient and, well also more complicated, but we just don’t have to do it. So we know less about mechanics.

But when they fail, they fail spectacularly!

Oh, yeah! *laughs*

Well, I look at Tesla, Tesla’s a good example of that right?

They literally explode.

By and large, you know, they’re super great, they do a ton of stuff. Their driver autopilot stuff is incredibly good. But, boy when it fails, it fails. That kinda thing. So let us know what you think. What do you think tech savviness will look like in ten years? I’d be interested to hear. I love this sort of future think stuff, and you know, predicting what things will be like, because you know the more they chang, the more they stay the same. And I think we’re always surprised sometimes, at how much Star Trek we have and yet, how little of it we have, all at the same time.

You mentioned Star Trek, if you look at the bridge there, how many of those people do you think would know how to fix the holodeck, if something went wrong? Pretty much the engineering team, right? Everyone else is just gonna be like ‘Uuuhh.’.

Barclay could do it. La Forge, of course. Data. Wes, I think Wes could pull it off.

Maybe. Yeah.


*laughs* Because, reasons.

Anyway, so today’s topic, kicking off the season, speaking of looking ahead – to an extent.


We want to tackle the question – and we are not the first to get here, we won’t be the last, but it’s a fun conversation nonetheless – of should you be taking the time to learn jQuery?


And I think this is a take on ‘the X is dead, long live X’ –


type story. And we all hate it.

I regularly see those on Quora.com and it’s always like, “Is blank dead”, the ones I get notified for, is usually like, “Is Ruby dead?” or “Is Rails dead?” or worse “Now that Rails is dead, what will -” and it’s like… the fuck? *laughs*

I mean, it’s understandable because technology has a life cycle –


the things we use, and this will come up again later, but Flash is a good example, of something that came up, felt super useful, people thought that this was the way of the web. Flash was gonna be how the interaction layer took place.


And then, it didn’t. *laughs*

But yet, people are still learning and using C and C++. So.

It has use outside of the web, though.

I just mean, as far as technology goes, just because something is old doesn’t mean that it’s going to become obsolete, and just because something is new, doesn’t mean that it’s going to be around forever.

Yeah. So, with jQuery – here’s your little bit of a history lesson, especially for folks who maybe aren’t as familiar with it – jQuery came out, it’s very much, like what we would use as a CSS or a responsive framework today. These Javascript libraries, they were this way to take and abstract and simplify techniques that we used in Javascript to help – this is gonna sound fluffy, but – to democratize, functionality. jQuery, was sort of the start of this idea of, let’s take this mysterious thing called Javascript and make it easy and make it do a lot of stuff for people. And it was really, I think it was one of the first big ones, now they may have gotten beaten to the punch by some of them, but they definitely got the gas – so to speak.


And so they took, and combined, all these things in the one place. Kind of like the way a library does. So now, all of a sudden you could go include one file, and with this one thing you could do everything from domin-dom – man. Episode number one, season two, and I already can’t talk – DOM manipulation, you could do Ajax, you could do animations, you could do interactions, you could do all this stuff and you only needed one thing to do it. You weren’t including a different file for everything. It was one deal that you could go get and download that was kept up to date. And that, was a full 12 years ago now.


Not old enough to vote, but it’s getting there.

So, the same year as YouTube then? Wow.

I think so.

I didn’t realize that they were contemporary, that’s interesting.

Everything happened in 2006.


Just everything.

Actually, yeah.

I mean, honestly if you were to like, draw out, sort of the ages of internet development, right there between that 2006-08 period was a big transitional period into the sort of web we have now.


And ultimately, jQuery won the war. It’s the one that’s here, it’s the one we use. There are tons of them though, that were out there.

I remember the name that I was trying to think of earlier – before the show, we were talking about this – Scriptaculous.


Using Prototype. That’s the one I was trying to think of.

And I remember the domain, it was like script.aculo.us.

Yes! Yeah, yeah. So, it’s still up.

Oh yeah. I’m sure it’s probably not gone.


Most of them aren’t. Mootoo – ugh I still can’t talk – MooTools is also still around. Now of course YUI, the Yahoo UI library is, I think, dead, because of Yahoo, but YUI was one. xJS was another, which I think is actually still around too.

I remember that one.

Yeah it was, it had this very application way of thinking about if the iFrame worked in interactions –


that just very much didn’t age well.

It – yeah.

And a lot of these, some of them were kind of competitors, throughout there jQTouch. jQTouch was the Javascript library that was designed to emulate iOS for mobile devices.

Right, and then there was jQuery Mobile, or jQ Mobile.

Right. Same thing. So, it started as jQTouch, and was – it needed jQuery, but it was its own thing, maintained by somebody entirely different.

That wasn’t-?

And then jQuery just absorbed it and called it jQuery Mobile.

Okay, okay. I remember using jQuery mobile for a, this is prior to us using Bootstrap, for a site that we had to have mobile licensing for. It was pretty good!

I launched *something* State’s very first mobile website using jQuery Mobile.


I think, if I remember right, we were the first university in Kansas to have a mobile website.


I’m pretty proud of that. And it was good, it looked nice, it worked well. It was what it was for the time.


Today, it would be terrible, but you know it followed that same pattern of iOS, we’re talking 2008, 2009, maybe? The iPhone came out in 07, we’re still like super early in this idea of a mobile web. And so everybody’s answer to web development was just ‘Make it look like it does on iOS.’.


‘Cause there was no competition! Apple, there was nobody, at that point Android didn’t exist, you had Blackberry.

Are they still around? Blackberry?

Yeah, didn’t they just release that phone that like, was awful?

Which one?

I think there was just a new Blackberry. It was bad. That’s all I remember.


So at any rate though, jQuery, they come through, they’ve got all these guys. And that’s not to say now – xJS wasn’t great, but Scriptaculous was a relatively good library.

There was Dojo too.

Dojo’s another one. Dojo I would group in with what we’re going to be talking about, because Dojo also had a lot of backend stuff.

Mm, okay.

One of Dojo’s big selling things was your ability to take Java classes from a server side piece –


and expose them to Javascript. And be able to use them from Dojo.


So it made it kind of a frontend/backend type thing.

Did you have to use Struts in the backend, or Tomcat, something?

Yeah. You had to have Tomcat, or any kind of VM type – or not VM – Java –

Java thing.

Thing. The word that I’m looking for, that isn’t coming out of my mouth.

Java VM? JVM?

JVM, yeah! Literally Java VM, and I could not get the acronym ‘JVM’, to come out of my mouth. So there you go. We are having a rough start to this season, let’s go. But that was the thing. All of these competitors, they were all frontend, because that’s the only way we thought about web development at that point. All of these resources were designed to help you, strictly on the frontend.


Like, I say, Scriptaculous was good, and MooTools was good and jQuery just had the force of will and the robustness –

Why did they win? What was the watershed moment for them? Was it they got adopted by some big players, arbitrarily, and then it just sort of rolled out from there?

I don’t have an answer, my speculation to that would be A: WordPress –


WordPress started including it as a default part of their backend, and through the registered scripts area. And jQuery UI.


Remember jQuery had that really, and it may still be out there, I’m sure. jQuery UI was an extra package that you could load that had all of these extra elements. Stuff you didn’t always need, like calendar pickers, and other animations, and tabs –

And you had to select them from a big checklist, which things do you want.

Right. And you could roll your own jQuery that way. It would give you a customized download with just those bits and pieces that you needed.

I do remember doing that! That was a cool feature that they had.

Yeah. It got cumbersome after, you know, from a maintenance standpoint because then anytime they updated you had to redo your stuff –


Those things combined, gave it the desirability, and market share that just kept it going, basically.

Yeah. I ask that mainly because, if we think about, we’re talking about the future of jQuery, and I think that if we understand how jQuery won, we might also understand how it might eventually be supplanted by something else. Like what things to look for, on that front.

Take that deep thinking and get off my show! This is not the place for that. You are not drinking enough yet, sir.

Ugh, I do need to refill. *laughs*

What it comes down to is jQuery just had a really great kitchen sink product.


I mean anything you needed to do with Javascript, jQuery basically was able to empower. Whether through the core library or the UI framework.


Plus, the plugin framework. Which, that’s a whole other part of the –

That was probably a big part of it too, the extensibility.

Being able to just drop in, yeah, you had something custom you could just write a plugin and just drop it in there, and tie it straight into your jQuery set up.


And I’m sure, I didn’t use Scriptaculous enough, a very very cursory level is all I ever used it. I’m sure I had something else along those lines, but jQuery really marketed that piece of it.

Well, Scriptaculous was built off the Prototype framework. And the Prototype framework was very comparable. I think Prototype and jQuery were like the last holdouts. I remember seeing those two – because Prototype was the one that I was learning and then I was like ‘Alright, I guess I’ll learn jQuery, ugh.’. *laughs*

So, today, jQuery is basically used by 74% of websites.


So the –

In the show notes we have a link to an article with a graph on this, but it’s a power law distribution. So like jQuery, like 74%, but then like the next one is a fraction of that.

Yeah, so, and that’s a lot. When you think about, what is on all websites. There aren’t a lot of things out there, like when we talk about WordPress, WordPress is the CMS that drives the internet. It still only has 30% of the market share. And yet here we are with jQuery, out here dominating 74% of websites. Because it’s just there, right? Everything just includes it at this point.

Actually, on one of the show note links, it says that as of 2017 jQuery is 83% library distribution, jQuery UI is in 22%, Modernizer in 16%, Bootstrap in 13% and everything else is 11%, then 8% and 4% and the numbers go down.

A lot of those numbers you could take with a grain of salt –

MooTools has 1.8% still!

All of these things, they’re scraping websites, looking through archives and things like that –


and trying to identify stuff in the code. So there’s gonna be, depending on which measurement tool you look at, or whatever, you’ll get different notes. But the broad stroke is pretty much the same though, which is that – jQuery is everywhere –


So we’re going to spoil the episode for you here real fast, that should you learn jQuery? The answer is ‘Yes.’.


Now, I‘m gonna put some context to that here in a little bit. To act like we shouldn’t know how to use a library that’s used on ¾ of all websites, that’s just a stupid thing to say.

So, like, when we say ‘Should you learn jQuery?’ it doesn’t mean like ‘Should you learn jQuery to the point where you’re writing your own extensions –


and where you’re, like, doing really deep, down stuff.’. Like, you can learn everything you need to know about jQuery in about a week.

Easily. Yeah.

So, yes, you should spend a week learning jQuery, so you’re at least literate in it, and can do basic stuff in it.

Yeah, that is a good point. We aren’t saying go out and be the guy, the go to expert –


But, functional – you need to be functional in it.

We’re not saying to build your career on learning jQuery, but like, you should – if you don’t know jQuery, expect that you’re going to have to learn it at some point. So maybe it’s not ‘Should you learn jQuery?’ it’s like ‘Are you going to have to learn jQuery at some point?’ and the answer will definitely be yes. *laughs*

The funny thing is, in these tools and their breakdown they also are able to pick out which versions of jQuery are in use. Because usually, every jQuery file has a version number included in a comment, or in the filename. And they found that only 6.4% of websites had jQuery 3 and up on them, which was –


real interesting, because it shows this picture of what happens in a system like, WordPress let’s say, where the sites update and when a minor release comes out, your CMS updates and you’re just there. Things like jQuery don’t do that, you have to manually go out there and make sure you’re updating your libraries. And people don’t do that, basically, is what that’s telling you. And I don’t know what, when you add in jQuery 2 to that, I don’t know how high up that number goes, but it’s not much, I mean.

The largest share of all jQuery versions, as of 2017, is 1.12. So we’re up to version 3, version 1.12 has 21.37% share as of 2017.

Like looking back and seeing IE –

Two major versions. Yeah! For real, or IE 6, right?

The thing, and the reason why – to revisit this question of ‘Why did jQuery win the war?’ – this is kind of why too. You can still run a website on these old versions, still have that code out there and it runs perfectly well.


It’s a very functional, very resilient framework in that way.


Which is a credit to it, and part of what makes it so useful. It’s one of those ‘If it ain’t broke, don’t fix it’, you know, if your sites aren’t going down because the latest version of Chrome came out. If you’re not throwing errors everywhere in your console, then most people don’t even about keeping up with something like that.

And really, it’s – there’s not a whole lot of – I don’t want to say there’s not innovation happening, there isn’t a lot of need to add new stuff, if you’re not already using it, right?


And, one of the developers from jQuery has said that in the newer versions, most of what they do is remove stuff. So they’re taking things out, not adding new things. So if you have a version that works for you, and it doesn’t cause any problems, there isn’t a whole lot of security threat potential there, because it’s all frontend. You know, like why would you need to upgrade at all?

I mean, your biggest threat potentially, can come in the area of you know, if you load it over a CDN for instance –


And somebody happens to be able to poison the CDN or something like that.


That’s ultimately one of the biggest threats to not updating that kind of stuff. It is a very, and I’m not, I don’t want anybody to take that as advice to not worry about updating because obviously that’s terrible advice. But, there is a certain resiliency there, that you can get away with a whole lot more. It just doesn’t create the same kinds of, you know the threat model is very different by not updating in those cases. And most of it, like you just said, is about efficiency, it’s about refactoring. Things like that. Even I, I’m sitting here trying to think of what was the last big thing jQuery took out, and I honestly can’t tell you.


Because I’m not a changelog hound for it, so I’m not like there reading every single thing.

I’m willing to bet that the majority of the reason people, you know if the people are using 1.12, you had Ajax, you had, like basic UI effects, and those haven’t changed much. So if that’s all you needed it for – especially if you just needed it for basic Ajax stuff – jQuery is a nice wrapper for that. And I mean, if it’s working for you, why change?

And you mentioned the power law distribution of just sites using jQuery –


I bet, if you could look at that in terms of how they were using it-


I think you would see something similar in that most sites are probably using it for a slideshow.


And, it turns into a real long tail from there in terms of like, the number of people who are using jQuery and developing super dynamic, complex websites with it, and running all of these different animations and things like that. That list is pretty short, in the grand scheme.

Or they’re installing it as an afterthought, because the thing that they actually wanted, such as the slideshow you mentioned, whatever it may be, just happens to also have jQuery with it and they didn’t bother to think ‘I’m going to download jQuery’, they just thought ‘Oh these are the files I need to put in this folder and then I need to do this line of code and then the thing just works, yay!’

Yeah. Now, part of the reason why, I think, why this discussion has changed is – I think we’re seeing it more anyway – whether that’s if you go to Quora, or whatever you’re watching Twitter or these places, this idea that the war itself has changed. jQuery was originally in this war with the other frontend frameworks, these were frontend frameworks that were trying to do the same things in most cases. They filled the same, we’ve had this discussion before, “nitch”? Niche? Niche? Is that the one I should say?


Nietzsche. I was about to say – I’m going to take a page from your book and I’m just going to call it “nīche”.

“Nīche”. *laughs*

And that’s just the way, I mean, my own pronunciation.

That is now how I, too will also pronounce it.


It will now be “nīche” forever. *laughs*

Now jQuery is facing this pushback from the new frameworks –


and these are, we’ll call them ‘The Node Bunch’, whether that’s React or Angular Redux, these Javascript frameworks – they’re still Javascript frameworks – and they absolutely take the place of a lot of jQuery’s functionality. Especially when it comes to data handling, and DOM manipulation and things like that, but, and I’m saying this with a word of hedging –


They are largely designed to be frontend and backend components. Because they’re all built around this idea of much more MVC focused development and you see them, the reason, or the places where we’ve seen these come up the most is with the folks building web apps, or single page apps, or things like that. As opposed to a website, a blog.


And I think that makes a big difference, though it doesn’t change the fact that people keep lumping them all together.

Yeah. I mean, in those peoples’ defense though, the speed at which the Javascript community moves makes ‘Move fast, break stuff.’ even say ‘Whoa, wait a minute!’ *laughs*

The thing here is, when you look at these frameworks, it’s one of those like they aren’t exclusive to each other. You could build a React application that absolutely uses jQuery, like these things are not mutually exclusive. Though I think most folks would kind of turn their nose up at that thought. *laughs*


But that doesn’t mean you can’t do it, you just probably shouldn’t.

Eh, I don’t know. They wouldn’t occupy the same namespace, so I guess you could.


Everything in jQuery is all under either jQuery or a dollar sign ($) namespace, so – I don’t know much React, but I know some, and of what I know I don’t think they would collide. But I also don’t know why you would do that though!


Because I think React has all of that functionality baked in already.

Yeah, the overlap is part of what makes it a little weird. Vue is probably the closest, because you could absolutely use Vue as a frontend only Javascript library. Again, most people don’t, because most people that understand and are interested in learning these things, are people that are building something with a server side component. I may be wrong on that, I’m totally speaking out of my sphere of influence and what I’ve seen and heard.


But, I definitely think they occupy different resource space. And the thing that makes me feel weird about it is, even if we say, if we distill this down to Vue – visit the show notes, we’ll have some articles there about what the difference between what Vue and jQuery are and we’ll get more into all that – but at the end of the day, making the argument that you shouldn’t learn jQuery because you should learn Vue instead, is sort of bizarre to me. Because you’re basically saying ‘Don’t learn that library, learn this library.’

Learn this library. *laughs*

And ultimately, you’re – yeah, you’re just trading off, you’re not gaining –


you’re not getting ahead of anything because jQuery itself, isn’t necessarily broken. And it’s not –

Well, the only thing you’re gaining is a smaller community of support, right? Like jQuery has been around for over a decade, and –

I know that folks will say that Vue is simpler, and that you can do things quicker in it. And that’s entirely true, depending on your use case.


But it’s not true in every use case, and I think there is still a higher barrier to entry for those, than what you have with jQuery because even at the most basic levels, most tutorials, and – like you were saying – the community support is not necessarily geared towards and frontend only thought process, which is kind of what jQuery does.


So, let’s switch gears. I realize I say ‘so’ a lot when I’m changing gears, I need to fix that. Taking notes here. All that being said, there are legitimate reasons to not use jQuery. And we need to go over some of those before we talk about why you should learn it. Because if you fall into some of these categories, you may honestly think about not using it. But I want to dispel one of the big myths, which is that jQuery is too big. We’ve seen this with CSS, we see it with Javascript, you know, this argument that you need to make your page smaller, and your payload as tiny as possible, and it’s a great goal. But people act like jQuery is like this 300 – 400 kilobyte package that takes up a ton of room. And it will, if you’re using the uncompressed, you know, full shebang. But the minified version is only 85 kilobytes. *laughs*

Yeah. Didn’t we mention in an episode about, actually this is going way back, season one, episode like one or two we were talking about embedded video, and then about how – you know the average size of the average website, is hundreds of kilobytes. I’m sure that jQuery has a notable impact on that, or a little portion of that, but 85 kilobytes is nothing. *laughs*

Yeah. You can offset that, by optimizing one of your images, that you maybe didn’t catch.

Right. I mean, you probably have images that are bigger than 85 kilobytes.

And if you are serving from, you know, most any server that’s using gzip, that 85 kilobytes minified file is only about 28 kilobytes gzipped. So, jQuery – there are reasons to not use jQuery – but arguing that it’s a space issue, I don’t think is valid.


Unless you are in some situation, where you really are trying to run as absolutely lean as humanly possible –

But, if that’s the situation though, then you should be writing, like completely rolling your own Javascript.

Right, absolutely –


If you’re trading that off for Vue then, because here’s the thing, if you wanna use Vue – go for it – same size.

Yeah. Actually, I think, if you are of the presence of mind to realize ‘I need to be running as lean as possible, with as small load time as possible.’ you probably already know whether or not you should be using jQuery. Yeah.

The size argument, you know, I get it. It’s – you can make it. But if it’s a trade off issue, or you honestly think that 85 kilobytes is going to make or break you, then you have other questions to tackle, I guess at the point. So, one area where it is a perfectly good valid reason to think about not using jQuery is if you’re doing Javascript development, in a test driven environment. Because jQuery creates a dependency tree, which can influence the way you approach testing.


So, for instance, right now I’ve sort of been embracing Cypress. It’s very straightforward, very easy, it does client level integration testing, so it’s literally testing the way things are being put out to the user. And that works pretty seamlessly –


because it’s working through the browser, and so you’re getting, that same level of experience at that point.

Is Cypress similar to Selenium, or one of those?

Yes. The answer is yes.


I have not used Selenium to any degree, so I don’t, I couldn’t –

But it’s that kind of thing.

Yeah, yeah. Write your automated tests, and it will go through, you can have it click stuff and it uses the assertion the same assertion library – Chai assertion. So if you use a test framework, and you’re familiar with Chai, it’s the same ‘such and such expects length 3’ or whatever. I see a menu, I expect to see these links that have YouTube listed or something.


But that all works really well because there isn’t a lot that it has to do on its own. It’s interpreting –


as opposed to, like unit level testing.


So, in those situations – and I can’t, for the life of me remember, the test suite we were looking at originally. But I was trying to make it work with some of the code we wrote, which was jQuery based. And, I could not, for the life of me, in our build process get it to know that jQuery existed. Because the jQuery included client side, it wasn’t included in the build process.

Ohhh. So it wasn’t executing it in the – I see.

Right. And, because unit tests, generally, only look at a very small piece of your code.


And it can be very blind to all of the other things out of necessity, because in theory you’re trying to make very small pieces that function.


But that makes jQuery very difficult in those environments I think.

On the Rails side of things, I use the Capybara gem, which is similar to Selenium. It emulates a user interacting with a browser and the ChromeDriver library, or I’m not sure what you call it, it’s a binary, you grab it from Google’s thing –


Kind of. I don’t know what it’s using, but it’s using Chromium engine. And it’s great. We’ve used a couple over the years. We’ve used the webkit one, that’s the default in Capybara, we’ve used Poltergeist, which uses PhantomJS as the Javascript interpreter, and then um – ChromeDriver’s great though, and it has really good Javascript support and it handles a lot of the jQuery stuff pretty well. Every once in a while, you run into an issue with funny stuff, but, generally it does a pretty good job.


So, if you’re doing Rails, you should be using ChromeDriver. I think it’s funny because even the makers of Poltergeist, the Poltergeist library, they said ‘We’re no longer supporting this, you should use ChromeDriver, it’s better.’ *laughs*

Everybody’s abandoning ship for Chrome. But yeah, that idea also lends itself to this idea of if you are trying to write really portable code, it could be useful to not use jQuery. If you want your code to be very encapsulated, and very functional on its own, then avoiding jQuery might be what you want to go after because that’s going to give you that ability to write something that anybody can use and not have to worry about, you know, did I install the other libraries, or do I have jQuery UI on top of it, and things like this.


That can become cumbersome, and it’s that same idea of – the same reason why you unit test code is because you want very small, individually functional, pieces of information.


This is that same thought process, just without the testing pieces.


You want small, encapsulated pieces of self dependent code that doesn’t have to bring in anything else. Otherwise, you end up with just a lot of people all including jQuery over and over again.

*laughs* What could possibly go wrong?

That’s part of why, like WordPress, added in the scripting queueing stuff. Because if three different plugins all enqueue jQuery, it knows it only needs to fire it once.

You know, when I worked at Cornell, we had kind of a skunk works, not a library, but like skunk works PHP we’d written. And I wrote a subscriber pattern thing in PHP that did that. That where you would say ‘This class, or whatever, depends on jQuery, or whatever, these components.; and then when the page rendered, you would take the unique set of dependencies and load them. Because we kept having issues where jQuery would load up more than once. Yeah.

Yeah. There’s a – I think it was just a draft proposal for the http standard that had something along those lines, where you could define in page what pieces of a broader package you needed.

Oh, wow.

But that was quite a while back, it didn’t get very far.

That would have been cool.

But it was cool nonetheless. There’s one other reason why not to use it, and it’s gonna sound silly, but if you’re avoiding learning native code. But that can be a thing.

Wait, wait, wait but to clarify, by native code you mean like just plain old Javascript, right?


Pojis. Pojis? Pogs.

Plain old Javascript.

Pogs. Javascript’s spelled with a ‘g’ – pogs.

And that’s a POJO joke – The thing here is there are a lot of ways, jQuery was designed around this idea of trying to take all this stuff that worked in different ways, and had to be written multiple times, for different browsers, and make it in one thing that you could use, and make that easy. And for a lot of people that’s good enough for whatever it is that they were writing. And if your goal is to do something quickly, without care for the nuance, you just want it to work – which is a perfectly valid thing – if you’re more of a CSS person, or a designer, just writing header.addclass and addclass active, is a really simple, straightforward thing to do. And, you may not be benefitted by taking the time to scrounge over ‘Can I use dot-com?’ and figure out if all of this stuff’s supported, where is it supported, whatever. So there’s definitely a value to that, and that’s nothing to be ashamed of if that’s all you need, and that’s what gets you where you need to be.

On the flipside of that, though, jQuery is a nice, safe haven for those of us that don’t want to have to learn vanilla Javascript. In the show notes, I’m putting a link to a lightning talk called ‘WAT?’ W-A-T. He starts off talking about Ruby, but he goes into talking about a bunch of really funny, weird oddities in Javascript. It’s like five minutes long, it’s totally worth the watch.

Yeah, and there’s nothing wrong with that. I would say that if your career is going to be in frontend development, like deep frontend development, that’s not a good excuse.

Mm. Yeah, you should work on that.

But if you’re just visiting, so to speak, then it’s perfectly reasonable to say ‘You know what, I’m just going to do this the quick way.’. And that’s one of the reasons why it is worth it. Because for a lot of people, jQuery is just like a comfortable set of training wheels. And if you can jump in and do some real quick prototyping in it, which is true with just about any framework, most frameworks if you know it well enough, you could prototype something quickly in. But jQuery has a lot of support, a lot of examples out there. And you can get in and in a few lines, there’s no denying the fact in a lot of cases you can do something in fewer lines of code in jQuery, than if you had to write it out yourself.

This is not going to be an accessible analogy for most people, but for those of you that are Linux users, I kind of find it similar to using Ubuntu versus using Arch Linux, or one of those. Because I use Ubuntu because I don’t want to have to mess with all that bullshit –


I just want it to work. I just want to have an OS that works, I don’t have to think about it, I just want to do the thing on other stuff and not mess with operating system crap.

You have to roll your own operating system.

Right. Arch Linux is way more powerful, I don’t dispute that, but you also have to fuck with the operating system bullshit that I am not interested in.

Tell us how you really feel.

*laughs* If you have the time for it, you do you, boo. But I’m not there for it.

And that goes a long way too, you can’t sometimes just jump into the deep end. And jQuery can be that way of introducing simple concepts to users to get them used to different syntaxes, understand what a callback is, and how it works and what it does, what it takes as arguments and things like that. And you can ease in to some of that.

Did they have the callbacks and the promise thing in jQuery 1.2? I thought that was a relatively recent –

What version number it was, I couldn’t tell you for sure.


That’s one of those things that gets too detailed for my old brain.

I think the callbacks was version 2 and promises were in version –

And for folks that don’t know, a promise is basically part of a code that tells another part of the code, whether or not something happened.


So that it knows to expect something – or asynchronous. That’s the phrase I was trying to dig out of my brain.

Is that also a closure? I always get that –

No, Clojure is a library, isn’t it? Or no, it’s a language.

*laughs* No, no a closure is like a block of code that you pass in –

I’m trying to be funny.

Ugh, these names.

I messed up my own joke. Clojure is an actual language, not a library. Oh my go-, um –

I’ve been out of college too long. *laughs*

I know right. So, these things they lead up to something though, so if you’re using it to simplify concepts and introduce people, the next natural step is that learning jQuery as kind of a simple Javascript, can be that stepping stone to understanding actual native code solutions to things.

Yeah, definitely.

That’s why jQuery existed, that was its whole purpose. And if you can reach back, if you’ve been around long enough to know what it was like writing individual XML http request code –


for Internet Explorer, and for Chrome and for Firefox –


and each one handled it a little bit differently. You had to write it in a very particular way, and check for the existence of things –

Uh huh.

and it was – Ajax was a pain in the ass!

It was, it was. I remember writing XHRs manually and it was a pain in the ass. Totally.

jQuery is the reason that Ajax succeeded, in my opinion.


I don’t think Ajax would have succeeded as a technology, if jQuery had not saved it, basically. Because it came in and just said ‘Oh, you want to do something Ajax-y? Then just use the Ajax method.’ – And gave us the end point, and the data, and we’ll handle all that different –

Oh, man.

which browser it is, which syntax it needs. That was the watershed moment for when people looked at jQuery and went ‘Ohh –


we need this.’

If your use case allows you to use the load method, of the Ajax portion of jQuery, oh man that is so nice. Like $.load and the URL and the destination and node where it’s going loaded.

Now, it’s worth noting that that argument is not as necessary as it used to be. jQuery isn’t –


because things like that have normalized over the years. This need to have a library that deals with all the browser idiosyncrasies, you know, that piece of it is actually filing away. And that’s one reason why these conversations come up.


Do you still need to learn jQuery? It’s because the reason we did it, and the need that was there, that was solving for isn’t the same need that it was ten years ago.


But, that’s okay. You don’t need jQuery for it to be helpful.

So, there’s a link in the show notes for this comment on the jQuery GitHub, where someone was asking ‘What’s the future of this library?.’ Because, looking at your commit history, and your blog posts and everything, has kind of like slowed down to almost – the pulse is very slow. And one of the maintainers for jQuery pointed out they’d just, they are intentionally doing less frequent releases because of a lot of things we’ve discussed already. Like having to upgrade, and also they’re trying to remove things instead of add them. But he did say that, they are roadmapped for, probably Version 4. Quotes, “A complete rewrite using next generation Javascript. This, in turn, requires an update to our build system, because we want to use ES2015…” which is ECMA6, right?

ECMAScript, yeah.

“We need to do this in a way that keeps the final size identical, or smaller than the original.” So they are actively maintaining it. It’s not like this is a dead library or anything.

Well, think of it like PHP –


Right? Anytime somebody steps up, young and is whether it’s on Reddit or Stack Overflow or something, asks ‘Which language should I learn?’, or ‘Should I learn PHP?’. And you always have this group of folks, who are really quick to be like ‘PHP is a terrible language, it’s a dead language, there’s so much better stuff out there to go learn.’

Well, two out of those three things are right. *laughs*

Well, I mean, that’s a ridiculous way to approach learning in general. But even if PHP was not super active, it still is the backbone of the internet at this point.

Oh, yeah!



And, like you were saying, and we’ll revisit this in a second, but this idea that you don’t have to become an expert in it to have it be worth learning. You can learn it at a functional level –


and be fine. And that’s – I’ve seen that with PHP so many times. Folks saying ‘You’re wasting your time learning PHP.’ you know what? People said you were wasting your time learning Java ten years ago, and guess where Java is today? All the same places it always was –


because it has anchored itself into the industry. So, looking ahead, and why the answer to the question of ‘Should you learn jQuery?’ is yes, is if we look ahead five, ten years into the future – and I’m not going to be picky, five year, ten years, whatever. Ten years is probably good, because it ties us back to the start of the show. I said it early, and I’m going to say it again – jQuery isn’t Flash.


And if you’re scared of learning jQuery because you’re worried about it failing – not failing – but going away, being outmoded the way Flash was. Don’t have that concern, because it won’t.

Flash required a lot more, like you could not learn Flash reasonably well in a week. To use Flash in an effective way, it required so much onboarding with that. But jQuery, you could learn how to use it, very functionally, in probably at least 50% of your use cases in just a few hours.

Flash also, at its best, was riddled with serious problems.


From bugs, to accessibility issues, to loading problems across the board. So, we know jQuery isn’t Flash –


And if anybody wants to go deeper into that subject, I’m always happy to. I consider them very different technologies, and I think Flash failed for reasons that are unique to it. That don’t apply to jQuery. That was a funnier joke than I intended it to be. Go me!

*still laughing* There’s just a lot of, there’s a lot –

A lot to unpack?

A lot bundled into that statement. *laughs*

The other side of this is, what the backbone that we’re talking about is – Javascript, right?


All of this, at the end of the day it all comes back to just Javascript.


jQuery is just Javascript. It’s just Javascript that has been written in a smart way, basically.


But what has happened is, Javascript is based on the ECMAScript standard – which has improved every year, and people hear this thrown around – and it’s confusing, and it doesn’t always make sense. As Aaron had just mentioned, if jQuery 4 moves ahead, they want to base it on ES6. It used to be that Javascript got very rare updates, as a language.


You know, as a subject matter. So what we had throughout all of the 2000’s basically, was the same Javascript that we always had. In 2009 there was a huge update to Javascript, an that was when we started this idea of – or no, I’m sorry – 2009 was the last, like, relatively normal –

Last big one.

update to Javascript. It was in 2015, hence the name ES2015, that they came out with this huge update to Javascript, included –

Oh, that was ES6, right?

Yes. ES2015, ES6. Same thing, just different –


‘Cause it was easier, right?


ECMAScript is a versioned language, just like anything else and we’d been on ES5 up to that point.


And, keep in mind that ES5 was what was available when jQuery came out.


So in 2015 by that point jQuery’s been out forever, and now ECMAScript comes out and says ‘Oh, by the way – here is a dump truck of new stuff you can start using now.’


The problem had always been, even though Javascript supported it, that didn’t mean browsers supported it.


And that’s where, if you’re getting into build processes and things like this, and you’re hearing phrases like Babel – that’s another one, is it a long A or a short one, I don’t know – The Babel module, when you were doing a build process and were writing, when somebody says they’re writing their Javascript in ES2015, and they’re using Babel to transpile it. What they’re basically saying is they’re writing in modern Javascript, and using this library to take that and it knows how to rewrite all of those pieces using more Javascript, to reproduce the functionality in different ways, so that it would be backwards compatible. All of this, to say Javascript itself is getting better every year, there’s an ECMAScript update every year in June. It didn’t used to be an annual release cycles until 2015. Which that jQuery’s role definitely changes, because it mans Javascript is capable of improving upon itself in a way that it couldn’t when jQuery came about.


That said, it’s still slow. And while ES2015 has pretty good support across the board, on a browser standpoint, ES2018 doesn’t.


And there will always be some of that to deal with. And I’ll be interested to see what jQuery does to kind of pivot. And it sounds like that’s exactly what they want to do. They want to remain relevant and they want to figure out a way to fix these things, and still provide value with jQuery 4. That’d be an interesting topic to maybe get a dev for, and have a chat about. But at the end of the day with jQuery and Javascript – there’s gonna be a few articles in the show notes – for a lot of you, if you want to start writing jQuery-less Javascript you can easily reproduce a lot of its functionality now using native code.


And that can be more efficient in some cases. You can use just the pieces you need, even if you want to use the same style selectors, there are ways to write a dollar sign parentheses ID label, you know, whatever. And have it behave the exact same way jQuery does. Because that’s all jQuery’s doing. jQuery is just doing that in Javascript, and so you could do that.

I would be really surprised if someone doesn’t write, like, a jQuery lite thing. Where it’s just those basic – just DOM manipulation, and Ajax, and then that’s it. And like, jQuery Lite or whatever they would call it, and just see if that rolls out to all those places that are using jQuery 1.2.

Well if you go to one of the links, it’s called ‘You don’t need jQuery’ it’s from a user called ‘Nefe’, again here I am with not being able to pronounce stuff. But he’s got all of these things that jQuery does, and they’re native Javascript analogs, and so, you could take all of his code and just package it together and use the pieces you want, and that’s basically what you would have, is jQuery Lite.


What we’re gonna need to do –


and this is maybe more of a five year watch, rather than a ten year, is paying attention to what big players are doing.


Because the big news this past year, was that GitHub announced that they had completely removed jQuery from their codebase.

Yeah. That’s amazing.

Yeah, that was a big move on their part.


And they’ve been working towards it for a long time. They weren’t trying to turn the light switch off, they had been over time, chewing it away and taking it out as they improved stuff.

They’re Rails based, yeah. What are they using for their frontend then?

Native code. I think everything is native code for them. I don’t think they’re using any library –

Ah, that makes sense.

There’s no library at this point. And because there’s an article in the show notes, from engineering blog at GitHub and they go into all of this. Like how they kind of strategically approached this, because that’s a big undertaking.

Yeah, sure.

To say you’re going to remove all dependency on a library. That’s another reason why jQuery has held on so well, is because it’s part of a lot of places’ infrastructure.

I mean, if anyone was going to do that though, like GitHub is not surprising.

Oh, sure. Yeah.

Yeah. *laughs*

And they go into depth, like how they approached it, why they did it, what value they’re getting out of it. And a lot of it comes back to some of the stuff we’ve talked about – things like, test driven development, and portable code and things like that. But also storytelling in code, being able to look at code and understand what it’s doing, without a bunch of comments and things like that.


One of jQuery’s strengths is also its weakness, and that by abstracting a lot of stuff away –


you remove context of what’s happening.

That’s a good point.

And, yeah. It’s – if you’re the only person working on something, that’s fine, but if you’re working on a team and people come and go or anything like that. If definitely changes the vernacular that you need to use when you’re writing.

I don’t want to deviate too much on this but, that’s actually a really important thing that I’ve been discovering the past year or two is that – nine times out of ten, I prefer code that’s easy to read, than code that’s clever, or even in some cases, like – fast. If something is – if it runs in 3 milliseconds with this particular version, or the easier to read version runs in 4 or 5 milliseconds, I’ll take the easier to read version most days.


Because if you have to maintain that you’re talking about saving hours of time if something is easier to understand overall.

Right. The other big player that’s gonna be out there to watch is WordPress.

Mhm. Yeah. They do React now, right?

Yeah, it’s that idea of ‘I brought you into this world, I can take you out of it’. They introduced jQuery to 30% of the web, and naturally themes are going to support it for ages beyond now. WordPress isn’t going to take it out of the registered scripts or anything, but they could remove – just like GitHub has – they could remove all of the dependencies in their framework now that they’re moving towards React.

It wouldn’t be a bad idea for them to –

Oh yeah, I don’t think it would be.

that would move more of the stuff in house.


And create less – yeah – I think that would be smart on their part.

And we were saying earlier, like this idea of you can mix and match jQuery and React, that’s a thing you can do. But most people wouldn’t recommend it.

The maintainer from GitHub that I mentioned earlier, who’s maintaining jQuery – another quote from him, he says “jQuery can and does get used alongside robust application building solutions, like Angular and React/Redux. But its main usage probably still lies more within websites, rather than web applications, if I can make that distinction.” And I think that’s probably – if the question for this episode was ‘Should I use jQuery?’ versus ‘Should I learn jQuery?’ then if you’re doing a basic website of some kind and not something that’s framework based, then jQuery’s probably a good consideration.

I think that’s absolutely the distinction, like with WordPress –


A theme, using jQuery is not the same as WordPress using jQuery. WordPress, the backend application, I think within two years, you will see it going exclusively React.

You know what though? WordPress – one of the reasons that WordPress is so nice is because both PHP and jQuery are relatively easy to pick up. I cannot say the same about React. React is not as easy to pick up as PHP and jQuery are.

Oh yeah, no.

I’m saying this, as someone who’s trying to pick up React. *laughs*

Yeah, it’s a different learning curve. It very much is.


And because it takes that idea of what is Javascript and –


turns it a little bit on its head. Because it’s using Typescript and this other stuff that is a variation of ECMA standard.

A lot more pieces involved.

The Javascript landscape – if you want to have a fight with somebody about why javascript is a messy language, there are a lot of perfectly valid cases you could bring up there.

I think it would be likening, saying, learning PHP versus learning WordPress. You can learn serviceable PHP very quickly. Learning WordPress can take a little bit more time. In the same way that you could learn Javascript and, by extension jQuery, quickly, but learning React is going to take a lot more time just because you have to see more of the picture in order to actually use it.

Well, there’s a clock counting down on it.


I mean the reality is, jQuery I think does have a lifespan, like any technology does.


And a lot of it’s gonna come down to exactly what you were just saying with React. React is a denser language, it’s got a sharper learning curve, and the way we approach training new developers moving forward is going to say a lot about how quickly that clock counts down for jQuery. Because, as of right now there’s a lot of safety, sort of, in that world.

But, you know what though? Even if all the maintainers of jQuery decided you know what? We’re done. We’re not gonna maintain this anymore. And no one else decided to pick up the mantel you could still use it.

Oh yeah.

It still works, and it will probably still work five years from now. *laughs* As long as you don’t need anything too modern and complicated, it’s probably fine.

The final thought that I’ll throw out here is simply what we’ve been stressing, which is, at the end of the day, should you learn jQuery? Absolutely. Because –


at some point, you’re gonna have a project, or a tool, or an application or something that you need to maintain. And that something is going to be written by somebody else, who used jQuery.

And stepping back from that even, you’re a web developer – get used to it. You’re going to have to learn a shit ton of languages, and about all kinds of different things, and you’re going to have to learn them at different levels of depth. So, yes, this should be something that’s in your repertoire whether or not you use it all the time.

Yeah. With that, sit back, take a second – we’re gonna take a break, and we’re gonna wrap things up. Folks, thanks for listening to the Drunken UX podcast. It’s season two, baby!

Season two! *laughs*

We’ve already lined up the first three months of shows, and we’re going to be recording –

I had no idea that we would be making a season two episode when we decided to this a year ago.

That’s his way of saying that he wants to quit –


and I’m not gonna let him. If anybody wants to apply for a co-host position, just email us. Folks, we’ve got some exciting stuff coming up. We’ve got some new show concepts that we’re gonna be doing, and we’ve got new topics that are gonna be on the way. All the things, all the special stuff, we’re gonna have fun with it. Got new episodes of Real Time Overview coming out with a new format, Build Process will be coming out in the middle of the month, as always and all of those things. So, we’re happy that you stuck around we hope you have fun with us. And if you have anything, I guess, let us know, right?

Yeah. Connect with us on your favorite social platforms, be it Facebook or Twitter you can find us at /drunkenux or you can find us at drunkenux.com/slack – if that’s your jam, I’ve got 11 Slack channels. Or Slack – sites? Slack instances?



I don’t know what they’re called either.

Yeah. And then also on the Instagiggles, that’s what you called it earlier right? Instagiggles?

I did no such thing. I would never call something Instagiggles.

*laughs* The Instagrams – Instagram/drunkenuxpodcast – make sure you have that last bit on there, that’s where we keep all the flavor.

Otherwise, garsh. I guess all I can tell you is the same thing I tell you all the time because I enjoy it and it makes me laugh, but that’s – folks, keep your personas close and your users closer. Welcome to season two, bye bye!


This episode of The Drunken UX Podcast brought to you by nuCloud.

© 2018 All Rights Reserved