jQuery with Tomasz Łakomy

Links:

• https://www.stedi.com/
• https://cloudash.dev/
• https://egghead.io/q/resources-by-tomasz-lakomy
• https://www.cypress.io/
• https://insidegovuk.blog.gov.uk/2022/08/11/how-and-why-we-removed-jquery-from-gov-uk/
• https://zeptojs.com/
• https://github.com/jquery/sizzle/wiki
• https://www.sitepoint.com/premium/books/jquery-novice-to-ninja-new-kicks-and-tricks/
• https://en.wikipedia.org/wiki/JQuery
• https://trends.builtwith.com/javascript/jQuery
• https://twitter.com/tlakomy

Transcript

Mike: Hello and welcome to episode three of behind the source podcast. I’m Mike street, lead developer and CTO at Liquid Light. Each episode, we invite someone to come and talk about a topic project tool or process. We try not to get too techy, trying to cover the topic for people who don’t know much about it and are looking to find out more. All the previous interviews and podcasts, along with the mailing list, sign up are on the website at behindthesource.co.uk.

Today. I’m joined by Tomasz. Tomasz do you wanna just give a little overview of who you are what you do, any side projects and just sort of a little bit of background of why you are here.

Tomasz: Awesome. Very happy to meet here. So my name is Tomasz Łakomy. As you could probably guess from my terrible accent. Not from the us. I’m from Poznań in Poland, born at raised actually. So currently I’m a, a technical team lead over Stedi. So Stedi is a fully distributed startup, very much into serverless space and we make API for optimizing business integrations.

On top of that, I am also co-founder at clouddash. Clouddash is a AWS desktop client for serverless and cloud engineers. So basically if you are tired of AWS console, you might find it useful. And I, I also have surprising the. Large amount of content online. So I’ve been teaching web development on egghead.io for the last couple of years, and I have close to a 200 small lessons published.

So it’s like between three to five minutes at most. I think my longest lesson is own six minutes long because this is the extent of my attention span. So I don’t record anything longer that I wouldn’t watch myself. And I also do a little bit of blogging and I have habit of posting about jQuery on Twitter.

And I suppose this is the, the topic of the show.

Mike: Yeah. So before we get on to jQuery the lessons that you’ve put online, what kind of, what are they about? Are they just sort of fundamentals of web development or are they a little bit more advanced

Tomasz: well, all of it, I suppose. So I have stuff on, on the react. I have some stuff on CSS. I did my first share of publishing lessons about AWS cloud. So kind of my, my story was that I started my career as a front end developer, roughly, you know, 10 years ago, before I even became a front end developer. I used to do C plus plus at work, which was miserable.

And this that’s why I decided to switch to to front-end. But you know, for the last couple of years I’ve been digging more, more, more, and more. Cloud development stuff. And kind of the idea behind the vast majority of my content was I had to struggle to understand some of those, you know, ideas and frameworks and, you know, basically the entire of cloud computing, because, well, it’s, it’s not trivial.

So I wanted to create an record content that would appear to me when I was learning about this stuff. So the the core audience for, for instance, some of my egghead courses is actually myself a couple of years back

Mike: That’s the best. It’s the best kind of audience. If you could remember what you didn’t know that it that’s always the tricky bit. Isn’t it is that, so before we get into the main topic, which as you mentioned is jQuery I like to ask all our guests, what are you learning at the moment?

What are you looking forward to getting your sort of teeth stuck into what’s what’s new for you at the moment

Tomasz: So I’ve recently switched roles over here at Stedi so I, I will say hired as a front end engineer, but recently I took over Technical team team leader role. So I suppose you could say that I learned to focus to take a step back, to take a higher kind of birds-eye view on some of the things that we are building.

So I’m not going to say that I’ve switched from vs code to Google docs and Gmail because we are not very email heavy, but I guess what I’m thinking is what I’m trying to learn is to how do I do my best in order to make my team more productive and so that we can ship awesome stuff. So it’s it’s a different, different kind of challenge.

This is different, you know, something that you would have to do in your first year. As a software developer, but being able to, as you probably know yourself, also take a step back and have a greater understanding of what we’re building. What are the blockers? How do we get there? Which teams do we need to talk to?

And so on, which is especially challenging because we are a fully distributed company. So to the best of my knowledge, most of my colleagues do not have flex because I’ve never seen those. Like it’s always on zoom, you know the faces and the arms and well that’s.

Mike: Yeah. Yeah. It’s that, that switch from being a developer to a manager is certainly. More challenging than you sort of expect it to be. Um, And the biggest, the biggest thing I found was, although it’s quicker sometimes for you to do it, it’s not the most efficient way you have to sort of let go of things and let other, you know, teach other people to do those things that, so it can free up your time. And it’s, yeah, it’s all about the sort of long term gains

Tomasz: luckily, I have, I am very privileged to work with the smartest people I’ve ever known. So it’s it is a different kind of, kind of challenge, mostly in terms of how do we get the right things done? Luckily, but I do emphasize with this this idea that, well, sometimes I would like to. A little more into coding.

You know, I have those features that I would like to share, but Hey you know, there are some documents that we need to guide. There are some things that we have to think about. There are some, you know, stuff that we need to plan and, and, and so on. So it is different, like a different kind of challenge people often think about, you know, going to our leadership role, like a team lead or tech lead or whatever is a promotion. And I don’t see it as a promotion. It’s a different kind of role. You are essentially a beginner, all again

Mike: Yeah. It’s, you’re just you’re just swimming in a different pond. Aren’t you really? So you’re different sized fish at a different pond. thinking about different things. So this, this episode we are talking about jQuery which might make some of you sort of take a, a, a sharp breath in. So for those that don’t know, Tomasz, what is jQuery?

Tomasz: So jQuery is is a diff interesting uh, subject to talk about in the year of 2022, because if we were to record this podcast, like 10 years ago, it would be the lingua franca of front end engineering, right? Because basically jQuery is a DOM manipulation library, which. fairly old for, you know, modern web development standard.

Because if you have been doing web development for more than two weeks, you’ve noticed that things , tend to change all the time. So jQuery the first edition was 15 years ago.

Mike: wow.

Tomasz: So. It was burned because at the time, and this is still true today, Browsers did not exactly agree with one another. So for instance, manipulating DOM elements. A challenge mostly because you have to think about, okay, in firefox, I do it like this in IE8, I have to do it like this in Chrome I have to do it like this and so on and so forth. And that was incredibly painful at the time. So jQuery was born kind of to, to solve this problem.

And it also came with an entire ecosystem of being able to send Ajax requests and to basically, you know, to, to work with, with backend, to implement animations at the time, there was also jQuery UI which basically was a collection of, you know ready to be used components. And there was a huge ecosystem of plugins.

And I tend to use was, and were when I talk about jQuery because this is not something that people usually grow up when they start a new project, but I still argue that some of those ideas and the labor itself is still important and relevant in the year of 2022

Mike: You mentioned Dom manipulation. What is Dom manipulation?

Tomasz: Imagine, you know, you have a website, you have elements on the page and the easiest kind of scenario is that you want to hover over an element. And I know you would like to change its color or its size. So supposed to have a button, you hover over a button, you would like to make it slightly larger and change the background.

So nowadays this. Way easier than it used to be because, well, you have, for instance query selector and stuff like that, which are built in into the browser. And there’s like a very, very common standard. Whereas back in those days, those days, you know, every, the browser had a kind, like a different way of interacting with, with elements on the page.

So what usually tend to happen is that for instance, when I was working a couple of years, For, for a bank. So they had special requirements that they had to support modern browsers. And also IE8 at the time, so effectively I was working on two apps at the same time. Mostly because IE8 not compatable with, with, with with anything really at the time.

Mike: And so the modern query selector JavaScript function that was inspired by jQuery wasn’t it?

Tomasz: Absolutely. So there’s there, there was this trend for the last couple of years, but I’ve been, you know, tongue in cheek kind of arguing that, you know, just build jQuery into the browser because it’s It’s incredibly, incredibly popular. If you look it up, it’s actually used by the majority of websites online.

And it’s not sometimes it’s even by accident to, before I go back to your question it’s used by accident because Wordpress is incredibly popular on the web and every single WordPress website. Uses jQuery under the hood. So probably, you know, all those websites, they may not be aware even that they’re using jQuery the hood, but it’s it’s incredibly popular.

And like I said, I was arguing sometimes, seriously, sometimes well not so seriously that, you know, just build this into the browser. Everybody will have their own versions going to be always cached because imagine how much processing power we’ve spent with, you know, mankind downloading Jaguar from a CDN it’s probably, you know, terabytes per per day. I don’t have the exact numbers. So whoever listens to this may, you know, prove me wrong, but I’m fairly sure this it’s the number is absolutely massive and jQuery did inspire quite a lot of APIs in the, so the the web manipulation API secondly also jQuery introduced something which at the time was called deferred, which later became promised and promises in JavaScript. So the design was not copied and pasted from jQuery, but it was inspired by it. And it’s still this API shape of jQuery this. Kind of influences some of the products that we have and use today. So for instance, Cypress, my favourite end to end product library.

Mike: Mm-hmm

Tomasz: It uses jQuery under the hood. So basically when you, when, when you are writing end to end test and you think, Hey Cypress is kind of cool. Well, it’s mostly because they have an excellent API under the hood. And is jQuery

Mike: yeah, jQuery been a great proof of concept for, for browsers hasn’t it?. So it’s sort of been seeing how people have used it for the last 15 years. So is there a reason in 2022, that you would start a project with jQuery

Tomasz: as usual with tech, it depends. There’s the it’s like every single somebody ask me if I should do X, Y, Z for a project. Always the answer is depends. If it’s not, then somebody’s lying to you. I would say that first of all, if you want to build something that is not going to get incredibly complex, if you don’t need like huge state management, if you just want to add some. Extra functionality to your site and you happen to find this jQuery plugin, because like I said, there’s this huge ecosystem of jQuery plugins, but it’s not hugely popular nowadays, but this code is still out there. So if you go on the GitHub and find like a jQuery jQuery plugin that solves your particular problem, for your customers and you want to build that or whatever.

Well, you might consider this. Whereas, you know, if I was starting a new project at work or like a startup, I would probably not Derek jQuery this is like, not my go to go to solution because even though I very active on Twitter talking about jQuery I don’t actually use this at work, but I think that there’s also another side of it.

Developers tend to think about technologies in terms. Would I choose this technology to start a project, but vast majority of developers, they are not working on a Greenfield project. So if you, you, if you, you know, start your career as a web developer and you join a large established company, you realize they have seven layers of legacy. And third one is jQuery because they’re actually using something even older under the hood and something even older under that. And you were asked. Okay. You should contribute to that and help us fix some of those legacy issues. Because the, the way I think about legacy code is that this is the code that actually pays my bills. So it’s kind of important maintain that, especially in large organizations. And I I’ve been there.

Mike: So do you think that jQuery has run its course? Do you think it’s it’s if there’s the opportunity to get rid of jQuery you should, or does it still. Have a place. I mean, obviously I know you said if your, if your website isn’t complex and stuff, but if you have the skills and the time and the knowledge, should you be looking to replace it with native JavaScript or is there still holes that jQuery fixes that there aren’t alternatives for

Tomasz: You could rip out jQuery from your site. And actually I read an article recently that the UK government website, they actually ripped the jQuery from their site and because of their traffic, they were, you know, there were some impressive numbers out there and, you know, jQuery weigh, I think like 70 kilobytes or so.

So this is not a, like a zero number. So if you are very much latency focused you might, you know, consider. Every every single time you ship less code, well, you ship less code and users have to download less of it. It’s maybe faster because, well there’s less code to par and, and, and so on. But to go back to your question again, it depends on your, what are your goals is if you have a work in production site and. You wouldn’t get main, like many benefits of pulling out jQuery you will spend half a year of doing that in, but may or may not be useful to you if you know that in the long run you would have to maintain that and you will have trouble for instance, hiring people to actually work on that. Well, it it’s, it’s something that you definitely should consider, because you don’t want your site to become like this old financial systems for wall street that are written in Cobal. And basically nobody knows how to maintain those anymore because they are so old nd has a different kind of foundation to legacy code than some of the backend systems that I’ve seen because backend in larger organizations, usually it gets to treated like, Hey, if it works it’s all good. Whereas front end development, like in general, tends to evolve much more quickly. So as usual, it depends.

Mike: So I, a lot of, a lot of our websites actually use jQuery at my work. So I actually use it still quite a lot. And every now and then I sort of go through, you know, a sort of A little Google and stuff to find if there’s any alternatives. Is there anything that has sort of a similar API, but is smaller?

Cuz there are things like Zepto . And I think that was one called sizzle,

Tomasz: So Sizzle is the the query engine that is built into jQuery. So if you only the DOM manipulation stuff, you can grab it without all of the extra baggage.

Mike: Yeah. Yeah. So there are sort of certainly a few alternatives. Some of them use the same, like APIs and syntax that are in theory, if you don’t need any of the sort of more complex jQuery stuff like Ajax and stuff like that, then you can just sort of swap it in and out to save some bytes without having to rewrite all your legacy code.

But the thing I found when I was sort of Googling for jQuery alternatives is React and Vue come up a lot as viable jQuery alternatives. And it sounds like my kind. Web development history is similar to you. I’ve been sort of being a front. I started off as a front end developer. I’ve been doing it for sort of 10, 12 years.

So I was very much jQuery from the start. You know, I had the classic Sitepoint, JQuery ninja book. I, I said, I read that on the bus on the way into work. And I just can’t see how you could ever replace jQuery with react unless your whole site was built with. like, jQuery using it for templating and stuff, because for me, jQuery is like, you’ve got a, dynamic website that’s from a CMS, like WordPress or something like that.

And then you can sort of drop jQ uery in there and sort of add some animations. Or as you said, some DOM manipulation some slides, some AJAX and stuff. I don’t, maybe it’s my naivety with react, but I don’t think you could ever just drop react in and then be like, oh, animate this, animate that. And if you did it’s react, I mean, I don’t have the size in front of me.

I can, I can have a look at a second, but in terms of file sizes, I can imagine reacts bigger as well than jQuery

Tomasz: If I think the, to react is roughly the same in term in terms of, of, of size. Well, of course, you know, react is it, it solves different set of problems. I suppose I, I would argue that whoever thinks that Hey, we should just replace jQuery with react.

They are, they really want to get rid of jQuery in their side like this is not a drop-in and replacement I I actually have been involved in a project where we migrated from backbone. Backbone is a for kind of younger I suppose listeners out there. it is a, a framework which was based on top of jQuery and introduces like model view controller. To the web and so on. And I was involved in a project that was migrating that to react and it takes months on a reasonably size project to migrate it from one framework to another. And that is why I said that it might be useful for you to do that when you’re thinking in, in, in the long term, but the worst case scenario.

And I’ve also seen that. You start migrating from framework a doesn’t matter if it’s or whatever, to framework B and you are left in between because the priorities change and having to maintain a code base where you have half of staff, you know, in January half of that scenario, some of the parts are in view because we’ve hired this one developer and they already wanted to try you.

it’s not exactly pleasant and, and one more thing. Kind of, I miss from jQuery days I suppose, is that maybe jQuery is large in terms of file size. Maybe it is, but you install a single library and you have AJAX, you have animations and you have no manipulations and so on. So there’s one decision , to be made.

Are we using jQuery yes or no? Whereas with full react, react is. It’s a library for, for views. It doesn’t have very strong opinions on sighting. It doesn’t have very strong opinions on animation. It doesn’t have a very strong opinions on like state management and so on. I’m not saying that jQuery has opinions on all of those stuff, but for instance, I have this opinion that, animations were much more visible and much more prevalent on the.

When jQuery was the king of the new websites, when you have, you know, scroll up scroll down all those kinds of events and don’t get me started on flash. I I still miss flash.

Mike: Still miss flash. Yeah. I was just, was just have a look. And jQuery is 18% smaller than react and that’s obviously without all the sort of extensions and the plugins and, and stuff like that.

So, Yes, you’re saving it, but when we are talk, when we’re saying 18%, it’s something like, it’s the difference between 95 and 75 kilobytes?

Like it’s not Yeah, it’s sort of, you’re saving a few K

Tomasz: and it still depends on what you optimize, right? Because you, you, every single project has different business needs. If it’s your is your project. So latency focus that you have to have, you know, your site loaded in under 10 millisecond. Well, maybe then your preferred framework of choice may not be the exact, the bottom leg, because maybe you need to use some edge computing stuff to push your stuff closer to the edge.

And so on. I guess what I’m trying to say is that the, the file size of a given framework is one of bazillion different factors that you have to consider when building stuff on the web.

Mike: Yeah. Cuz It might be that you can load react if you’re using react, you load react, but you then need less. Other assets or your, your actual general document size can be a bit smaller or stuff like that. So it does it certainly a lot to consider. It’s not just a, like for like swap it

Tomasz: And it’s possible to write slow, terrible, terribly optimized code in any framework. And if you don’t believe me, I can show you

Mike: I’ll pull up a project I wrote about five years ago and I’m sure it’ll be something in there. If you go on like built with.com or something like that, I think the last time I looked over 80% of the websites in the world we’ve got jQuery or something, but if you are on Twitter in the front end, development sphere you’d get the impression that everyone hates jQuery everyone’s using react, but why does it have this, like, cuz it’s obviously got a need in business, in big businesses and corporate worlds and stuff, but where is this mentality come from that jQuery’s the devil and should be avoided and. Why, why has it got such bad press?

Tomasz: So quoting Wikipedia, " jQuery is JavaScript library designed to simplify HTML DOM tree traversal and manipulation, as well as even handing CSS, animation and Ajax" and what happened in. in some of the larger projects that you start using jQuery your app explodes in complexity because it always happens.

You know, every single project gets larger and larger and larger, and you realize that, oh, crap, jQuery doesn’t have shonk opinions on, for instance, state management. So for instance having to check of, you know, Is this customer locked in if they’re logged in, okay, we need to change the, the header color to this.

I click on this button. So this stuff in the other side of the code base, it needs to change. It needs to, needs to be updated and so on. And it becomes a spaghetti code. So spaghetti code basically is this idea of it is like tangled, like spaghetti. So is very difficult to find out what affects what so to give you a concrete example, When I was working for, for this project, when we are migrating from, you know, jQuery to some of the other stuff, we’ve had two different event buses.

So the idea was that you can send an event to an event bus, basically like an at event listener. And the other part of the app could to react to it. And we had two of those that were conflicting, you know, both of them were legacy was very hard to maintain. So of course what we did, we added the third one. So it was an absolute mess to, to maintain.

And that is part of the reason why I quit after not a very long time I suppose, because it, it was not fun to maintain. And secondly, I, I did mention the legacy is often found in the legacy projects and the web development community. You know, especially like nobody is very excited about mating legacy stuff.

Developers who get told that yes, we actually need people to maintain our legacy stuff because well, we need to get paid and this is what pays our bills. They say, no.

Mike: Yeah. , it’s just not new and exciting any more as well and that, which, which doesn’t help. I’ve just while you were talking there, I’ve just pulled up the built with and this, it, it, if I’m reading the numbers, right. There’s 80 million websites with jQuery on them and. 10 million with react. jQuery is still very much alive. I think we’re currently on version three point something aren’t we?

Tomasz: yeah, the, the last release was last year ago. So in the March of 2021,

Mike: so it is still, it’s still being developed. And I think there was some, some chat of version four coming at some point with some big changes and it just, I mean, jQuery the people working on jQuery strikes me as. The kind of people that want to get rid of it themselves in a kind of weird way. Cuz every release has less and less stuff in it because browsers support more.

So it’s not like it’s something that’s being developed and then it’s just sitting there big, old and clunky. It does, does get optimized and it does get cut down. So hopefully there’ll be a point there. We can just. Delete kQuery and everything just works with a few small changes. So that it certainly feels like the mission they’re striving towards.

Have you got any other comments that you want to say about jQuery before we wrap this up?

Tomasz: So to kind sum it up from my own perspective, I’ve been using react for basically everything for the last six years, react pays my bills and, you know I’m. I’m very happy user of it. I, I do have some concerns with React there are some things that, you know, could be improved. Some things are are difficult, but the, the ideal framework is the one that you write yourself.

And I don’t have the patience to do that. and by the way, I don’t do this. Don’t reinvent the wheel until you really they have to. So I think that, you know We should be extremely grateful to everyone who ever worked on jQuery because it was still is the so-called backbone on the, of the entire web development infrastructure.

And secondly, I do strongly, I, I have this very strong opinion of the jQuery was one of the best things to ever happen to the web Because of the fact that it did simplify and solve this problems of like cross-browser issues with like DOM manipulations and Ajax was way simply with jQuery as opposed to, to this a X HR request, which were BA built in into JavaScript. And nobody remembers the, the syntax. So if it wasn’t for jQuery I feel like the, the speed. How the web development evolved would be significantly slower. And the, the fact alone that the Jaguar design did influence the choices or later built in into the browser. This is an excellent thing. And I do agree with you of it.

You know, at some point the jQuery team might basically stop contributing to the project because the, the issues that were the de was designed to solve, they are going to be solved in the browsers. The. Which is a good thing and which is an excellent thing for every single web developer out there. So still, you know, cutting edge.

I am very much interested in new brand new technologies, but I do sometimes wish we could go back to those simple times where I could just install a single library, copy a single thing into HTML. I remember that HTML, I could copy a script tag and send a network request and the other name animation to the button. Without, having a PhD in modern front end development.

Mike: Yeah. There’s a couple of things there. Before the fetch API came around in the browser I tried to make it a mission to, I was like, let’s get rid of jQuery. Oh, I need to do an Ajax request. And yeah, it’s not, it’s not easy. Or it wasn’t before fetch came along and secondly, I wanted to build. Web application with one of the modern frameworks and coming from jQuery react was such a big. Like hurdle that I just couldn’t get over at the time because you couldn’t just drop in a script tag and write some HTML. Whereas with Vue you actually could. And like, yes, you can. And it’s better if you do an NPM install with Vue but I hadn’t, before I got to that point, I hadn’t really NPM installed anything.

You know, I was very much a shove script tag in the bottom of the, the page kind of thing. So there is certainly. A big, I dunno whether React have since released something that you can just put as a script tag in your footer, but certainly at the time Vue you could just yeah. Include something, whereas reaction couldn’t.

There is still something that jQuery does that I’ve yet to find anything else that fills that hole of just like, oh, I really need to do an Ajax request. And I really need to have some animated tabs and some toggle boxes and all of this. Let’s just shove in jQuery and there’s sort of, there’s nothing really that fills that hole. At the moment that I know of. I mean, it might be that someone gets in touch and tells me that I’m wrong right. So if that’s all, thank you very much for your time, where and how can people get in touch or find you if they wanna disagree with what you’ve said or if they wanna sort of pat you on the back or, or similar

Tomasz: The best place to find me, if you either agree or disagree with me is on twitter.com. So my, my handle is tlakomy. So it’s T L a K O M Y. I’m assuming this is going to be in the show notes to this as well. It is possible to find my email online. Don’t email me. I am terrible at. And as I mentioned at the very beginning, I’m a co-founder of clouddash so if you happen to be annoyed with the AWS console and you wish it would be, you know, much more much easier to use check out, check us out at clouddash.dev.

Mike: Wonderful. AWS still scares me. I still log in and just get confused by the hundreds and hundreds of options of things when you just need a web server, you know, it’s

just, Yeah, so I am at @mikestreety on all social networks and you can find the podcast @behindsource on Twitter. Or as I mentioned at the beginning of the show at www.behindthesource.co.uk, there is a mailing list.

If you want to get in touch with any comments, criticisms feedback, or you wanna feature on the podcast, or you wanna suggest someone’s feature on the podcast, then drop me an email at [email protected]. Tomasz. Thank you very much for your time. It was great to talk to you about jQuery reminisce in the old web dev days before things got complicated.

Tomasz: Thank you for having me. That was fun.

Mike: No problem at all