8 ms·

>Do people still use jQuery? Oh yes. Everyday. Still love it. >…Javascript document api via document.querySelector, and document.querySelectorAll The jQuery

>Do people still use jQuery? Oh yes. Everyday. Still love it. >…Javascript document api via document.querySelector, and document.querySelectorAll The jQuery API is still (and probably aways will be) far superior to the native DOM (terser, composable, more expressive, etc). >…smaller footprint libraries like lodash jQuery is ≈30k gziped and most likely already cached from CDN. >…has fallen out of favor of more comprehensible state management inside of JS (like React Hooks, Redux...etc.) Managing state is hard. There shouldn't be much of it in any single view. IMO, React doesn't bring much to the table in this regard while adding a lot of complexity and heft. Vue is a bit better, but still, I'd much rather use jQuery if given the choice. If you're building something like Spotify/Slack, I can maybe see the need for virtual DOMs, etc. If you're sprinkling interactivity to your webpage, which is arguably what most of the web should be, jQuery is probably as good as it will ever get.

actuator 6y ago
> IMO, React doesn't bring much to the table in this regard while adding a lot of complexity and heft. Strongly disagree with this. In any complex web application with a lot of components, specially ones where a lot of fixed components can live for a while, React is definitely a massive improvement over vanilla JS or something like Backbone which allows wild west. Imagine state coming from sockets, rest APIs etc with updates being either pull or push. A user might do an action which changes the state in some other component, keeping track of the components gets hard if the state is distributed. Also, centrally managed state with things like Redux allows for good caching of API data which can make a SPA considerably fast. While I love plain HTML pages which need little or no JS, a lot of applications are better as SPAs.
- megous 6y ago
  That's more like redux and company...
  - actuator 6y ago
    Yeah, but redux etc gained traction with React, and together they make SPAs good.
    - megous 6y ago
      SPAs were perfectly good before with ExtJS and similar, and more easily extensible too.
      - e1g 6y ago
        ExtJS = "What if JSX, but in JSON" ;) For me, ExtJS redefined what's possible on the web a full decade before React/Angular & co, and it's sad that Sencha is now part of a heartless corporate graveyard.
      - tomc1985 6y ago
        SPAs were never good, the entire notion of them or shoehorning full apps into a browser is a farce. But, as parent says, that ship has long sailed
        actuator 6y ago
        Native apps definitely have advantage in some areas. But web apps give the ability to ship an app to more platforms and not be restricted by app store border control. Spotify had an Ubuntu client which never worked well, but as their web app improved I got almost the same experience as I would have on OS X or Windows web app. This gives equal chance to other platforms and to app developers as well as they don't have to play by rules like 30% cut. As long as we can ensure web browsers can be kept open on major platforms(the only exception right now is iOS), it gives more freedom and choice to non platform developers. I would be really happy if PWA support in web browsers keeps improving going forward and need for dedicated apps gets eliminated for most things.
- tambourine_man 6y ago
  I'm exactly arguing against this Webpack, Typescript, React, etc approach to web development. I'm more productive in PHP + jQuery, a lot due to familiarity, of course, but I'm also a huge believer in a simple stack. If you've 20+ mutually dependent inputs, maybe you need a better UI, not a complex state management framework. If your browser is ultimately executing an untyped crazy dynamic language, is it worth trying to shoehorn types into it, only to later transpile it back? Not to mention JSX. It all seems so crazy to me, but this ship has long sailed.
  - folkhack 6y ago
    > It all seems so crazy to me, but this ship has long sailed. Nope. And it's why Svelte is something that I've been hard adopting because it looks the closest to old-school JS/CSS/HTML while still bringing some of the same capabilities over that I love from React and VueJS. It also runs without a VDOM or a constantly running event loop - both things are incredibly attractive to me. Although it's not a perfect solution (nothing is) I would strongly suggest you checking into Svelte as it looks more like traditional web development vs. highly complex Webpack + TS + React + eslint + Babel etc etc-based development. The ship hasn't sailed. Your instincts to be weary of such a complex, constantly re-invented toolchain to get traditional development tasks accomplished are a natural response to the craziness that these tools bring to the table.
    - mixmastamyk 6y ago
      Svelte has been on my list to try, thanks for the reminder. I've also liked htmx (from intercooler) for keeping complexity managed. Any comparisons?
    - tambourine_man 6y ago
      I saw the Svelte presentation a few years ago when it was released and my jaw hit the floor hard. That was some cool radical thinking. I haven't used it beyond playing with a few examples, so I can't really tell for sure if it holds up. Everything looks great on the demos. Unfortunately it hasn't caught on, though it maybe be too early to call.
- theknocker 6y ago
  I think it's underestimated, how far you can get with a simple dispatch loop, a state tree, and some judicious OO sprinkled in for client widget-bullshit events/lifecycle. I'm not saying it's better than React, but it's underestimated.
ivosaur 6y ago
> jQuery is ≈30k gziped and most likely already cached from CDN. This part isn't so true in reality anymore, due to revised browser caching systems[1]. Doesn't mean you shouldn't use jQuery, just that part of the benefits of a centralized CDN are no longer a factor and it's a lot more sensible to self-host. 1: https://www.stefanjudis.com/notes/say-goodbye-to-resource-caching-across-sites-and-domains/ https://www.stefanjudis.com/notes/say-goodbye-to-resource-ca...
- tambourine_man 6y ago
  Right you are. But jQuery is around the same size as Vue, and that's the lean alternative to React. So the “jQuery is bloat” argument still doesn't make much sense. A single retina hero banner is larger than most JavaScript libraries/frameworks.
  - srgpqt 6y ago
    A lean alternative to React would be preact.
    - shard972 6y ago
      Or mithril
      - fragile_frogs 6y ago
        Or Inferno
        IA21 6y ago
        something something framework of the week
  - cultofmetatron 6y ago
    > and that's the lean alternative to React. Ahem https://preactjs.com/ https://preactjs.com/
deleted 6y ago
[deleted]
deleted 6y ago
[deleted]
Kudos 6y ago
Firefox and Safari use partitioned caches, and Chrome is following with the feature behind an experiment flag for now. The argument that it's probably cached from a CDN is just about dead.
1shooner 6y ago
>most likely already cached from CDN. I don't believe any major browser allows sites to share 3rd party caches anymore. Previous HN discussion: https://news.ycombinator.com/item?id=24894135 https://news.ycombinator.com/item?id=24894135
- starik36 6y ago
  True, there is still a perf win however since CDNs are located geographically closer to a global consumer than keeping the libs on your own box.
  - 1shooner 6y ago
    But don't modern frontend-oriented sites/apps deploy to CDNs anyway?
  - r1ch 6y ago
    Self-hosting is no longer the performance drain it used to be now that HTTP/2 is a thing, as soon as the browser parses the page, the JS file is only 1 RTT away. Using a CDN for a single asset like jQuery requires a DNS lookup, TCP connection and TLS negotiation - that's 3 RTTs plus unknown latency from the user's resolver before the HTTP request is even sent. The performance difference in the single request scenario is likely negligible and the benefits of not relying on a 3rd party can outweigh the latency savings.
enraged_camel 6y ago
I used to write a lot of JQuery, and I've switched to Vue three years ago. Occasionally I have to go back and write more JQuery, and it makes my head hurt. edit: why the dowvotes? are we not allowed to share our experiences now?
- Zelphyr 6y ago
  I know we're not supposed to discuss voting but people downvoting someone simply because that person said something disagreeable, yet still within the rules of Hacker News, is becoming a serious problem in my opinion. I'd like it just fine we get rid of downvotes altogether.
- babypuncher 6y ago
  Trying to write any kind of complex interactivity with JQuery event handlers is a serious pain in the butt, and it's so hard to go back and read. I did the same as you; moved on to Vue and haven't looked back. My frontend code is so much cleaner and easier to debug. I've built a large library of components, so often times adding a new page only takes a couple hours re-using those instead of writing a bunch of new JQuery from scratch. JQuery is great when I need to make (non-contentful) changes to the DOM. But I refuse to use it for managing the state of my app or putting content in UI components.
deleted 6y ago
[deleted]
steviedotboston 6y ago
I agree with this 100%. Even though "vanilla JS" is more powerful now, JQuery is still much easier to work with.
pseudosavant 6y ago
"The jQuery API is still (and probably aways will be) far superior to the native DOM" The jQuery API really is so well done. I stopped using jQuery, but implemented a simple script (jSugar.js) that exposes many basic jQuery things but is really just a wrapper for native DOM operations. It only operates on individual DOM nodes. Any looping should be done using your JS loop of choice (forEach, for loop, which, etc). The script started out really small. I've slowly added more and more as I need more functionality for some projects. https://gist.github.com/pseudosavant/b86eedd9960ade958d49447130c95811 https://gist.github.com/pseudosavant/b86eedd9960ade958d49447...
- _ZeD_ 6y ago
  > The jQuery API really is so well done. I stopped using jQuery, but implemented a simple script (jSugar.js) that exposes many basic jQuery things but is really just a wrapper for native DOM operations. so... like jQuery?
  - pseudosavant 6y ago
    No, because jQuery normalizes all sorts of DOM stuff. Part of the reason it is 30kb. What I've done is basically syntatic sugar and is only 74loc.
cphoover 6y ago
Smaller footprint in my mind doesn't refer to download size which is minimal in either case but the footprint or impact on a project. IMO It is way harder to move off of jquery once it has been fully utilized throughout the project than to swap a single function to/from lodash once a core API has a better way of handling it. Using JQuery demands you buy into the whole ecosystem whereas Lodash is modular. Also as others have mentioned caches are individually isolated for each domain now to prevent tracking/data leaks.
thatsnotmepls 6y ago
> If you're building something like Spotify/Slack, I can maybe see the need for virtual DOMs Heck, even Slack was built with jQuery the first time. Only after a while they migrated to react.

actuator 6y ago

> IMO, React doesn't bring much to the table in this regard while adding a lot of complexity and heft. Strongly disagree with this. In any complex web application with a lot of components, specially ones where a lot of fixed components can live for a while, React is definitely a massive improvement over vanilla JS or something like Backbone which allows wild west. Imagine state coming from sockets, rest APIs etc with updates being either pull or push. A user might do an action which changes the state in some other component, keeping track of the components gets hard if the state is distributed. Also, centrally managed state with things like Redux allows for good caching of API data which can make a SPA considerably fast. While I love plain HTML pages which need little or no JS, a lot of applications are better as SPAs.

megous 6y ago
That's more like redux and company...
- actuator 6y ago
  Yeah, but redux etc gained traction with React, and together they make SPAs good.
  - megous 6y ago
    SPAs were perfectly good before with ExtJS and similar, and more easily extensible too.
    - e1g 6y ago
      ExtJS = "What if JSX, but in JSON" ;) For me, ExtJS redefined what's possible on the web a full decade before React/Angular & co, and it's sad that Sencha is now part of a heartless corporate graveyard.
    - tomc1985 6y ago
      SPAs were never good, the entire notion of them or shoehorning full apps into a browser is a farce. But, as parent says, that ship has long sailed
      - actuator 6y ago
        Native apps definitely have advantage in some areas. But web apps give the ability to ship an app to more platforms and not be restricted by app store border control. Spotify had an Ubuntu client which never worked well, but as their web app improved I got almost the same experience as I would have on OS X or Windows web app. This gives equal chance to other platforms and to app developers as well as they don't have to play by rules like 30% cut. As long as we can ensure web browsers can be kept open on major platforms(the only exception right now is iOS), it gives more freedom and choice to non platform developers. I would be really happy if PWA support in web browsers keeps improving going forward and need for dedicated apps gets eliminated for most things.
tambourine_man 6y ago
I'm exactly arguing against this Webpack, Typescript, React, etc approach to web development. I'm more productive in PHP + jQuery, a lot due to familiarity, of course, but I'm also a huge believer in a simple stack. If you've 20+ mutually dependent inputs, maybe you need a better UI, not a complex state management framework. If your browser is ultimately executing an untyped crazy dynamic language, is it worth trying to shoehorn types into it, only to later transpile it back? Not to mention JSX. It all seems so crazy to me, but this ship has long sailed.
- folkhack 6y ago
  > It all seems so crazy to me, but this ship has long sailed. Nope. And it's why Svelte is something that I've been hard adopting because it looks the closest to old-school JS/CSS/HTML while still bringing some of the same capabilities over that I love from React and VueJS. It also runs without a VDOM or a constantly running event loop - both things are incredibly attractive to me. Although it's not a perfect solution (nothing is) I would strongly suggest you checking into Svelte as it looks more like traditional web development vs. highly complex Webpack + TS + React + eslint + Babel etc etc-based development. The ship hasn't sailed. Your instincts to be weary of such a complex, constantly re-invented toolchain to get traditional development tasks accomplished are a natural response to the craziness that these tools bring to the table.
  - mixmastamyk 6y ago
    Svelte has been on my list to try, thanks for the reminder. I've also liked htmx (from intercooler) for keeping complexity managed. Any comparisons?
  - tambourine_man 6y ago
    I saw the Svelte presentation a few years ago when it was released and my jaw hit the floor hard. That was some cool radical thinking. I haven't used it beyond playing with a few examples, so I can't really tell for sure if it holds up. Everything looks great on the demos. Unfortunately it hasn't caught on, though it maybe be too early to call.
theknocker 6y ago
I think it's underestimated, how far you can get with a simple dispatch loop, a state tree, and some judicious OO sprinkled in for client widget-bullshit events/lifecycle. I'm not saying it's better than React, but it's underestimated.

ivosaur 6y ago

> jQuery is ≈30k gziped and most likely already cached from CDN. This part isn't so true in reality anymore, due to revised browser caching systems[1]. Doesn't mean you shouldn't use jQuery, just that part of the benefits of a centralized CDN are no longer a factor and it's a lot more sensible to self-host. 1: https://www.stefanjudis.com/notes/say-goodbye-to-resource-caching-across-sites-and-domains/ https://www.stefanjudis.com/notes/say-goodbye-to-resource-ca...

tambourine_man 6y ago
Right you are. But jQuery is around the same size as Vue, and that's the lean alternative to React. So the “jQuery is bloat” argument still doesn't make much sense. A single retina hero banner is larger than most JavaScript libraries/frameworks.
- srgpqt 6y ago
  A lean alternative to React would be preact.
  - shard972 6y ago
    Or mithril
    - fragile_frogs 6y ago
      Or Inferno
      - IA21 6y ago
        something something framework of the week
- cultofmetatron 6y ago
  > and that's the lean alternative to React. Ahem https://preactjs.com/ https://preactjs.com/

deleted 6y ago

[deleted]

deleted 6y ago

[deleted]

Kudos 6y ago

Firefox and Safari use partitioned caches, and Chrome is following with the feature behind an experiment flag for now. The argument that it's probably cached from a CDN is just about dead.

1shooner 6y ago

>most likely already cached from CDN. I don't believe any major browser allows sites to share 3rd party caches anymore. Previous HN discussion: https://news.ycombinator.com/item?id=24894135 https://news.ycombinator.com/item?id=24894135

starik36 6y ago
True, there is still a perf win however since CDNs are located geographically closer to a global consumer than keeping the libs on your own box.
- 1shooner 6y ago
  But don't modern frontend-oriented sites/apps deploy to CDNs anyway?
- r1ch 6y ago
  Self-hosting is no longer the performance drain it used to be now that HTTP/2 is a thing, as soon as the browser parses the page, the JS file is only 1 RTT away. Using a CDN for a single asset like jQuery requires a DNS lookup, TCP connection and TLS negotiation - that's 3 RTTs plus unknown latency from the user's resolver before the HTTP request is even sent. The performance difference in the single request scenario is likely negligible and the benefits of not relying on a 3rd party can outweigh the latency savings.

enraged_camel 6y ago

I used to write a lot of JQuery, and I've switched to Vue three years ago. Occasionally I have to go back and write more JQuery, and it makes my head hurt. edit: why the dowvotes? are we not allowed to share our experiences now?

Zelphyr 6y ago
I know we're not supposed to discuss voting but people downvoting someone simply because that person said something disagreeable, yet still within the rules of Hacker News, is becoming a serious problem in my opinion. I'd like it just fine we get rid of downvotes altogether.
babypuncher 6y ago
Trying to write any kind of complex interactivity with JQuery event handlers is a serious pain in the butt, and it's so hard to go back and read. I did the same as you; moved on to Vue and haven't looked back. My frontend code is so much cleaner and easier to debug. I've built a large library of components, so often times adding a new page only takes a couple hours re-using those instead of writing a bunch of new JQuery from scratch. JQuery is great when I need to make (non-contentful) changes to the DOM. But I refuse to use it for managing the state of my app or putting content in UI components.

deleted 6y ago

[deleted]

steviedotboston 6y ago

I agree with this 100%. Even though "vanilla JS" is more powerful now, JQuery is still much easier to work with.

pseudosavant 6y ago

"The jQuery API is still (and probably aways will be) far superior to the native DOM" The jQuery API really is so well done. I stopped using jQuery, but implemented a simple script (jSugar.js) that exposes many basic jQuery things but is really just a wrapper for native DOM operations. It only operates on individual DOM nodes. Any looping should be done using your JS loop of choice (forEach, for loop, which, etc). The script started out really small. I've slowly added more and more as I need more functionality for some projects. https://gist.github.com/pseudosavant/b86eedd9960ade958d49447130c95811 https://gist.github.com/pseudosavant/b86eedd9960ade958d49447...

_ZeD_ 6y ago
> The jQuery API really is so well done. I stopped using jQuery, but implemented a simple script (jSugar.js) that exposes many basic jQuery things but is really just a wrapper for native DOM operations. so... like jQuery?
- pseudosavant 6y ago
  No, because jQuery normalizes all sorts of DOM stuff. Part of the reason it is 30kb. What I've done is basically syntatic sugar and is only 74loc.

cphoover 6y ago

Smaller footprint in my mind doesn't refer to download size which is minimal in either case but the footprint or impact on a project. IMO It is way harder to move off of jquery once it has been fully utilized throughout the project than to swap a single function to/from lodash once a core API has a better way of handling it. Using JQuery demands you buy into the whole ecosystem whereas Lodash is modular. Also as others have mentioned caches are individually isolated for each domain now to prevent tracking/data leaks.

thatsnotmepls 6y ago

> If you're building something like Spotify/Slack, I can maybe see the need for virtual DOMs Heck, even Slack was built with jQuery the first time. Only after a while they migrated to react.