Telerik blogs

This article is the transcript of a Slack chat between TJ VanToll, Jen LooperTodd Motto, Jeremy Likness, Aurelio De Rosa and Nathaniel Anderson.

Although jQuery's heyday may have passed, the library is still used at a staggering rate. But how of much of that usage is legacy? And how many developers are choosing to use jQuery in new applications?

In today’s Slack chat we’ve invited a few industry experts to talk about these questions and more. The topics for today’s chat are:

  • What are the pros and cons of using jQuery in 2016?
  • What sorts of apps is jQuery the most useful in?
  • If you were starting a new web app tomorrow, would you use jQuery?

Let’s start by having everyone provide a brief introduction so readers know who’s here.

Jeremy Likness: I am a 7-year Microsoft MVP (my specialty is Visual Studio and Developer Technologies) and I lead the application development practice for iVision, a technology consulting services firm based out of Atlanta, GA. I am a certified Kendo UI developer and Telerik Developer Expert and have been using Kendo UI since beta.

Jen Looper: I’m a member of the Progress Developer Relations team along with TJ.

Aurelio De Rosa: Hi everyone. I'm Italian developer in love with the Web. I'm also a member of the jQuery team.

Nathanael Anderson: I'm an independent contractor doing development in Web, Desktop, Server and mobile applications.

TJ VanToll: I work with Jen as a Dev Advocate at Progress. I used to be on the jQuery UI team, so I might have a bit of a bias in this conversation πŸ˜„. Our colleague Todd Motto is lurking in here as well and will be joining momentarily.

TJ VanToll: So onto our first question: What are the pros and cons of using jQuery in 2016? Who wants to get us started?

Aurelio De Rosa: One of the main pros is that it's very easy to start developing with jQuery, which is excellent for web amateurs and junior front-end developers.

TJ VanToll: For sure. Personally I still find jQuery’s APIs incredibly elegant compared to the DOM.

Jen Looper: I think that jQuery is getting an increasingly bad, and undeserved, rap nowadays, simply because of JavaScript fatigue and the number of new frameworks coming down the pike.

Jeremy Likness: I will start with pros. I know for the longest time jQuery was one of, if not the, most downloaded/used libraries on the web, so it is certainly a proven library and there are many people with experience using it. In fact, it's managed to become so ubiquitous some beginning JavaScript developers confuse it with JavaScript.

TJ VanToll: Yep. And because of that, the breadth of knowledge online via tutorials and such is incredible.

Todd Motto: To me jQuery is/was like the BlackBerry of “smart phones”. It was once dominant, but that’s quickly fizzling out.

Jen Looper: One of the cons, and something that can bite newer developers in interviews, is just what Jeremy mentioned - learning jQuery shielded a lot of folks from actually learning JavaScript.

Jeremy Likness: There are numerous extensions, plug-ins, and add-ons available. Ultimately I've always looked at jQuery as a way to normalize the DOM. Write once and let the jQuery team figure out the nuances of various browsers. That's not fair because it does a lot more than that, but I believe that's why it became so popular, so quickly.

Nathanael Anderson: I think you guys covered the pro's pretty well; the biggest negative for JQuery in this day and age is that browsers are a lot more standard in coverage and directly messing with the DOM is slow unless you can do everything at one time; and JQuery was not designed for large change groups.

Aurelio De Rosa: As Todd said, jQuery is probably less useful then it used to be these days. But I think that it has incredible merit: jQuery has helped shape the specifications of features like querySelectorAll(), prepend(), append(), before(), after(), and replaceWith().

Jeremy Likness: Con: a lot of what jQuery does is imperative, when much of UI work tends to be declarative, so it forces a mix of code and markup in HTML pages.

Jen Looper: It seems to me that the rise of Angular had something to do with the downfall of jQuery - jQuery lite was included, if I remember properly, in Angular 1.x, so people were in turn shielded from jQuery…@Todd Motto what do you think?

Jeremy Likness: Con: continuing from the last point, a lot of what you do is "start somewhere" and "filter to" or "filter in" ... i.e. grab an element or bucket of elements, and then apply a change. With a declarative approach, you can attach a behavior directly to the parent element and don't need a selector to "find your place."

Todd Motto: 100% agree. To be honest, most of what I wrote before Angular was jQuery. But I did however know the equivalent JavaScript APIs. Angular 1.x showed us ‘jQuery devs’ the way forward for building complex apps with sensible separation layers.

Jen Looper: I think my trajectory was similar, Todd.

Todd Motto: Now we take the opposite approach, instead of touching the DOM, we “program” our JavaScript to tell the DOM what to do. This is the key mind switch for me. Event listeners? Automated from a framework, React, Angular, doesn’t matter.

Jeremy Likness: I believe that Angular, Knockout, React, etc. have all contributed to diminishing the need for jQuery. I don't require it anymore for my developers and we rarely, if at all, use it in projects because we are focused on data-binding over imperative "programmatic" access.

The DOM api has become more standardized, so when you develop for a "modern" or "edge" browser you no longer need that normalization.

TJ VanToll: That actually leads into our next topic quite nicely so why don’t we go there. Nowadays, what sort of apps are best suited for jQuery usage?

Aurelio De Rosa: I don't think there are specific apps where jQuery is a good fit. I think that jQuery is general-purpose and as such it can be used everywhere. However, a situation where I'm employing jQuery more and more these days, together with Bootstrap, is when I have to develop prototypes.

Jeremy Likness: In our work it really boils down to "brochure-ware" sites and legacy sites. The former because I may have mostly static code and can use some lightweight jQuery and plug-ins to add some effects, and the latter because I can use it to bridge across older and newer APIs. 99% of what we do only includes it as a side effect, i.e dependency from an existing library, and those are becoming less.

Aurelio De Rosa: When developing a prototype, I need something that allows me to achieve a result quickly and with a few lines of code. jQuery is also excellent as it has an incredible ecosystem around it (e.g. plugins). jQuery UI and the almost unlimited amount of plugins, for doing basically everything you might need, are perfect for adding widgets with minimal effort.

Nathanael Anderson: I would agree, jQuery can be used to mock something up; or if you need compatibility with some older stuff; but mainly new development being imperative eliminates most usage of jQuery in newer apps.

Todd Motto: Thing is with jQuery, it’s not for building apps. We have component-models now that make way more sense. jQuery shouldn’t be shamed as “useless” in the app world, it got us this far - however we’ve completed eradicated (through very smart frameworks) the use case for it. Even with Angular 1.x, I’d rarely use it as well.

Jeremy Likness: Right. Prototyping is great. If I want to show the results of a motion study, demonstrate interaction without the underlying app, that's a way to do it... however quite frankly a lot of what we do now is prototype with Angular and then start from the prototype markup to build the real app.

TJ VanToll: To me there’s a distinction to be made between web sites and web apps. Web apps tend to be more complex, and more advanced concepts like separation layers can make a big difference. Web sites tend to be a large chunk of the web, and don’t require a whole lot complex. In those cases, cases where Angular, React, and so forth are overkill, I still think jQuery is highly relevant. jQuery plugins are still the easiest way to achieve little effects on brochure sites.

Jeremy Likness: I'd also say back to my legacy point - if I want to parse the DOM, jQuery is the best there is. Maybe I inherit a huge site and lots of code, and want a simple plug-in that applies a behavior. I don't want to rewrite the site with a modern framework, jQuery makes it easy for me to filter to what I need, inspect the DOM, manipulate it, and add a behavior without boiling the ocean. Uh-oh. Now I've introduced a cliche.

Todd Motto: The issue jQuery has is that it is just a library, even the plugin ecosystem is extremely mixed and complex in structures of plugins. Think about turning that into a “framework”. You’ve no separations, models, view layers - unless you spend a lot of time rolling your own. If you did roll your own JS models etc. with the right JavaScript patterns, then absolutely jQuery can boss it. But we, IMO, as a community are not likely to ever do that. It’s slower to build, difficult to predict, no controlling dataflow and events / lifecycle hooks and so forth.

TJ VanToll:

add a behavior without boiling the ocean

New jQuery tag line right there πŸ™‚

Jen Looper: What about on the mobile front? Would anyone ever have a need to use jQuery to build mobile apps?

I’m thinking not.

TJ VanToll: 🍿

Nathanael Anderson: For a PWA maybe, for a native app - no.

Aurelio De Rosa: I guess it depends on the kind of features you want to demonstrate or prototype. If I want to demonstrate an interaction or an easy feature, I'd definitely use jQuery and avoid any framework. It's known that MVC allows you to write more elegant code and gives you the separation of concerns, but it's also known that it increases the amount of code you have to write.

TJ VanToll: I have used jQuery on mobile and I would totally do it again. You have to be careful what you do on mobile because every kilobyte counts, but jQuery is good about being modular so you can grab just the pieces you need (AJAX, animations, DOM manipulation, etc).

Nathanael Anderson: React Native and NativeScript don't have a DOM, so JQuery can't work. For something like Cordova/Phonegap or a PWA, they are still using a WebView and so you have a DOM to access.

Todd Motto: Even years ago I could tell jQuery mobile was never going to fit with my workflow/mindset for building apps - before any proper solution came along too.

Jen Looper: Yes, I’m just thinking back about those jQuery-heavy frameworks for mobile and thinking…nope, no màs!

TJ VanToll: I think jQuery Mobile was good as long as you viewed it as a quick way of building a decent app. Remember that jQuery Mobile’s initial aim was taming the UI on what was then an absolute wild west of devices.

As devices got better its value diminished.

But it’s still great for beginners and for prototyping in my opinion. Really easy to learn and use if you compare it to JavaScript MVC frameworks today.

Jeremy Likness: Right "taming the UI" ... basically normalizing it again. Normalize the DOM. Normalize the UI.

I'm not sure I agree a framework increases the code I have to write. The first time? Maybe. But if I can create a component/directive/behavior that is reusable and declarative, I can actually mock using a data-binding framework much faster than writing imperative jQuery code. I like the fact I can reuse something as either an element or attached behavior. Add the attribute "my-focus-attribute" and it's done.

Aurelio De Rosa: I agree with TJ here. jQuery Mobile has been very useful in the past and I still find websites around that use it.

TJ VanToll: Some of the Android 2.2 hacks in jQuery Mobile were, um, interesting πŸ˜›

Jen Looper: Would you teach jQuery to new developers, like in a coding school? Inquiring minds want to know

Jeremy Likness: Jen, probably not. We just don't use it enough.

Aurelio De Rosa: I'd say I would not teach it, but use it to teach.

TJ VanToll: Jen, I would argue yes. It gives beginners a sense of accomplishment to be able to do something powerful very quickly.

Aurelio De Rosa: I find jQuery an excellent tool for teaching code to others. Sometimes you want to teach a technique without throwing into the mix the intricacies of browsers incompatibilities and some methods of the DOM API to avoid any distraction. Other times, you want to give a gentle introduction to a concept before delving into the native implementation, without having to write several lines of code. In these and other cases, jQuery is a great tool to use.

Jen Looper Aurelio, that’s a really interesting approach. πŸ™‚

Aurelio De Rosa:

It gives beginners a sense of accomplishment

I hear you, TJ.

Todd Motto: Performance is another key factor for me here. Angular 2 can be statically analyzed and tuned to perfection with Angular’s ahead-of-time compiler, which is where critically fast rendering comes into play. With jQuery, it’s all post-processing DOM manipulation, no way to control state mutations or template layers. One-way dataflow has proved “the way” forward, even Angular 1.x has it now to steer away from two-way bindings in components to help the migration. From a performance perspective, one-way dataflow is far better through using immutable operations to create new state, it helps the change detection mechanisms to calculate what’s changed faster, as well as time-travel debugging helpers where we can step through state mutations etc. jQuery is literally (to me) a helpful tool for hitting the DOM where needed - but even with Angular 2 and React, the DOM layer is abstracted from you for performance reasons as well as native rendering (NativeScript, hello!)

TJ VanToll: I agree with what Todd had to say. I think the only thing I’d say in response is that there are a whole lot of web sites out there where that sort of performance nuance is irrelevant; they just need an accordion that works and is accessible.

Jen Looper: I just grabbed a book off my bookshelf, it’s “JavaScript for Kids: A Playful Introduction to Programming” by Nick Morgan - highly recommend, btw, and guess what’s in Chapter 9 πŸ™‚

Aurelio De Rosa: jQuery Jen? πŸ˜„

Jen Looper: “Advanced JavaScript: The DOM and jQuery"

TJ VanToll: So let’s move onto our last question to wrap things up: If you were starting a new web app tomorrow, would you use jQuery?

I’ll give every developer’s favorite answer: it depends πŸ™‚

Aurelio De Rosa: I don't use it by default anymore, but it also depends on the project and the browsers I have to support. These days I don't have to support IE8 anymore, but I'm still maintaining some code bases developed a couple of years ago that needed to support IE8. So, I still see jQuery around from time to time.

Jen Looper: At this point, with the use cases I’m developing, I’d say probably not. That being said I don’t work in a web/mobile shop any more.

Nathanael Anderson: No, more than likely not. As you say TJ, it does depend; but it is more like it would be a special case that needs it; rather than the default choice now.

Jeremy Likness: Right. Gets back to ... brochure sites and legacy. πŸ™‚ jQuery still rocks for those.

TJ VanToll: Exactly. I still find jQuery to provide the exact mix of functionality I need for little sites like that. I would probably not, however, use jQuery if I were starting on a large complex app nowadays. I think modern frameworks like Angular 2 just provide better paradigms for building apps at that scale.

Aurelio De Rosa: I think we can all agree that jQuery is not the tool for building SPAs, but to be honest, it was never conceived for that.

Jeremy Likness: 99% chance I would NOT be using jQuery for a new app, unless it was a dependency of a library or framework I was including. Most of what we build are web apps, not web sites, and 99% the ask is for a responsive, mobile-first, single page app.

Jen Looper: jQuery will live forever in the legacy and embedded in those frameworks! #jQuery4Life! πŸ™‚

Todd Motto: I wouldn’t no, but if I was building some form of brochure website that required some interaction, I’d certainly consider it πŸ™‚

Aurelio De Rosa: I think we should also consider what jQuery has done not just for developers, but for JavaScript.

Jen Looper: That’s true.

Aurelio De Rosa: jQuery's utility is fading away, that's for sure. But this is actually a good thing. It means that standards are evolving and we're finally getting where jQuery led us several years before.

Jen Looper: I think it helped smooth the way for a lot of people

TJ VanToll: Amazingly browsers are relatively spec compliant nowadays. Who would’ve thought that in 2006 when jQuery first came out?

Jeremy Likness: Yes. It is ironic, but I've had a web blog for almost 10 years now. I've had popular Silverlight articles, Kendo, Angular, you name it. But if you see the most viewed article across all of the thousands I've written, it's an old snippet that tells you how to use a timeout to fix an issue with an event handler in IE 6.

Those were the most painful days of the web and jQuery completely transformed it and made building web apps at scale possible.

Aurelio De Rosa: Well, it took just a couple of decades πŸ˜›

Nathanael Anderson: Yeah, but jQuery probably had a major hand in getting MS to actually fix their issues; since the code would work on all browsers but not very well on IE....

Aurelio De Rosa: One thing I wish I'd see in all these new upcoming frameworks and libraries is a better documentation, one that is comparable with the jQuery one.

Not many projects can claim the same good documentation that jQuery has.

Jen Looper: That’s true…I guess it will take time to catch up.

Nathanael Anderson: PHP imho has better docs; but jQuery is way better than most projects.

TJ VanToll: Aurelio, completely agree, and on that note we should take a minute to thank Aurelio, aka the 4th largest contributor to πŸŽ‰

Jeremy Likness Thank you, Aurelio!

Jen Looper: 🎊

Aurelio De Rosa: I didn't expect this, thank you all πŸ˜„

Todd Motto: Final thing from me: let’s not aim to dissuade jQuery developers from using it - it’s amazing, extremely mature and powerful, and its place in “modern web” has shifted, that’s all. In 5 years we’ll all be doing it wrong again πŸ™‚

Jeremy Likness: The documentation is great. Love seeing newer frameworks adopt the philosophy of documenting and testing as you build, rather than making a separate after-thought project.

Jen Looper: I’d just say that if the web has moved away from the need for jQuery, that’s only great news! That means that browsers have standardized and frameworks have matured. Now, we have a great model to follow for future development.

Jeremy Likness: Right. I'm definitely not opposed to jQuery or developers using it, just like I have a lot of respect for React and Ember even though we've found our productivity through Angular

Nathanael Anderson: Agree with both of you Todd & Jeremy. jQuery is still a rich library.

Aurelio De Rosa: We, as web developers, owe a lot to jQuery. It's an incrediblely mature project, another feature that not many other projects can claim. It has reached a point where it doesn't need to add more functions to be useful. It's in fact "removing" them (e.g. the slim version). So, thank you jQuery and the whole community behind it.

Nathanael Anderson: +1

Todd Motto: Yep! And I know if all goes wrong with a framework, I can get the job done with jQuery πŸ˜„

TJ VanToll: To me, jQuery remains the gold standard for a library with an elegant API design and comprehensive documentation. Although I may not use it in every app nowadays, I still find it the easiest way to interact with the DOM and add powerful widgets to my apps.

On that note, here at Progress, we have you covered whichever way to choose to build your apps. Our super popular Kendo UI for jQuery control suite provides 70+ UI widgets for your jQuery-based apps. And our new Kendo UI for Angular 2 suite lets you use the same suite of controls without the jQuery dependency.

And if you found this chat interesting, you might enjoy our broader discussion on the future of JavaScript as well.

Related resources:

TJ VanToll
About the Author

TJ VanToll

TJ VanToll is a frontend developer, author, and a former principal developer advocate for Progress.


Comments are disabled in preview mode.