You think jQuery would finally have died after the IE era? Or that it would only be used to still pander to IE users?

Well... nope: https://w3techs.com/technologies/... says jQuery 3 has overtaken jQuery 1, which was the only version to even polyfill IE.

WTF is wrong with web devs, just WHY?! jQuery's use cases are shit that would be simpler and with less code without jQuery, shit that should be done in CSS instead, or shit that doesn't belong on websites to begin with.

Magento...
Atlassian....

Any larger web frontend that is older than 5-10 years and that will never get migrated for the sole reason that maintenance plus selling support is more efficient than investing in modern stack.

Atlassian realized just 2 years ago I think that Postgres 9 (!!!!) with it's initial release in 2010 and last release in 2015 if I'm not wrong should be replaced with Postgres 12.... Any version other than 9 was unsupported in the whole product line if I remember correctly.

It's blazingly incompetent stupidity.

@IntrusionCM Incidentally, I remember Atlassian only for their atrocious Jira and Magento for their security problems.

I never got the hate for jQuery. It was a fabulously robust solution that pushed the issue that web content should be responsive to the end user.

I still think it's far easier to use than native js only because of my extensive experience in CSS selectors and would probably still use it if a client required a static HTML site that didn't/couldn't be built with something like Vue.

@sariel So basically use cases 1, see also https://youmightnotneedjquery.com, and 2, abusing JS to do CSS' job.

@sariel abusing vue.js is nice though. We can just static link it into anything in order to have it working anywhere. Going to use it if js DOM is not an issue

jQuery is still WAY BETTER than react on poerfomance side ... so...

For me anyone using react is an idiot. jQuery is better

Eh, I won't use JS for anything new these days but I still have projects lying around using it.

No, I won't be ripping out Jquery because you don't want me to use it and spend months replacing it with something else, both vue and react, we dont speak about B̶r̶u̶n̶o̶ Angular here, but yea something else would take a lot to migrate over to when it would be easier, and more cost effective to let the projects die and be rebuilt from scratch.

WordPress maybe? Nextjs and sveltekit are way easier to use.

Going to preface this by saying I'm not a web developer.

How would you build UI functionality without using JQuery? Raw CSS and JS is not superior to JQuery.

If you don't use Vue or any other JS frameworks, isn't JQuery still the best option?

JQuery is not that big of a dependency for even a large web application, it does not require webpack etc to be added to a project (one could argue that neither the other examples in terms of frontend) and it does what it needs to do in a pretty reasonable way.

I get that you are not a web developer, but trust me, if you ever build a large project, you do not want to wait for the "I do this in X way" mentality of CSS developers, no, what you want is for the fullstack dev to be as common as you can in terms of what JS they are bringing to the codebase. It is far easier to find JS experts than it is Kiki level masterminds with regards to CSS, everyone hates CSS but Kiki, because only Kiki gets CSS. For everything else you want JQuery

@searchy2 it is, it would also be the easiest one to maintain and the less resource intensive, there really ain't nothing wrong with jquery other than the fact that it overcompensates for lack of CSS JS knowledge. Even then, it is better to use a curated library to handle things in a standardized way than it would building things from scratch. As a full stack web dev, JQuery still has its place and there is nothing wrong with it other than hype hate.

@Fast-Nop those are simple use cases, the great variety of web applications do not fall into this category, and you do not want your frontend shit be handled insecurely in a case by case basis without a proper framework. Trust me on this

@IntrusionCM modern stack in the sense that: Let us use shiny frontend tool that it is not Angular because we are progressive and cool!!! Oh shit version compatibility and node modules broke!!?

Not that long ago I reviewed the whole frontend of the product I work with with the sole purpose of aspiring to get rid of jQuery… and the conclusion I arrived to was that it’s still the best approach in our case and as long as jQuery keeps being maintained and no better approach for this particular case pops up, it makes zero sense to go about replacing what we have with, say, Vue or Svelte or anything I did review as an alternate.

@100110111 i want to kiss you so bad and I do not even care about my heterosexuality

@NoToJavaScript pure javascript is way better than jquery on performance side. Anyone using other than javascript is idiot.
C is way faster than java. Anyone not using c is idiot.
Cpu instructions are way faster than C. Anyone not whispering to cpu is idiot.

So, whats your point? Of course I'm not fan of bloated frontend stack but if something does the job by cutting development time in half why we shouldn't sacrifice few milliseconds of load time?

oh, you poor frontend slaves, bickering over which terrible framework to use to make the terrible thing you call "javascript" barely usable... *laughs in backend*

@searchy2 jQuery is basically just repacking existing functionality, and since it doesn't support IE anymore, you can as well use native JS, CSS, HTML. CSS in particular for things that are CSS' job to begin with because it performs way better, given that it can offload stuff to the GPU if done right.

@AleCx04 jQuery contributes nothing to security because it's not a framework, it's just a (now) superfluous DOM manipulation library. E.g. jQuery's .html() has exactly the same problems as innerHTML.

It was useful for papering over bad IE quirks, but first, that stuff has long been available in vanilla JS now, and second, jQuery > 1.x doesn't even support the IE quirks. Migrating from jQuery 1.x to 2.x/3.x as seen in the stats was pointless because the migration could as well have been to vanilla JS and proper use of CSS e.g. for animations.

I don't get the JQuery hate. Yes, all of it's functionality are availabe to plain / vanilla JS now, but JQuery makes coding consistent and simple. Also the filesize is very small and it gives very small overhead and performance degradation.

Vanilla JS is too mouthful and prone to errors. Instead of typing InnerHTML, html() is much simpler. Instead of typing getElementById and getElementsByName, typing $("") is so much simpler.

If you make a simple website, not a single page application, JQuery does the job.

Not everything has to be made with shiny new tools. Why use electric saw and electric drill to make a simple bench, when a plain old hammer and saw do the job?

@daniel-wu Only that it's anywhere from one to two orders of magnitude slower e.g. upon selectors. Wah wah don't wanna learn JS (not to mention CSS) isn't a good excuse.

Of course, modern hardware is fast, but it's an overall mindset of sloppiness at every corner that gives us a sluggish web despite modern hardware and bandwidth.

@Fast-Nop

I think Javascript itself, and the browser APIs/DOM are a sloppy mess, not necessarily jQuery.

jQuery was just a way to try to unify that sloppiness.

And working at a company where Vue is the norm... I can't say Vue is much of an improvement.

Sure, components and SPA stuff is powerful, and "modern frameworks" like Vue/React/Angular enable that...

But it has not improved performance of websites, made interactions more robust/bugfree, or decreased the amount of under-the-hood "magic".

Vue honestly makes it even harder to debug frontend issues compared to good old jQuery.

@bittersweet jQuery was highly useful back then when it spared you dealing with the IE mess. These days, IE is no more, and you already have a unified JS: vanilla JS.

Actual frameworks such as Vue have quite a different use case, namely to get rid of the jQuery spaghetti that inevitably accrues in more complex applications. Data X influences also widget Y, and a setting in widget Z also has impact on widget Y.

jQuery spaghetti means having these cross-dependencies spread over tons of handlers while a framework uses declarative logic to model the dependencies. After all, jQuery is a library, not a framework.

If you can meaningfully use jQuery because tracking the state right in the DOM is manageable, then a framework is overkill - but then you can as well use vanilla JS.

@Fast-Nop but it does because my point still stands: You do not want a "I did X and Y" build from scratch on every project, when I means securely I am not talking about literal security concerns, but more in terms of a "standardized" way of doing things, which JQuery will have over any monkey doing 10 billion different things in JavaScript.

And yes, it is a library more than a framework, but in the sense of all the available plugins and add-ons to the library that they have a lot of us that work with it do see the entire ecosystem as a framework. Which, by the way, it is still lighter than anything that is node_modules based.

@tosensei not a full stack in 2022? weird flex but ok.

@AleCx04 So basically avoiding to learn JS as reason to stick to a crutch that has long lost its original justification, incurring a x10-x100 JS execution speed penalty, stuttering animations in particular on hi-res displays, and some 80k of minified JS that get parsed for nothing.

@Fast-Nop Yes and no. Everyone that uses JQuery should be familiarized enough with Javascript to work independently from one another. My point is:

Company X requires a table which will require: population through an API from some endpoint, full ajax based functionality, pagination, state management etc etc. Should company X say "ew JQuery, I saw on youmightnotneedjqury that JS on itself can do them simple examples (which the web never is), I will just have someone develop their own solution for it instead of using datatables.js!!"

Then bam! We created a unique solution for which we are trusting the skill of the average JS user (that alone should tell you my friend)

Or we add the plugin that is maintained documented and for which the performance penalty is minimal since people are no longer running a pc from the early 2000s

@AleCx04

I'm definitely not fullstack either -- and I think no self-respecting developer should aim to be a fullstack dev, at least not in the long run.

Any interesting job will have such depth of technology that keeping up with all of frontend/backend/DB/ops is impossible.

Of course, as a Backend dev you should probably make a simple frontend a few times, and it wouldn't hurt if a Frontend dev can understand some simple SQL queries.

But to me "fullstack" sounds like "junior without specialization".That's not meant to disrespect people who call themselves fullstack devs, I just think it's a terrible career plan to focus on "a little of everything".

@Fast-Nop Are you sure it's 10x to 100x slower? Since I don't feel the difference. The jquery maker isn't dumb. They must have tried their hardest to optimize their codes.

$("#copyright") and document.getElementById('copyright') have almost no performance difference, since under the hood JQuery executes the vanilla JS statement as soon it finds # as the first character and the string has no other symbol.

If you use more advanced selector such as $(".menu-item[href='#']"), then of course it will be slow. The same slowness that you would get when you wrote vanilla JS code which achieves the same thing.

@AleCx04 Only that jQuery itself doesn't do that, and you'd expect an equivalent "datatables.js" without jQuery by now - provided that the application is simple enough to just work on the DOM itself. That is, without derailing into the infamous kind of jQuery spaghetti that actually only coincides with jQuery, but is not caused by it.

That's only a small part of why the web still feels sluggish although today's mobiles are as powerful as full-blown PCs in the past. Because people don't give a rat's ass at every corner you can see, at those you can't see, and then some.

@daniel-wu Depends on the complexity of the DOM and the selectors you use, but yes, 10x to 100x is what the benchmarks showed over and over.

That's not even mentioning that jQuery is popular for abusing JS to do things that shouldn't be done in JS to begin with.

@AleCx04 No.

But the sole purpose of JQuery was to do what ECMAScript did:

Provide common glue code plus browser compatibility hacks in a single library.

Modern stack can mean ECMA Script - which in turn can be far more secure and better maintained than JQuery is.

The downside of JQuery is exactly that JQuery predates ECMA Script...

Many rather shady hacks to achieve compatibility are in JQuery that are not necessary anymore... Or can be dramatically simplified.

It doesn't have to be VUE or Angular.

It could be just plain vanilla JS plus CSS.

@IntrusionCM And as I stated throughout the convo: I do not have a Kiki on my side, and I do not trust people with vanilla JS enough as of yet.

I am not disagreeing with y'all, I am just not tempted to jump on the pure JS code that people write, since pretty much in 99% of JS projects I have seen in the wild: we all have our own way of doing sh.

I don't *love it* but I will take whatever mess of JQuery people use over their JS pure solutions, any day of the week.

To me Angular is king, but that is the subject of another story.

@daniel-wu document.querySelector - does the same job though. You don't need to switch methods anymore depending on what to select.

I find the every day stuff that was better in jQuery back in the day have all been added to JS. Queryselector, classList, classList.toggle, better Array methods, more Dom methods like append/prepend, fetch, more syntactic sugar, easier chaining etc. Combined with css animations becoming easier and better which I felt reduced the need for stuff like fadeIn

Gotta give jQuery credit though for its plugin Eco system. Something like dataTable was pretty much standard and everyone knew it - I'm sure there's dozens of similar vanilla libs but none that is as widely known as dataTable was.

If someone wants out of jQuery but feels to comfortable with the small things like the syntactic sugar - start using Node.

Once you start using more vanilla JS you'll just get annoyed at the tiny differences. After using forEach you'll start to dislike jQuery's each with the weird argument order of having index before value. And sooner or later feel like "since I'm writing plain JS on the server just fine it's superfluous to have jQuery on the client"

Between jquery and react, I really hope that something in rust ecosystem take care of this, maybe yew can shine one day

@AleCx04 well, i'm excited about blazor. just waiting for an appropriate project to get my feet wet.

@tosensei I have been playing with it for a bit, I really like what I see thus far, but we will see how it changes in the future.

I have also been bitten by the C# crave for quite a while, so hopefully it matures fast and provides a sane alternative. I *do* trust C# devs far more than I do JS devs.

@AleCx04 my hopes are for blazor server and blazor WASM to merge - combining the performance and scalability of one with zero-effort backend-access of the other.

@ericprog Obviously, it's not about using Vue or React vs. using jQuery. The objectives are very different.

The choice is dropping jQuery in favour of plain vanilla JS. You don't need jQuery anymore. At all.

@ericprog Vanilla JS isn't a lie. It's the native language of your browser. jQuery itself doesn't do anything useful.

Sure, there are libraries which in turn build upon jQuery, and they can do useful stuff - but that's the point, that they still rely on jQuery although that dependency should have been eliminated years ago.

@ericprog You for once didn't even know the difference between jQuery and frameworks such as Vue until today. Don't complain about being educated - you're in dire need of it.