8 ms·

Just Use jQuery

28 points by ent101 3y ago

erhaetherth 3y ago
For simple, mostly-static pages, go right ahead. For dynamic pages with a lot of interactions... jQuery doesn't scale so well.
- ent101 3y ago
  I built puter.com in jQuery and honestly couldn't be happier :')
kaonashi 3y ago
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
herbst 3y ago
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.
bromuk 3y ago
Or just use vanilla JS
- Onewildgamer 3y ago
  Or just don't use JS
  - _2z1p 3y ago
    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.
    - twiss 3y ago
      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_validation https://developer.mozilla.org/en-US/docs/Learn/Forms/Form_va...
      - lelandfe 3y ago
        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.
- arp242 3y ago
  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.
  - twiss 3y ago
    Those exist now: https://developer.mozilla.org/en-US/docs/Web/API/Element/remove https://developer.mozilla.org/en-US/docs/Web/API/Element/rem..., https://developer.mozilla.org/en-US/docs/Web/API/Element/prepend https://developer.mozilla.org/en-US/docs/Web/API/Element/pre...
    - arp242 3y ago
      Ah cheers, I didn't know that. I'll have to take a look.
  - deleted 3y ago
    [deleted]
- kordlessagain 3y ago
  Which, interestingly enough, an LLM can probably write quite well.
ulrischa 3y ago
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.
BozeWolf 3y ago
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.
- ghusto 3y ago
  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).
  - slowmovintarget 3y ago
    Or AWS ECS instead of Kubernetes.
eternityforest 3y ago
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.
- macNchz 3y ago
  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.
  - arp242 3y ago
    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...
    - macNchz 3y ago
      You can run it with just a script tag: https://vuejs.org/guide/extras/ways-of-using-vue.html#standalone-script https://vuejs.org/guide/extras/ways-of-using-vue.html#standa... They even describe it as a "declarative replacement for jQuery" in the docs!
      - arp242 3y ago
        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.
arp242 3y ago
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).
debok 3y ago
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.
elzbardico 3y ago
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.
- firecall 3y ago
  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!
- srgpqt 3y ago
  There is no need for jQuery nowadays. That said, it in still convenient. Compare: $(“.submenus”).hide() vs let submenus = document.querySelectorAll(“.submenus”); for (let i = 0; i < submenus.length; ++i) { submenus[i].style.display = “none”; }
  - ent101 3y ago
    This is a major reason why I still use jQuery instead of vanilla.
  - ggx2 3y ago
    Why not this? document.querySelectorAll("p").forEach(e => e.style.display = "none")
    - WorldMaker 3y ago
      Or: for (const e of document.querySelectorAll("p")) { e.style.display = "none" }
  - gabrielsroka 3y ago
    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();
rchaud 3y ago
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.

28 points by ent101 3y ago

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

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

kaonashi 3y ago

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

herbst 3y ago

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.

bromuk 3y ago

Or just use vanilla JS

Onewildgamer 3y ago
Or just don't use JS
- _2z1p 3y ago
  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.
  - twiss 3y ago
    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_validation https://developer.mozilla.org/en-US/docs/Learn/Forms/Form_va...
    - lelandfe 3y ago
      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.
arp242 3y ago
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.
- twiss 3y ago
  Those exist now: https://developer.mozilla.org/en-US/docs/Web/API/Element/remove https://developer.mozilla.org/en-US/docs/Web/API/Element/rem..., https://developer.mozilla.org/en-US/docs/Web/API/Element/prepend https://developer.mozilla.org/en-US/docs/Web/API/Element/pre...
  - arp242 3y ago
    Ah cheers, I didn't know that. I'll have to take a look.
- deleted 3y ago
  [deleted]
kordlessagain 3y ago
Which, interestingly enough, an LLM can probably write quite well.

ulrischa 3y ago

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.

BozeWolf 3y ago

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.

ghusto 3y ago
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).
- slowmovintarget 3y ago
  Or AWS ECS instead of Kubernetes.

eternityforest 3y ago

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.

macNchz 3y ago
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.
- arp242 3y ago
  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...
  - macNchz 3y ago
    You can run it with just a script tag: https://vuejs.org/guide/extras/ways-of-using-vue.html#standalone-script https://vuejs.org/guide/extras/ways-of-using-vue.html#standa... They even describe it as a "declarative replacement for jQuery" in the docs!
    - arp242 3y ago
      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.

arp242 3y ago

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).

debok 3y ago

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.

elzbardico 3y ago

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.

firecall 3y ago
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!
srgpqt 3y ago
There is no need for jQuery nowadays. That said, it in still convenient. Compare: $(“.submenus”).hide() vs let submenus = document.querySelectorAll(“.submenus”); for (let i = 0; i < submenus.length; ++i) { submenus[i].style.display = “none”; }
- ent101 3y ago
  This is a major reason why I still use jQuery instead of vanilla.
- ggx2 3y ago
  Why not this? document.querySelectorAll("p").forEach(e => e.style.display = "none")
  - WorldMaker 3y ago
    Or: for (const e of document.querySelectorAll("p")) { e.style.display = "none" }
- gabrielsroka 3y ago
  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();

rchaud 3y ago

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.