4 ms·

Yes...What were you expecting then to do? Usually you replace code if you're dropping a dependency. It's one less network request, saves bandwidth and removes o

by tcd 8y ago

Yes...What were you expecting then to do? Usually you replace code if you're dropping a dependency. It's one less network request, saves bandwidth and removes obsolete and pretty much unmaintained code (at this point, the jQuery github is as good as dead, unlikely to see major releases any time soon). Seems to be a sensible approach to me. It's like using native code rather than electron, even if you add more lines, I'm pretty sure the performance gains would be worth while.

mschuster91 8y ago
> It's one less network request, saves bandwidth Given that most stuff these days is packed together with Webpack or at least concat'd together, you don't really save much, plus jQuery in gzip'd form is clocking in at <30 kB anyway (https://mathiasbynens.be/demo/jquery-size https://mathiasbynens.be/demo/jquery-size). > and pretty much unmaintained code (at this point, the jQuery github is as good as dead, unlikely to see major releases any time soon) So what? Software can very well be "done", there is no need to always evolve and evolve. As long as there is no security issue left unsolved, though. In addition, if you're rebuilding half of it on your own anyway, chances are high you'll miss some weird corner case that jQuery solved years, or decades, ago.
- tcd 8y ago
  I don't agree, software needs to evolve as its dependencies does. In this case we have fetch, async/await, promises and loads more native features that jQuery hasn't adapted to (XHR is obsolete now for example). Why include a dependency that the browser provides for free? jQuery was good before ES6/next came along, these days it's extra cruft. And if what you're saying is true about weird corner cases, people will fix that up in PR's anyway, that's not a reason to stop innovating and just say "meh, jQuery is good enough". Thank god most software doesn't work your way, we'd probably be stuck in the stone ages still.
  - exodust 8y ago
    > ...promises and loads more native features that jQuery hasn't adapted to Promises work great in Jquery. I've had much success chaining combinations of AJAX and interface events together using Jquery deferred promises. Jquery is stable and reliable. Use it or don't use it. A lot of devs tend to think the whole world has an updated web browser like they do. Forgetting that millions of hand-me-down older devices that can't be updated (eg an iPad 3) will NOT load a page properly with ES6 javascript. Example: the Steam website... this site is now useless to browse on an "old" device like an iPad 3 which Apple considers "vintage" so doesn't give updates. So do we throw the iPad in the trash? We're talking an iPad 3 with retina screen and pretty good performance, but no updates to OS or web browser. In the real world, people are not throwing their iPad3's and older devices in the trash, they're keeping them around house, giving to kids or selling them on ebay, which means people are buying them on ebay and still using them for years and years.

by tcd 8y ago

mschuster91 8y ago

> It's one less network request, saves bandwidth Given that most stuff these days is packed together with Webpack or at least concat'd together, you don't really save much, plus jQuery in gzip'd form is clocking in at <30 kB anyway (https://mathiasbynens.be/demo/jquery-size https://mathiasbynens.be/demo/jquery-size). > and pretty much unmaintained code (at this point, the jQuery github is as good as dead, unlikely to see major releases any time soon) So what? Software can very well be "done", there is no need to always evolve and evolve. As long as there is no security issue left unsolved, though. In addition, if you're rebuilding half of it on your own anyway, chances are high you'll miss some weird corner case that jQuery solved years, or decades, ago.

tcd 8y ago
I don't agree, software needs to evolve as its dependencies does. In this case we have fetch, async/await, promises and loads more native features that jQuery hasn't adapted to (XHR is obsolete now for example). Why include a dependency that the browser provides for free? jQuery was good before ES6/next came along, these days it's extra cruft. And if what you're saying is true about weird corner cases, people will fix that up in PR's anyway, that's not a reason to stop innovating and just say "meh, jQuery is good enough". Thank god most software doesn't work your way, we'd probably be stuck in the stone ages still.
- exodust 8y ago
  > ...promises and loads more native features that jQuery hasn't adapted to Promises work great in Jquery. I've had much success chaining combinations of AJAX and interface events together using Jquery deferred promises. Jquery is stable and reliable. Use it or don't use it. A lot of devs tend to think the whole world has an updated web browser like they do. Forgetting that millions of hand-me-down older devices that can't be updated (eg an iPad 3) will NOT load a page properly with ES6 javascript. Example: the Steam website... this site is now useless to browse on an "old" device like an iPad 3 which Apple considers "vintage" so doesn't give updates. So do we throw the iPad in the trash? We're talking an iPad 3 with retina screen and pretty good performance, but no updates to OS or web browser. In the real world, people are not throwing their iPad3's and older devices in the trash, they're keeping them around house, giving to kids or selling them on ebay, which means people are buying them on ebay and still using them for years and years.