
Ask HN: Is jQuery still a thing? - linkula
With so many &quot;new&quot; js frameworks (like React, Vue.js, Mithril,..) and js-like languages (Elm, Dart, TypeScript,..) is classic jQuery still taken as something good and recommended to use for the front-end? Or should it by replaced by something else? Maintainability and minimum of errors are more relevant for me than raw speed or &quot;hype&quot;.
======
dabernathy89
Absolutely. Most projects that would be considered "websites" rather than "web
applications" are likely candidates for jQuery. It's still extraordinarily
useful.

~~~
throwaway420
This.

Pick the right technology to solve the problem you're trying to solve.

Some inexperienced devs just try and cram every single technology they've ever
heard of into a simple project when it's not needed. You're not at Facebook's
scale just yet where many of these abstractions are anything other than an
extra complication and a waste of time and future liability.

Your average simple website for a law firm, bike repair shop, or a pizza
delivery place doesn't need 93 different
libraries/frameworks/technologies/build systems/etc to show/hide a couple
products or submit a form or two. You can go pretty far with just jQuery in
many cases.

It gets a little more complicated as you go from simple site to more complex
site to app to more complex app, but I see too many developers trying to be
trendy and over engineering simple problems and wasting a lot of time and
money.

~~~
craigvn
I was going to say the same thing. If you are building an app something like
Angular is great. But for a website that needs to be simple, fast and easy to
maintain then jQuery still works well.

------
tomcam
Do you know a better library for support of a wide array of browsers going
back many years, with a huge log of support issues and test cases behind it?

~~~
aggronn
jQuery doesn't officially support IE 8 and earlier, or any other browser older
than "current - 1". React supports at least the same as jQuery.

~~~
jdmichal
[http://jquery.com/browser-support/](http://jquery.com/browser-support/)

> If you need to support older browsers like Internet Explorer 6-8, Opera
> 12.1x or Safari 5.1+, use jQuery 1.12.

------
rexbee
Looks like ~70% of the top million sites are using jQuery

[https://nerdydata.com/search?query=jquery](https://nerdydata.com/search?query=jquery)

------
jressey
Given that most applications are actually not public facing and do not require
'slick' UIs like we're getting with the new frameworks, I think it will
continue to be the choice for utilitarian shops that want to produce easy to
maintain stuff quickly. I will certainly admit that it crumbles under its own
weight in large apps, but I will continue to evaluate it as my first option
when building. Disclaimer: I make my living on the back-end.

------
headcanon
It depends on what you're doing, and what you're comfortable working with. If
you have page content that is largely rendered server-side, with bits of
interactivity and some basic AJAX on the frontend, jQuery's your friend. If
you want to build a single-page application that rests mostly or entirely on
the frontend, thats what the newer frameworks and methodologies are designed
to do, and you're better off going with one of them.

~~~
linkula
OP here: I'm a back-end dev working on an internal company site. I have used
jQuery for the past years for things like simple AJAX and manipulationg
dropdowns. Recently I had to build an AJAX heavy part of the page, and got a
bit lost in callbacks and DOM manipulations (1500+ lines already). There is no
real reason to re-code everything, now it's working, but after seeing all the
new shiny frameworks, I started to question my ability to maintain the code of
this specific page ("Wouldn't this framework be better and easier to
read/debug/extend?"). Still, don't know if one javascript-heavy page is enough
to bring a new framework in the project and start over again.

~~~
asciihacker

        > I had to build an AJAX heavy part of the page, and got a bit lost in callbacks and DOM manipulations
    

Have you missed all the posts on intercooler.js -
[http://intercoolerjs.org/](http://intercoolerjs.org/)

------
darrelld
jQuery might not be the fancy new hotness on the block, but it still works and
is still used.

I get the feeling more and more that developers are embarrassed about using
it, similar to how some devs are embarrassed about using PHP, yet it's still a
workhorse.

~~~
labster
PHP should be significantly more embarrassing than jQuery. The jQuery
interface is well designed and reliable.

The fact that it still works is important. As long as I've got clients asking
for IE 8 support, jQuery's going to be in my toolbox. And probably even after.

~~~
tjons
Ouch. PHP dev here. We write design-pattern-influenced code with classes,
abstract classes, DI, interfaces, etc. It's not all bad.

~~~
brandon272
You know, it's been well over a decade of seeing the anti-PHP stuff and I
still have yet to see a "PHP is evil" argument that doesn't fall apart after a
little scrutiny. I proudly use it and am happy to look at it's usage vs.
alternative languages in any of the real-world projects I've developed.

------
sdegutis
Yes, jQuery is good and most people still use it. It does its job perfectly
fine. The thing is, HN is a very small like-minded community of people who are
always looking for something better than the status quo, which is why you're
always seeing news about things like React and Vue, etc.

~~~
Pica_soO
In the discussions we are a very small sub-sub community of very realistic
pessimists who share the experience of having lost a arm and leg to
technological minefields during the hype-wars.

~~~
sdegutis
Best explanation I ever heard.

------
erikb
Very simple and as always it depends on what you want. You want to do the cool
new thing? Then use one of the younger frameworks but expect things to be
slow, buggy, and ungooglable. If you want to make money wiht little effort
then use the older frameworks that survived (e.g. jquery).

~~~
newbear
How does one make money? Help please

~~~
bbcbasic
1\. <script
src="[https://cdnjs.cloudflare.com/ajax/libs/jquery/3.1.1/jquery.m...](https://cdnjs.cloudflare.com/ajax/libs/jquery/3.1.1/jquery.min.js"></script>)

2\. Profit

------
scabbycakes
For _web apps_ I would use anything BUT jQuery.

For adding simple functionality to a _web page_ , I would probably ever ONLY
use jQuery. (Assuming plain js was going to be a hassle.)

FWIW I haven't used much jQuery for about the last 3 years, and all I do is
web apps all day every day. The day I discovered Knockout (as the gateway
drug) was the day life got exponentially better.

------
grayrest
The only use case for jQuery is if you want virtually all your logic and
rendering to be server side and only want to use javascript for toggles, form
checking, or other jQuery sprinkles. I wouldn't choose this but if someone did
and picked jQuery I wouldn't question the jQuery part much.

If you're writing more than a couple hundred lines of javascript, the jQuery
model of putting your application state in the DOM is inferior to pretty much
any other application model. There's a reason everybody went to Backbone and
then to the component libraries. Separating your model and rendering concerns
and delegating the latter to your framework roughly halves the amount of code
you need to write.

~~~
city41
Not to mention storing app state directly in the DOM can have performance
implications, as JS needs to cross the bridge and possibly force relayouts to
access the state info.

------
adimov
Popular doesn't mean good. Check out modern pop music or American president
(joke).

jQuery is ok for super simple sites, but modern interfaces becomes more and
more interactive and complex. Attempts to organise some logic via imperative
jQuery way usually turns into hell. So, first of all it isn't scalable.

Btw, I wrote an article how Vue.js can replace jQuery for "websites", not only
for "web applications": [https://medium.com/@borisadimov/vue-js-the-second-
breath-of-...](https://medium.com/@borisadimov/vue-js-the-second-breath-of-
multipage-apps-3f75818514f2)

------
carsongross
Of course it is!

The way I build web apps is to use intercooler.js (which is built on top of
jQuery) for my AJAX and then jQuery, or jQuery-based plugins, for UI needs.

Works great. Yes, the jQuery API has some aspects that haven't aged all that
well, but it's a pretty well thought out and through library that provides
great tools that should have been baked into all browser environments since
the start, and that has a rich ecosystem around it to boot.

The jQuery haters are usually folks who tried to write an SPA with it, which
they say, correctly, is a terrible idea. But then, building an SPA is usually
a terrible idea as well.

~~~
commentzorro
_> But then, building an SPA is usually a terrible idea as well._

Would you care to elaborate on this? I'm interested in why.

~~~
carsongross
I was obviously being flippant, but a long story short is that going to a
JSON-based, RPC-style SPA app gives up a lot of the advantages of the original
RESTful web network architecture, not the least of which being simplicity.

Long-suffering HN readers can skip all of this (sorry guys) but I expand on
this in the following blog posts:

[http://intercoolerjs.org/2016/01/18/rescuing-
rest.html](http://intercoolerjs.org/2016/01/18/rescuing-rest.html)

[http://intercoolerjs.org/2016/02/17/api-churn-vs-
security.ht...](http://intercoolerjs.org/2016/02/17/api-churn-vs-
security.html)

[http://intercoolerjs.org/2016/05/08/hatoeas-is-for-
humans.ht...](http://intercoolerjs.org/2016/05/08/hatoeas-is-for-humans.html)

~~~
commentzorro
All of these seem to imply discoverability and queries are the biggest pain
point in web apps. For me, in creating specific purpose business apps, the
biggest headaches are presenting the data in ways that minimize the user's
unnecessary actions and, even more of a pain, wiring things up so an event in
one location triggers the proper client display changes in another location.

For my use cases, discoverability and ad hoc queries just don't apply.

~~~
carsongross
Mmm, this is probably a long conversation, but I don't disagree with what you
are saying. I think discoverability (in API terms) is different than the
flexibility that HATEOAS, with a proper hypertext gives you.

The query issue just depends on how complex your data consumption needs are.
The closer they get to levels requiring SQL-levels of expressivity, the more
you will need to either churn your API or expose expressivity (and security
risk) on the browser side.

In the old days, the way we dealt with changing the UI in another location was
by simply replacing the whole page. This actually works pretty well, except
for those FOUCs, and we are heading back that way, but now people are starting
to do DOM diffs to avoid the blinky-blink. intercooler has a few options for
solving it as well (either expanding your replacement target or using
dependencies.) I imagine eventually I'll end up adding DOM-merging as an
option as well.

Anyway, it's a long conversation.

~~~
commentzorro
_> I imagine eventually I'll end up adding DOM-merging as an option as well._

This will be nice. I was playing with some of the examples on the site and
noticed a number of them tended to "jump" a bit when the response was
returned.

------
Bjorkbat
I think it's still super userful.

I'm an Ember developer myself, and I love it, but there's no way in hell I'd
use it for a small website. For that matter, I wouldn't use React or Angular
1.x either (I haven't had to do any project in Angular 2.x yet, so I don't
really have an informed opinion yet).

So, that out of the way, next up is jQuery, which I think is still a perfect
fit for smaller projects. The fact that you can just use it, without having to
worry about any real initial prep-work, or having to compile anything, is
almost kind of magical in this day and age.

------
markplindsay
React is my only choice for single-page apps, but it's unnecessary for
ordinary JS UI widgets on a mostly server-rendered site.

For UI elements that have a lot of internal state, React can remove a ton of
complexity. However, the delay between initial page render and the React
component rendering itself can sometimes be distracting when those elements
are key parts of the UI. This is a solved problem if you're using Node on the
server, obviously, but if you're rendering pages with other server-side
technology it is a drawback to React. jQuery does not have these issues as it
just attaches itself to the server-rendered markup.

------
trose
[https://www.npmjs.com/package/jquery](https://www.npmjs.com/package/jquery)

2.3 million downloads in the last month and 4883 dependencies... what do you
think?

------
arxpoetica
This is useful:
[http://youmightnotneedjquery.com/](http://youmightnotneedjquery.com/)

------
chmln
It all depends on your needs.

The frameworks you mentioned are not exactly in the same "niche" as jQuery,
which encapsulates a friendly way to manipulate DOM, make ajax requests, etc.

However, if maintainability is your focus, write in plain js as much as
possible. Frameworks come and go. Code written in ES5 will still work in 5
years from now, while jQuery code may get at least partially deprecated.

------
sharmi
I have been using query in one of my projects. For me support of IE 8 and
older is not an issue but support of mobile users is. So I have replaced
jquery with vanilla JavaScript. I found the page performance to be noticeably
better. It was also easy to keep the necessary JavaScript functions in mind,
compared to jquery, not to mention the reduction in js file size.

------
2bluesc
As an embedded systems guy, Hackernoon [0] tells me that nobody uses jQuery
anymore:

> -It’s 2016 man, no one uses jQuery anymore, it ends up in a bunch of
> spaghetti code. Everyone knows that.

[0] [https://hackernoon.com/how-it-feels-to-learn-javascript-
in-2...](https://hackernoon.com/how-it-feels-to-learn-javascript-
in-2016-d3a717dd577f)

------
pragmatic
Yes.

1\. There are some edge cases where it is still useful and it would be way
more painful to reimplement it in vanilla js (though maybe still possible).
But in these edge cases why bother when:

2\. In any largish project invariably _something_ will require jquery. Think
Bootstrap or some widget library the boss/users absolutely want or something
some "UI" person built themselves.

------
kristopolous
Keep it simple. Being clever usually leads to making things buggy. Unclever
and boring makes things reliable and sustainable.

------
sheeshkebab
"websites" still mostly use jquery,

"webapps" typically use a concoction of 100+ js frameworks/plugins, including
one of angular/react/ember/backbone (or in some really hotness of the month
type places - more than one of those).

it's of useful to know jquery, just to keep things simple when you can.

------
q3r3qr3q
Even angular used to/still comes with a jQuery-lite object you can use if you
aren't already including jQuery. The new frameworks don't replace _everything_
jQuery does.

------
yread
What's worse even IE7 is still a thing!

------
british_india
Every other framework relies on JQuery so--yes, absolutely--it's still a
thing.

And if you don't work for a company that is in the JavaScript-framework-of-
the-month mode, you should know JQuery is still king.

~~~
georgedrummond
> Every other framework relies on JQuery

This just isn't true. OP mentioned React, Vue.js, and Mithril. None of these
use jQuery as a dependency. Neither does Angular, Backbone, or Ember.js.

~~~
Rumudiez
Angular 1.x uses a version of JQ Lite, and will utilize jQuery if it's already
loaded on the page.

That being said, I don't think knowing jQuery is very valuable for JS
developers anymore. Browser standards have come a long way and frameworks are
handling your DOM writes for you, so that major use case for jQuery is gone in
any website that requires substantial scripting.

~~~
gremlinsinc
Really? what if you have to support legacy apps that are 100% jquery on the
frontend / php on the back? It's VERY much still a thing..

------
acedinlowball
Mithril and Vue are not new.

Of course jQuery is still a thing.

Can I ask how old you are, linkula? This seems like a question a 13 year old
would ask.

