Just Use jQuery | Hacker News Reader

Just Use jQuery

twitter.com

28 pointsent10139 comments

Honest question from a backend developer:

Is it still necessary to use JQuery in 2023 instead of vanilla js? I always had the impression JQuery was more useful to decouple you from the pain of multi-browser development in the 2000s dark ages of browser standards adoption.

Not necessary, but you might like the jQuery API.

I still use it as it’s a decent way to write succinct code to access the DOM.

Makes me laugh that the same devs that claim you should use vanillaJS and that jQuery is bad are the same ones building React sites and using whatever else the latest JS trend is!

There is no need for jQuery nowadays. That said, it in still convenient. Compare:

    $(“.submenus”).hide()

    let submenus = document.querySelectorAll(“.submenus”);
    for (let i = 0; i < submenus.length; ++i) {
        submenus[i].style.display = “none”;
    }

This is a major reason why I still use jQuery instead of vanilla.

Why not this?

  document.querySelectorAll("p").forEach(e => e.style.display = "none")

Or:

    for (const e of document.querySelectorAll("p")) { e.style.display = "none" }

why not

  const $ = s => document.querySelectorAll(s);
  const hide = e => e.style.display = 'none';
  $('.submenus').forEach(hide);

or, if you're okay with changing prototypes

  const $ = s => document.querySelectorAll(s);
  NodeList.prototype.hide = function () {this.forEach(e => e.style.display = 'none');};
  $('.submenus').hide();

Ha. We actually just installed jquery in our code base recently for our Chrome extension.

I can’t remember the exact use case. We probably could have done it in raw JS, but jQuery made a bunch of things much easier. Since it’s a Chome extension, package size didn’t really matter.

It's no more necessary than Twig is compared to raw PHP.

jQuery syntax is clean, it works, why change that?

I often make a similiar joke when I am struggling with microservices related bugs or architectural designs.

1: Just use apache + php

2: Use microservices, service meshes, k8s etc.

3: Just use apache + php

Cheap joke though, although it was fun, applications and demands have changed. Especially in the environments I work in today. Although I often, as an excersize, question myself why stuff got so complicated and if this really is the way it should work. And tbh, sometimes the answer, in my opinion, is no.

Right? I had a lot of fun learning K8s for a client. Every new thing I learnt made me think it was even cooler.

Then the first maintenance came. _"Not worth it"_ doesn't even begin to cover it.

If you have both:

a) Well designed microservices that follow the 12 Factor App principals _fully_ b) A team of (minimum) five to dedicate solely to K8s maintenance

Sure, go for it. How many people using K8s can tick both of those though?

If you want something reliable, easy, and (almost) maintenance free; Just use AWS Lambda + API Gateway (or whatever Google and Microsoft equivalents you have).

Or AWS ECS instead of Kubernetes.

I'm quite happy with Vue, and the Vue HTTP component loader so I don't have to deal with the build process in Python apps.

I also quite enjoyed Svelte.

I have very little interest in touching the DOM imperatively when a declarative option exists.

I was a big advocate for “just use jQuery” amidst the JS framework hype ~10 years ago, but nowadays I agree that plain Vue hits a similar mark quite well.

Even just a naive approach of plopping a whole page in one big component or enhancing a page rendered elsewhere by mounting a few self-contained widgets on it is nicer than manually keeping track of state with events. Even my best an most concerted efforts at jQuery frontends eventually had many bugs that simply don’t happen with a declarative approach.

One downside of Vue is that you need a build system for it; I really like the ability to "just" serve files, or build things on-demand when needed (even with cache that's 20 lines of code or so).

It's just too slow and convoluted to do that (I tried), and this gets even worse with TypeScript because tsc is so darn slow to startup.

The closest I've gotten is running the JavaScript build system as a subprocess in the application itself, but meh...

You can run it with just a script tag: https://vuejs.org/guide/extras/ways-of-using-vue.html#standa...

They even describe it as a "declarative replacement for jQuery" in the docs!

How do you include all the pages and components with that? e.g. I have about 60 .vue pages and 10 .vue components. Last time I looked at this everything seemed pretty hacky and came with some pretty serious trade-offs.

I have come across this:

https://github.com/FranckFreiburger/vue3-sfc-loader

Might be worth trying. The problem is that these 3rd party libraries may work but you may end up needing a build system for a new library that you may need in the future.

I tried but for complex applications with JS, you unfortunately cannot get away from the build system.

> Vue HTTP component loader Whats this? Can you link?

I believe they're talking about single file components being lazy loaded.

https://github.com/FranckFreiburger/vue3-sfc-loader

What do mean by build process in Python Apps?

For simple, mostly-static pages, go right ahead. For dynamic pages with a lot of interactions... jQuery doesn't scale so well.

I built puter.com in jQuery and honestly couldn't be happier :')

For 95% of all websites jquery does a fantastic Job. Damn easy to manipulate the dom or some ajax stuff. No need for other frameworks.

Dynamic forms, push and page loads are part of the Rails stack. For everything else (which usually isn't a lot) I use jQuery and always have. Sometimes pure JS even.

I never got the hype honestly. However I have been happy with my stack ever since, would I be 10 years younger I may would do node and react as well.

I think a lot of people conflate "horrible state of web dev anno 2008" with "jQuery". At the time I heard coworkers talk about things like "oh, just make the variable public"; I had never heard of "public variables" in JS context before, but it wasn't my project and at the time I didn't know much about JS so I just assumed there was a gap in my knowledge. When I later took over the project I discovered that "public variable" meant "put window. in front of it".

I'm not saying jQuery or vanilla JS (which is the same thing, just a different API) is the end-all of everything, but with a bit of care and organisation it's not too hard to make dynamic "modern" sites and even web apps that are fast and can be maintained fairly easily. It is easy to make a mess of things though, as it doesn't guide you through a "framework" and especially in larger teams with different experience/skill levels this can be an issue.

At the end of the day I think this is a "Python vs. Ruby" type of discussion, where both can obviously work well, but both obviously also have their own strengths and weaknesses.

I dislike a certain section of the frontend crowd who thinks that going full-in on WebPack+React+TypeScript+1561 dependencies is the only possible way to build something useful and derides anyone who disagrees (at some point someone called me "the anti-vaxxer of frontend development" over this).

jQuery is the "just works" of Javascript. There's no build step required, it's plug 'n play.

jQuery and PHP's ease of integration was what helped get me from HTML + CSS to interactive websites.

Long may they continue.

depends on what you're building, but you could do worse

i've seen a ton of react apps that had no business being react apps

Reactive frameworks are the best. It is so much easier than having to handle events. I also find it way easier to work with a component based framework for complex UIs.

I have 2 production Svelte projects completed, and it is a charm to work with.

Or just use vanilla JS

Or just don't use JS

Modern CSS and HTML's built in elements are better at a lot of the things people use JS for.

I think as coders we feel most comfortable reaching for JavaScript first, when really we should be doing as much in HTML itself as possible, then prettying it all up with CSS, and then finally adding some JS for interactivity such as client side form validation.

Indeed, and even a lot of client side form validation can be done using HTML and CSS: https://developer.mozilla.org/en-US/docs/Learn/Forms/Form_va...

It’s pretty limited, though, and has some random quirks. Like a required field will be marked as invalid immediately on load, or that it’s not really possible to display multiple errors on a single input.

You can work around them, but you’re approaching the complexity of just writing your own validator by that point.

I like being able to do elem.remove() instead of elem.parentNode.removeChild(elem), and elem.prepend(other) instead of elem.insertAdjacentElement('afterbegin', other). There's loads of stuff like this.

The DOM API does not spark joy.

Those exist now: https://developer.mozilla.org/en-US/docs/Web/API/Element/rem..., https://developer.mozilla.org/en-US/docs/Web/API/Element/pre...

Ah cheers, I didn't know that. I'll have to take a look.

Which, interestingly enough, an LLM can probably write quite well.

Reply on news.ycombinator.com