
Ask HN: Does anybody still use jQuery? - jsnathan
I know that frameworks such as React and Vue have taken over most of the mindshare, but I still find jQuery easier to use and often more productive, especially for smaller websites.<p>Even when using a framework I usually include jQuery to smooth out the edges where the framework does not behave as I would have expected, or seems to make implementing a part of the intended UX awkward or complicated.<p>Is anybody else still relying on jQuery in some capacity, and if so, what value do you get out of it? Do you use it along with one of the major frameworks, or together with smaller libraries? And do you plan on dropping it soon?
======
sheraz
Yes, and I love it.

In hindsight I have been guilty of resume-padding and falling prey to hype by
choosing to build on technology not appropriate to the problems at hand. And I
find myself reverting back to basics, with bits of new tech sprinkled in.

My reversions:

    
    
      - React, flux, redux ---->  jQuery and intercoolerjs when needed
      - Swarm, Kubernetes  ---->  Just plain old docker on single machine, scale vertically with cores and memory when needed
      - Microservices first ----> Django Monolith first, then break out microservice when needed
      - API Gateways (kong, Azure) ----> Nginx reverse proxy with hand-edited configs.
    
    

I can do this because I have chosen to work on niche problems and smaller
markets. Scale is not my issue, even in very successful scenarios.

I see jQuery will have a place in my stack for some time to come. It just
works (tm), and it plays well when I need to level-up with wither intercooler
or yes -- backbone.

Another benefit is that it is a low barrier to entry for junior developers. It
allows me to establish a baseline knowledge, and then mentor other things like
workflow, code structure, and architectural things rather than chasing weird
configuration things inside of webpack or the taskrunner-du-jour.

~~~
aserafini
Your reversions resonate with me very strongly, even down to the exact tech
choices. While the industry seems to chase ever increasing complexity, I
believe 90% of web applications would be served more than adequately by
jQuery, intercoolerjs and Django running in a single container that can scale
horizontally if necessary on Elasticbeanstalk. (eb deploy.. Done).

But, sadly, it feels like openly selling yourself as a consultant in these
technologies would be a form of sabotage and limit your opportunities
considerably.

I've just had an idea for branding myself: artisinal, vintage web development
using traditional jQuery / Django. :)

~~~
mpfundstein
I might agree with you and your parent. My objection would be that I all too
often experienced that seemingly small projects turned out to grow into huge
applications. And previously accumulated tech debt is hard to get rid off. So
I mostly start out now with my own boilerplates. React + Redux is one git
clone command. Docker including Service Discovery (Traefic, Registrator),
RabbitMQ and MongoDB is another git clone [1]. So I am productive immediately
and the right tech is in place.

Regarding the discussion Micro-Service vs Monoliths. I agree that a monoliths
gets you started quicker. But it also asks a lot of discipline from the
programmers. E.g. 'stick to your domain boundaries', 'Don't take that shortcut
of direct db access because business needed the feature yesterday', etc.
Otherwise you'll have big troubles splitting it up later on. [2].

I REALLY REALLY REALLY like that micro-services make your boundaries explicit
and enforce you to write contractual APIs aka Interfaces. Much more than all
the promises of scalability etc.

[1] [https://github.com/MarkusPfundstein/microservice-service-
dis...](https://github.com/MarkusPfundstein/microservice-service-discovery)
[2]
[https://martinfowler.com/bliki/MonolithFirst.html](https://martinfowler.com/bliki/MonolithFirst.html)

~~~
sheraz
Question - how long does it take for your projects to “grow into” the stack
and complexity you have scaffolded up around it?

~~~
mpfundstein
If I look at the last two, it was 6 month and 9 month. The first one was
initially thought to be just another search engine for some of the company's
content. Then it got transformed into the main data store including CMS and
all those nicetees. In the end, 7 people worked on it. The second one was a
tool used only internally by my customer's employees. They then sold the idea
to some of their customers and it had to transform into a full fledged
product. 4 people are now in charge of it.

I am still coming back to projects sometimes where I didn't do this and I hate
every minute hacking on them -.- 'Wish I would have just used React or
whatever' are often my thoughts then :-)

~~~
mattmanser
How are those big projects? Why would you need any scalability for that?

From what you just said they're running for, at most, a few thousand people.

In terms of loads/numbers/etc. that's child's play and definitely not "huge
applications". The kind of decisions he's talking about are for things with
thousands of concurrent users per second, not per day.

That kind of stuff could be dealt with a single desktop computer running PHP
and mysql. And you definitely don't need microservices.

In my experience, having worked in both enterprise and consumer startups,
enterprise is shallow but broad with little need for any of the complicated
stuff and more need to make the code really simple, obvious and uncomplex
because it ends up dealing with so many different problems, while consumer
scale is where you start needing to get a bit fancy purely because of scale,
but it only deals with a couple of problems.

~~~
mpfundstein
To quote myself regarding micro-services: "I REALLY REALLY REALLY like that
micro-services make your boundaries explicit and enforce you to write
contractual APIs aka Interfaces. Much more than all the promises of
scalability etc."

With huge applications, I mean 10s of thousands of lines of code with features
added on a daily basis by multiple developers.

What both have in common is that they started us as seemingly small 'throwaway
tools' but grew into business scale applications that serve now a core
purpose.

Btw, who said I didn't use MySQL and PHP ? :D

~~~
mattmanser
Again, "10s of thousands" of lines of code is nothing. It's a few months work.

Introducing microservices into a small code base feels like it would be
counter-productive. It adds a ton of unnecessary complexity to a tiny code
base.

You don't _want_ contractual APIs for code like that, as it grows the
contracts are going to be constantly breaking as new features are added and
the only people who care are the other, internal, developers.

If you used a statically typed language, in a monolith it would tell you
immediately that it had happened as soon as you did your sync (which should be
happening multiple times a day for everyone). Better still, the other
developer would have had to deal with it, the only code you'd need to worry
about is the new code you added, and again, your check in would break the
build.

Code how you want, but my mind boggles at people doing microservices for tiny
code bases. Much better to have a monolith until you get into the million of
lines.

I am just thankful I work on statically typed monoliths where my tools just
deal with it and I don't have to spend time setting up and debugging
microservices instead of doing actual work.

~~~
mpfundstein
“You don’t want ...”

Thanks for telling me what I want :-) I also worked on statically typed
monoliths (.Net)! I also worked on micro service systems (>70 services, 2
years of work) written in NodeJs.

It all has its pros and cons.

------
ukulele
I would be surprised if a majority of new projects with a JavaScript library
_weren 't_ using jQuery. I personally moved on a few years ago and I suspect
that's the case with many people who respond on HN, but there are still plenty
of valid use cases, particularly when JS needs are simple and backwards
compatibility is really important.

If you're doing projects with light functionality and already know jQuery
cold, you really don't gain much from React, Vue, et al for that project. You
may gain something personally (career path, different way of thinking, etc),
but that is a different topic.

For anything slightly above the basics, I'd recommend Vue as a great
alternative to jQuery. No build tools required and it's easy to stay in the
realm of plain HTML, CSS, and JS. It also "progresses" really nicely if you
have more complex needs later on -- that would be a main benefit over a tool
like jQuery.

------
Vinnl
What you used jQuery for hasn't so much been replaced by React and what not,
as it has by native Javascript. Most of the things you used to do through
jQuery are done with regular Javascript (and DOM API's) just as easy nowadays
- depending on your browser demographics, of course, but will be fine most of
the time.

------
INTPenis
Of course. We're not all mobile app developers on HN. Some of us still make
small info sites, or prototypes. And me, I'm actually a backend sysop but my
hobby of developing websites keeps me branching out. So I've never developed a
web/mobile app with a framework, and still use jquery for simple websites.

------
ronreiter
You are right that jQuery is dying:

[https://trends.google.com/trends/explore?date=today%205-y&q=...](https://trends.google.com/trends/explore?date=today%205-y&q=jquery)

5 years ago, jQuery was twice as popular than it is today. But I wouldn't call
it dead just yet. It's a work in progress.

By the way - one of the things that killed jQuery is HTML5, it's not only Vue
and React for more advanced features, a lot of people used jQuery for basic
DOM manipulation, which today you can probably get away with just fine with
the HTML5 DOM API, since the addition of the querySelector APIs and things
like CSS's classList APIs.

------
quantumleap22
Yes, for almost all projects I work on due to the plugin ecosystem. If size is
a concern I will look at zepto, a smaller 80/20 implementation of the jQuery
API. And I almost always use intercooler.js to keep my js footprint small.

------
floatboth
querySelector + classList + CSS transitions + fetch absolutely destroyed
jQuery.

And Web Components are starting to destroy jQuery Plugins.

------
terelak
The company I work at uses jQuery for most DOM manipulation. I'm a backend
developer and already knew it a bit so it's easier for me than using React for
simple things. I don't do any frontend outside of work, so I've never gone
past the React tutorial on my own time, and I suspect many mainly-backend
developers have a similar story.

------
zabowl
Yes. I use it especially for Wordpress custom themes or small websites or web
apps that rely on DataTables.

------
hambos22
It depends on the project. For web applications and SPA I prefer using React.
For ecommerce and smaller projects, the stack is jQuery for cross browser (and
old browser) compatibility with the minimum effort.(And Vue for some commerce
components like minicart, quickview etc)

------
Macha
Not so much. It's lost out at both ends. Larger projects end up with Vue (and
before that Angular), and smaller projects end up with just VanillaJS due to
support for APIs like document.querySelector(), window.fetch(), <input
type="date">, etc.

------
rajangdavis
I stopped using jQuery after I started a rather large Angular project 2 years
ago.

Since then, I had one project where using jQuery and jQuery UI was
dramatically easier than building out a datepicker input by hand; however, for
everything else, vanilla js is my go to.

------
kylorhall
Almost every older project I've worked on uses jQuery. Currently working on a
large Rails app, some parts being 10 years old, and it's the same story. Old
code is jQuery, new code is not.

It was spectacular 10 years ago, but now it's pretty much useless to me. Most
everything either shouldn't be done in javascript or has a native replacement
– at least with polyfills and Babel that I need for all development. I would
love to remove it, but it would take far too long and provide little customer
benefit (remove the library download), so it's only removed when something is
refactored.

------
CosmicShadow
I just use JQuery and a few other libraries as needed as I use ASP.NET MVC so
that takes care of the backend, no need for ugly, complex JS, keep it as
minimal and simple as possible. If things need to be done more intensely in
front end I use Knockout which seems to be very good at what it does and
doesn't muck it up by offering more than it needs or is meant for.

------
no1youknowz
I'm using jQuery for a platform that I am launching very soon. The
javascript/jQuery portion of it currently stands at 63k LOC. I would not be
surprised when I finish, it'll stand at over 100k LOC.

If I look at the number of open source 3rd party js libs that support it, they
are around 180k LOC.

Eventually, I do see a project that ports over the entire js code over to ES6
and Vue.

------
i_dont_know_
Absolutely! Different tools for different projects. If I'm building a 'real'
webapp (as in, something with users logging in and lots of data dependencies)
I'll use something like React, but if it's a small project... it's not at all
worth setting up the infrastructure and maintaining it when a few lines of
jQuery will do the job.

------
mythrwy
Yes. I think it is faster to develop in general for small sites.

When it becomes very much not faster is when you have a bunch of jQuery poorly
(or "customly") organized and someone else has to wade back through.

Vue is awesome though, really liking it. Sometimes I use Vue and jQuery
together to take advantage of jQuery plugins. Does this make me a bad person?

------
simion314
Yes, it is a good tool for one of my projects where I need to cleanup some
html, is very good for DOM manipulation. It is also a very good tool for
simple webpages, If I have some mostly static thing that I need to show I can
render that on the server with PHP and have jQuery insert it on the right
place and handle some events,

------
scarface74
Yes. I'm currently using JQuery+HandlebarsJS as a poor man's model view
framework. I create the interface with Handlebars + Bootstrap, use JQuery to
call an api when necessary. The template also has the necessary JavaScript
event/function inline.

------
siquick
Yes, still haven't really ever seen the need to use React yet.

------
tugberkk
Of course. It still works right? :) Probably there are experts on Jquery, and
although they are probably learning new technologies, when needed they rely on
their expertise.

------
paulgrimes1
I've literally only used it for .animate() in the past 6 months. VueJS came
and took over. Might be time to think about pulling jQUery out..

------
stctgion
I use it alongside Marionettejs. Not my first choice of technology but works
great for extending the framework with a plugin or two

------
throwaway180118
As a matter of fact, I write terrible Javascript all the time throw jQuery all
over the place.

My end users don't care! YMMV

------
originalsimba
"have taken over most of the mindshare"

Have you got numbers to support that? Because I think it's wrong.

~~~
jsnathan
It's only my impression, really. But I have seen a slew of articles about how
jQuery is dead, and very few people still writing articles about it's
benefits. Many libraries that use it are also unmaintained now (though they
often still work, of course).

If you want some numbers, compare e.g. the dates on popular HN posts for
jquery[1] vs react[2] and vue[3]. Most popular articles for jQuery are 4-6
years old, while for React and Vue the popular stories are much more recent.
Of course, HN might be somewhat special.

[1]:
[https://hn.algolia.com/?query=jquery](https://hn.algolia.com/?query=jquery)
[2]:
[https://hn.algolia.com/?query=react](https://hn.algolia.com/?query=react)
[3]: [https://hn.algolia.com/?query=vue](https://hn.algolia.com/?query=vue)

~~~
weego
HN represents current dev trends like reddit represents current social trends.

------
raymond888
"I know that frameworks such as React and Vue have taken over most of the
mindshare"

Marketing + meme.

