11 ms·

jQuery _did_ lots of useful stuff. It's unmaintained, has no interest/support (look at their github), doesn't adapt to modern features, is 'slow' compared to ot

by tcd 8y ago

jQuery _did_ lots of useful stuff. It's unmaintained, has no interest/support (look at their github), doesn't adapt to modern features, is 'slow' compared to other frameworks that now use the Shadow Dom, and can be replaced with features that are native to JS - what's there not to like about that? One less dependency, network request and more efficient code is always worth the effort. Oh, and since the new code is vanilla and written in ES6 (it was already but transpiled) you can use modules/tree shaking, even better for performance.

Carpetsmoker 8y ago
But this isn't replaced with a new framework that uses the shadow DOM, it uses the same techniques as jQuery, except without jQuery. jQuery already uses many native features when supported, while also working around browser quirks and such. It's less of an issue than in the past, but it hasn't gone away completely; see all the comments/fixes for specific browsers. > One less dependency, network request and more efficient code is always worth the effort. Of course not. It's a return-of-investment calculation. The 85k of jQuery isn't all that large, especially considering that websites like Medium and NYC load 2MB of JS, and the overhead of jQuery compared to standard JavaScript is minor.
- alejandromaka 8y ago
  in the world of web performance and SEO 85kb is very significant. i wouldnt think twice to remove it if i had the opportunity. compared to modern frameworks, jquery is ~500% larger. you could definitely debate the usage and needs but thats a separate topic than efficiency.
  - munk-a 8y ago
    Uh, at least in terms of react a bit of quick googling saw people who were putting effort into optimizing react's client side size getting it down to ~40 - 90 kB, so it seems pretty comparable. Some of these folks had a 1.2 MB script bundle they were sending to the client to begin with. I'm not in the trenches with this stuff though so my numbers may be wrong but... the ~500% number seems pretty off.
    - _oxih 8y ago
      https://gist.github.com/Restuta/cda69e50a853aa64912d https://gist.github.com/Restuta/cda69e50a853aa64912d react is 31kb vue is 20kb preact is 4kb. depends on the framework but 500% isnt far off
      - deleted 8y ago
        [deleted]
  - Carpetsmoker 8y ago
    The standard download of Vue.js is 95k; React is 120k. I have no idea where you got your "500%" from, but it seems wildly off-mark.
    - alejandromaka 8y ago
      https://gist.github.com/Restuta/cda69e50a853aa64912d https://gist.github.com/Restuta/cda69e50a853aa64912d react is 31kb vue is 20kb preact is 4kb
      - mynameisvlad 8y ago
        JQuery Minified and GZipped is also 30KB: https://mathiasbynens.be/demo/jquery-size https://mathiasbynens.be/demo/jquery-size When doing comparisons, don't be disingenuous. Compare like numbers.
        Carpetsmoker 8y ago
        Plus Vue.js 2.6.6 is 91K, not the 63K of 2.0.3 in that comparison. It's easy to "win" internet arguments like this rolls eyes.
        alejandromaka 8y ago
        whoops i assumed the 85k was already gzipped. fair enough
  - acdha 8y ago
    These massive compressed JS bundles make me think your numbers are off on the alleged golden age of modern frameworks: https://webpagetest.org/result/190213_XH_63c61dc3d45cb95ec8ac7db079372ae6/1/breakdown/ https://webpagetest.org/result/190213_XH_63c61dc3d45cb95ec8a... https://www.webpagetest.org/result/190213_NX_ee1e7ae8fa74557d70b7acadd8ce3b68/1/breakdown/ https://www.webpagetest.org/result/190213_NX_ee1e7ae8fa74557... It’s not hard to beat jQuery in many cases but they’re looking pretty svelte in comparison: https://webpagetest.org/result/190213_93_e2da91a07e2b2bc02345b086bf349bb5/1/breakdown/ https://webpagetest.org/result/190213_93_e2da91a07e2b2bc0234...
    - sureaboutthis 8y ago
      Just because others do bad things doesn't make it OK for you to do bad things. The biggest complain I read about is javascript downloads being so big nowadays so piling on with jQuery--or anything else--just because frameworks and other libraries are so bloated doesn't make it OK.
      - acdha 8y ago
        Look, I’ve replaced plenty of jQuery with vanilla JS. I’m totally on board for lighter, leaner pages. My point was simply that there’s this tedious cycle where people crap on the older tools and say everything is better across the board with the current hotness without actually measuring anything. There are a lot of cool capabilities we can use now but they’re only going to be better at the things you actually measure & attempt to improve. If you don’t profile your app, that cool new stack is probably going to be bigger and slower because tools like webpack make it easy to manage tons of code and you won’t notice until you test it on mobile, slow WiFi, etc.
        sureaboutthis 8y ago
        The "cool new stack", in this case, is native, vanilla javascript that works everywhere without downloading anything and without a need to learn someone else's library.
cptskippy 8y ago
I wouldn't say it's unmaintained. There have been more issues closed than opened in the last month. I would just say there isn't much interest in it anymore.
thrownaway954 8y ago
JQuery is still maintained. The last pull request was 2 weeks ago. Remember that this is a _mature_ project and as such doesn't need the plethora of pull requests everyday. Personally if you are spending all that time and energy recreating the wheel just to say "you don't use JQuery ", you're being an idiot and might as well just use JQuery. Seriously I wonder how much they actually spent in dollar hours on this pull request.
- cabalamat 8y ago
  > Personally if you are spending all that time and energy recreating the wheel just to say "you don't use JQuery ", you're being an idiot I prefer the term "Magpie Developer" https://blog.codinghorror.com/the-magpie-developer/ https://blog.codinghorror.com/the-magpie-developer/ Personally, I'm currently working on projects that still use Bootstrap 3. It still works, just a jQuery still works.
- capsulecorp 8y ago
  By that logic JQuery users/devs were idiots for recreating the wheel. I smell a jqueery fanboi and it stinks to high heavens.
  - exodust 8y ago
    When the wheel is prone to damage from small bumps, and can't handle off-road, a new stronger reliable wheel that handles all terrain is needed. That's what Jquery offers.
    - capsulecorp 8y ago
      And when the wheel is so bloated the car can barely make it down the road without needing to refill the fuel tank a new more lightweight reliable wheel that can handle modern terrain is needed. That is why people are moving away from Jquery.
      - exodust 8y ago
whoisjuan 8y ago
jQuery may be outdated from a JS point of view, but nothing beats its syntax. Nothing is as simple and straightforward.
- nullandvoid 8y ago
  Indeed it's polymorphic overloads ( over 10 on the $() method! ) were commendated in The book 'modular JavaScript' i'm reading right now. Whilst it would be questionable offering quite that many options nowadays on a library method it certainly helped devs get productive quickly and helped it become a such a success
- nkozyra 8y ago
  Most of its syntax is now part of JS/DOM natively now. I think that's because of how intuitive it was. It's not cool anymore but there's little compelling reason to tear it out of existing projects other than a refactor. It still works.
  - mercer 8y ago
    I've been jQuery-less for quite a while now, but honestly I still miss it sometimes. [...document.querySelectorAll()], event binding, and quite a lot of other jQuery stuff is still a bit more verbose, even in the hippest browser environments.
manigandham 8y ago
Jquery will fallback to native functions where available and it's feature complete. It doesn't need to have constant commits to still be immensely useful. Its primary purpose was smoothing over browser inconsistencies and it's cached by every major CDN already so using it is likely faster than trying to rebuild and maintain the individual parts separately.
- acdha 8y ago
  > it's cached by every major CDN already I’ve never found this to be true any time I’ve measured, especially for mobile clients. Small caches with lots of versions and CDNs really cut into the theoretical benefits.
  - mercer 8y ago
    I wish I could find it, but I read an article a while ago that showed how CDN-cached stuff usually, well, isn't. At the very least it's not something to rely on when making decisions about payload size.
    - manigandham 8y ago
      It's cached at the CDN nodes, which means quick delivery to the device. This is much better than serving that file from your origin server, and even if you use a CDN it's unlikely that it'll match the hit rates of the public CDNs. That can make a measurable improvement, and at worse is no slower than hosting it yourself.
      - acdha 8y ago
        Have you benchmarked that? Each host you add has its own overhead thanks to DNS, TLS, etc. and every time I’ve done the tests, that cancels out the benefits entirely for a site which itself uses a CDN. I’ve also tended to see numbers for public CDNs which suggest that things aren’t cached as often as you’d like - maybe if it’s a popular project which hasn’t updated in years but otherwise version spread undercuts hit rates dramatically. My rule of thumb is that public CDNs aren’t a performance move in the HTTP/2 era (i.e. 2016 or later). They may still be convenient, however.
sam0x17 8y ago
That said, I'm still waiting for a js framework to come around that uses the shadow dom that isn't terrible in some way. Like something with the light-weight unopinionated-ness of jquery, but modern features. I don't want to use whatever paradigm some framework enforces, just let me use the new features, with whatever paradigm I feel like making myself.
- colordrops 8y ago
  Polymer or the more light-weight LitElement.
- EB66 8y ago
  @sam0x17 If you have the time, take a look at this JS framework I put together ( https://github.com/elliotnb/nimbly https://github.com/elliotnb/nimbly ) and it's observer library dependency ( https://github.com/elliotnb/observable-slim https://github.com/elliotnb/observable-slim ). I built the framework so developers can take advantage of the benefits of modern frameworks (templating, data binding, state management, no explicit DOM manipulations, automated unit testing, loosely coupled modular components, etc) but without the typical drawbacks of modern frameworks. The framework has far fewer abstractions than React or Vue, requires no domain specific language (i.e., you write in plain HTML, CSS and JS), and does not require compiling/transpiling. The framework embraces the DOM instead of abstracting away from it and still refreshes/re-renders components in a highly performant manner via DocumentFragments. We've used the framework fairly extensively at my work because it plays very nicely with our jQuery-heavy legacy code and allows for much easier re-factors. The observer library has gained a fair bit of interest from other developers (~600 downloads per week via npm) and it'd be great if I could interest others in trying out the framework too. I'd love to hear feedback from anyone who takes the time to try it out. Other contributors would be fantastic.
  - sam0x17 8y ago
    This sounds super nice. Checking it out!
    - 8y ago
ljm 8y ago
GitHub is a terrible metric. You probably use tools like grep and ls many times a day... you do not check if ls is up to modern standards and has a constant stream of issues and fixes. You don’t do it for grep, or git...you depend on git. You cannot apply instant gratification to software library dev. If the work for a library was done and satisfied in 2015, then it’s fucking done. It’s tried and tested. It gets security patches. It’s maintained. Recency and the last github commit is not a metric for stability or success.
- lsiebert 8y ago
  FWIW, git is actively being developed. I see both pull requests and traffic on the git mailing list pretty much every day.
- justaj 8y ago
  It would only be 'done' or 'mature' enough if there would be (almost) no bugs being listed in the Github issues, right?
- leadingthenet 8y ago
  There's no such thing as "done" software. Your view is incompatible with reality, I'm afraid. Yes, I did check whether ls was still actively being developed, saw that it wasn't doing anything new, and switched to exa, which is a fantastic little project, with sane defaults, less cruft, and greater speed. You can always improve software, some people just get bored of doing so, and then declare it "done". But it isn't, and it's never going to be.
  - karimf 8y ago
    Paul Graham said he "finished" writing Hacker News 12 years ago. [0] This might even be more possible for "simpler" softwares. [0] https://twitter.com/paulg/status/1049723540902215681 https://twitter.com/paulg/status/1049723540902215681
    - krapp 8y ago
      HN and Arc are still being updated, though, just not by Paul Graham.
munk-a 8y ago
Less dependencies is a wonderful thing but... why not take an approach where alternative tools (like the shadow DOM) are preferred for new features and refactorings, just slowly deprecate it out of existence. It's always nice to have both feet securely on the ground as you shift your weight from one dependency to another.
okonomiyaki3000 8y ago
> One less dependency, network request and more efficient code is always worth the effort. Except that 90% of sites that use BS5 will continue to use JQ for other things anyway so, in reality, you won't have less code, fewer requests, etc. Personally I've felt for a while that JQ's day in the sun is over and that developers should really think about whether they need it or not. Maybe really getting rid of it starts with slightly risky moves like this. Like when Apple killed the floppy.
- dylan604 8y ago
  How was Apple killing the floppy a slightly risky move? Granted, we have hindsight now, but when they released the first machine without a floppy I had already said good riddance to lame 1.5MB slower than christmas devices. The only thing I miss about floppies are the sounds they made. The heads cycling back and forth and the Mac eject sounds were so distinct. I also do not miss the ADB connections, nor do I miss SCSI. I also do not miss System 7,8,9. Some of the decisions Apple has "forced" upon us have not all been bad. Although, all of those decisions were made when they were a computer company. The forced decisions after have sucked. I'm looking directly at you TouchBar, butterfly keyboard, MacPro Trashcan, AMD GPU only, and loss of MagSafe.
  - dajohnson89 8y ago
    Just curious, what's your opinion on their decision to remove the headphone jack?
    - dylan604 8y ago
      That's one of the post Apple Computer decisions that bugs me. I'm a relic and like my headphones with wires attached. My wired cans have this unique feature of not needing to be recharged.
      - sureaboutthis 8y ago
        Now you know how everyone else felt when Apple killed the floppy.
interlocutor 8y ago
jQuery still does a lot of useful stuff. The best advertisement for jQuery, ironically, is this site: http://youmightnotneedjquery.com/ http://youmightnotneedjquery.com/ Look at how simple things are in the left column, and how much more code is needed in the right column. jQuery has many convenience features such as chaining, for example: item.addClass('selected').siblings().removeClass('selected'); and you don't have to check for nulls after each selection. Many functions such as closest() and remove() have no equivalents in IE11, and other things such as replaceWith() and before() are not available even in Edge. For simple sites it is easy enough to remove jQuery, but for more complex javascript applications, especially apps that have a lot of interactivity, removing jQuery will result in more code, or you will end up writing a lot of utility functions thereby creating your own little clone of jQuery.
- adventured 8y ago
  I agree. I still use it from time to time when initially hacking together a project. It makes my development process faster and easier. I never have problems with it. The primary concern between start and launch is getting to done, not shaving 20kb or 30kb off (if it was 300kb or 500kb that would be a different matter). As I get to roughly 85%-90% done, or sometimes post launch, I'll then allocate time where it makes sense to removing jQuery and pursuing further optimizations. Eliminating jQuery is toward the bottom of the list of reasonable concerns when it comes to making a new product successful. I have more than two decades of experience with JavaScript, and there are numerous things that are simplified to a point of fast, no concern development triviality with jQuery. If it's useful to your development process, use it.
- dylan604 8y ago
  > Look at how simple things are in the left column, and how much more code is needed in the right column. This is misleading. Sure, that immediate code is cleaner in the left column. However, to do that, you have to have the entire JQuery library loaded as well. Sure, it's hidden, but the library looks like the code on the right column. I'm not knocking JQuery, as I use it a lot.
  - 8y ago
baby 8y ago
I still use jQuery, it still works quite well. IMO it still has a better API for a lot of stuff.
derptron 8y ago
Imagine basing all your dependencies on their last update time in Github. I guess you don't have to imagine though.
petre 8y ago
> can be replaced with features that are native to JS - what's there not to like about that? I don't feel like writing document.querySelector() all the time and then checking if it really got anything. Aliasing it to $ will break jq upon which some libraries still depend.

by tcd 8y ago

Carpetsmoker 8y ago

But this isn't replaced with a new framework that uses the shadow DOM, it uses the same techniques as jQuery, except without jQuery. jQuery already uses many native features when supported, while also working around browser quirks and such. It's less of an issue than in the past, but it hasn't gone away completely; see all the comments/fixes for specific browsers. > One less dependency, network request and more efficient code is always worth the effort. Of course not. It's a return-of-investment calculation. The 85k of jQuery isn't all that large, especially considering that websites like Medium and NYC load 2MB of JS, and the overhead of jQuery compared to standard JavaScript is minor.

alejandromaka 8y ago
in the world of web performance and SEO 85kb is very significant. i wouldnt think twice to remove it if i had the opportunity. compared to modern frameworks, jquery is ~500% larger. you could definitely debate the usage and needs but thats a separate topic than efficiency.
- munk-a 8y ago
  Uh, at least in terms of react a bit of quick googling saw people who were putting effort into optimizing react's client side size getting it down to ~40 - 90 kB, so it seems pretty comparable. Some of these folks had a 1.2 MB script bundle they were sending to the client to begin with. I'm not in the trenches with this stuff though so my numbers may be wrong but... the ~500% number seems pretty off.
  - _oxih 8y ago
    https://gist.github.com/Restuta/cda69e50a853aa64912d https://gist.github.com/Restuta/cda69e50a853aa64912d react is 31kb vue is 20kb preact is 4kb. depends on the framework but 500% isnt far off
    - deleted 8y ago
      [deleted]
- Carpetsmoker 8y ago
  The standard download of Vue.js is 95k; React is 120k. I have no idea where you got your "500%" from, but it seems wildly off-mark.
  - alejandromaka 8y ago
    https://gist.github.com/Restuta/cda69e50a853aa64912d https://gist.github.com/Restuta/cda69e50a853aa64912d react is 31kb vue is 20kb preact is 4kb
    - mynameisvlad 8y ago
      JQuery Minified and GZipped is also 30KB: https://mathiasbynens.be/demo/jquery-size https://mathiasbynens.be/demo/jquery-size When doing comparisons, don't be disingenuous. Compare like numbers.
      - Carpetsmoker 8y ago
        Plus Vue.js 2.6.6 is 91K, not the 63K of 2.0.3 in that comparison. It's easy to "win" internet arguments like this rolls eyes.
      - alejandromaka 8y ago
        whoops i assumed the 85k was already gzipped. fair enough
- acdha 8y ago
  These massive compressed JS bundles make me think your numbers are off on the alleged golden age of modern frameworks: https://webpagetest.org/result/190213_XH_63c61dc3d45cb95ec8ac7db079372ae6/1/breakdown/ https://webpagetest.org/result/190213_XH_63c61dc3d45cb95ec8a... https://www.webpagetest.org/result/190213_NX_ee1e7ae8fa74557d70b7acadd8ce3b68/1/breakdown/ https://www.webpagetest.org/result/190213_NX_ee1e7ae8fa74557... It’s not hard to beat jQuery in many cases but they’re looking pretty svelte in comparison: https://webpagetest.org/result/190213_93_e2da91a07e2b2bc02345b086bf349bb5/1/breakdown/ https://webpagetest.org/result/190213_93_e2da91a07e2b2bc0234...
  - sureaboutthis 8y ago
    Just because others do bad things doesn't make it OK for you to do bad things. The biggest complain I read about is javascript downloads being so big nowadays so piling on with jQuery--or anything else--just because frameworks and other libraries are so bloated doesn't make it OK.
    - acdha 8y ago
      Look, I’ve replaced plenty of jQuery with vanilla JS. I’m totally on board for lighter, leaner pages. My point was simply that there’s this tedious cycle where people crap on the older tools and say everything is better across the board with the current hotness without actually measuring anything. There are a lot of cool capabilities we can use now but they’re only going to be better at the things you actually measure & attempt to improve. If you don’t profile your app, that cool new stack is probably going to be bigger and slower because tools like webpack make it easy to manage tons of code and you won’t notice until you test it on mobile, slow WiFi, etc.
      - sureaboutthis 8y ago
        The "cool new stack", in this case, is native, vanilla javascript that works everywhere without downloading anything and without a need to learn someone else's library.

cptskippy 8y ago

I wouldn't say it's unmaintained. There have been more issues closed than opened in the last month. I would just say there isn't much interest in it anymore.

thrownaway954 8y ago

JQuery is still maintained. The last pull request was 2 weeks ago. Remember that this is a _mature_ project and as such doesn't need the plethora of pull requests everyday. Personally if you are spending all that time and energy recreating the wheel just to say "you don't use JQuery ", you're being an idiot and might as well just use JQuery. Seriously I wonder how much they actually spent in dollar hours on this pull request.

cabalamat 8y ago
> Personally if you are spending all that time and energy recreating the wheel just to say "you don't use JQuery ", you're being an idiot I prefer the term "Magpie Developer" https://blog.codinghorror.com/the-magpie-developer/ https://blog.codinghorror.com/the-magpie-developer/ Personally, I'm currently working on projects that still use Bootstrap 3. It still works, just a jQuery still works.
capsulecorp 8y ago
By that logic JQuery users/devs were idiots for recreating the wheel. I smell a jqueery fanboi and it stinks to high heavens.
- exodust 8y ago
  When the wheel is prone to damage from small bumps, and can't handle off-road, a new stronger reliable wheel that handles all terrain is needed. That's what Jquery offers.
  - capsulecorp 8y ago
    And when the wheel is so bloated the car can barely make it down the road without needing to refill the fuel tank a new more lightweight reliable wheel that can handle modern terrain is needed. That is why people are moving away from Jquery.
    - exodust 8y ago

whoisjuan 8y ago

jQuery may be outdated from a JS point of view, but nothing beats its syntax. Nothing is as simple and straightforward.

nullandvoid 8y ago
Indeed it's polymorphic overloads ( over 10 on the $() method! ) were commendated in The book 'modular JavaScript' i'm reading right now. Whilst it would be questionable offering quite that many options nowadays on a library method it certainly helped devs get productive quickly and helped it become a such a success
nkozyra 8y ago
Most of its syntax is now part of JS/DOM natively now. I think that's because of how intuitive it was. It's not cool anymore but there's little compelling reason to tear it out of existing projects other than a refactor. It still works.
- mercer 8y ago
  I've been jQuery-less for quite a while now, but honestly I still miss it sometimes. [...document.querySelectorAll()], event binding, and quite a lot of other jQuery stuff is still a bit more verbose, even in the hippest browser environments.

manigandham 8y ago

Jquery will fallback to native functions where available and it's feature complete. It doesn't need to have constant commits to still be immensely useful. Its primary purpose was smoothing over browser inconsistencies and it's cached by every major CDN already so using it is likely faster than trying to rebuild and maintain the individual parts separately.

acdha 8y ago
> it's cached by every major CDN already I’ve never found this to be true any time I’ve measured, especially for mobile clients. Small caches with lots of versions and CDNs really cut into the theoretical benefits.
- mercer 8y ago
  I wish I could find it, but I read an article a while ago that showed how CDN-cached stuff usually, well, isn't. At the very least it's not something to rely on when making decisions about payload size.
  - manigandham 8y ago
    It's cached at the CDN nodes, which means quick delivery to the device. This is much better than serving that file from your origin server, and even if you use a CDN it's unlikely that it'll match the hit rates of the public CDNs. That can make a measurable improvement, and at worse is no slower than hosting it yourself.
    - acdha 8y ago
      Have you benchmarked that? Each host you add has its own overhead thanks to DNS, TLS, etc. and every time I’ve done the tests, that cancels out the benefits entirely for a site which itself uses a CDN. I’ve also tended to see numbers for public CDNs which suggest that things aren’t cached as often as you’d like - maybe if it’s a popular project which hasn’t updated in years but otherwise version spread undercuts hit rates dramatically. My rule of thumb is that public CDNs aren’t a performance move in the HTTP/2 era (i.e. 2016 or later). They may still be convenient, however.

sam0x17 8y ago

That said, I'm still waiting for a js framework to come around that uses the shadow dom that isn't terrible in some way. Like something with the light-weight unopinionated-ness of jquery, but modern features. I don't want to use whatever paradigm some framework enforces, just let me use the new features, with whatever paradigm I feel like making myself.

colordrops 8y ago
Polymer or the more light-weight LitElement.
EB66 8y ago
@sam0x17 If you have the time, take a look at this JS framework I put together ( https://github.com/elliotnb/nimbly https://github.com/elliotnb/nimbly ) and it's observer library dependency ( https://github.com/elliotnb/observable-slim https://github.com/elliotnb/observable-slim ). I built the framework so developers can take advantage of the benefits of modern frameworks (templating, data binding, state management, no explicit DOM manipulations, automated unit testing, loosely coupled modular components, etc) but without the typical drawbacks of modern frameworks. The framework has far fewer abstractions than React or Vue, requires no domain specific language (i.e., you write in plain HTML, CSS and JS), and does not require compiling/transpiling. The framework embraces the DOM instead of abstracting away from it and still refreshes/re-renders components in a highly performant manner via DocumentFragments. We've used the framework fairly extensively at my work because it plays very nicely with our jQuery-heavy legacy code and allows for much easier re-factors. The observer library has gained a fair bit of interest from other developers (~600 downloads per week via npm) and it'd be great if I could interest others in trying out the framework too. I'd love to hear feedback from anyone who takes the time to try it out. Other contributors would be fantastic.
- sam0x17 8y ago
  This sounds super nice. Checking it out!
  - 8y ago

ljm 8y ago

GitHub is a terrible metric. You probably use tools like grep and ls many times a day... you do not check if ls is up to modern standards and has a constant stream of issues and fixes. You don’t do it for grep, or git...you depend on git. You cannot apply instant gratification to software library dev. If the work for a library was done and satisfied in 2015, then it’s fucking done. It’s tried and tested. It gets security patches. It’s maintained. Recency and the last github commit is not a metric for stability or success.

lsiebert 8y ago
FWIW, git is actively being developed. I see both pull requests and traffic on the git mailing list pretty much every day.
justaj 8y ago
It would only be 'done' or 'mature' enough if there would be (almost) no bugs being listed in the Github issues, right?
leadingthenet 8y ago
There's no such thing as "done" software. Your view is incompatible with reality, I'm afraid. Yes, I did check whether ls was still actively being developed, saw that it wasn't doing anything new, and switched to exa, which is a fantastic little project, with sane defaults, less cruft, and greater speed. You can always improve software, some people just get bored of doing so, and then declare it "done". But it isn't, and it's never going to be.
- karimf 8y ago
  Paul Graham said he "finished" writing Hacker News 12 years ago. [0] This might even be more possible for "simpler" softwares. [0] https://twitter.com/paulg/status/1049723540902215681 https://twitter.com/paulg/status/1049723540902215681
  - krapp 8y ago
    HN and Arc are still being updated, though, just not by Paul Graham.

munk-a 8y ago

Less dependencies is a wonderful thing but... why not take an approach where alternative tools (like the shadow DOM) are preferred for new features and refactorings, just slowly deprecate it out of existence. It's always nice to have both feet securely on the ground as you shift your weight from one dependency to another.

okonomiyaki3000 8y ago

> One less dependency, network request and more efficient code is always worth the effort. Except that 90% of sites that use BS5 will continue to use JQ for other things anyway so, in reality, you won't have less code, fewer requests, etc. Personally I've felt for a while that JQ's day in the sun is over and that developers should really think about whether they need it or not. Maybe really getting rid of it starts with slightly risky moves like this. Like when Apple killed the floppy.

dylan604 8y ago
How was Apple killing the floppy a slightly risky move? Granted, we have hindsight now, but when they released the first machine without a floppy I had already said good riddance to lame 1.5MB slower than christmas devices. The only thing I miss about floppies are the sounds they made. The heads cycling back and forth and the Mac eject sounds were so distinct. I also do not miss the ADB connections, nor do I miss SCSI. I also do not miss System 7,8,9. Some of the decisions Apple has "forced" upon us have not all been bad. Although, all of those decisions were made when they were a computer company. The forced decisions after have sucked. I'm looking directly at you TouchBar, butterfly keyboard, MacPro Trashcan, AMD GPU only, and loss of MagSafe.
- dajohnson89 8y ago
  Just curious, what's your opinion on their decision to remove the headphone jack?
  - dylan604 8y ago
    That's one of the post Apple Computer decisions that bugs me. I'm a relic and like my headphones with wires attached. My wired cans have this unique feature of not needing to be recharged.
    - sureaboutthis 8y ago
      Now you know how everyone else felt when Apple killed the floppy.

interlocutor 8y ago

jQuery still does a lot of useful stuff. The best advertisement for jQuery, ironically, is this site: http://youmightnotneedjquery.com/ http://youmightnotneedjquery.com/ Look at how simple things are in the left column, and how much more code is needed in the right column. jQuery has many convenience features such as chaining, for example: item.addClass('selected').siblings().removeClass('selected'); and you don't have to check for nulls after each selection. Many functions such as closest() and remove() have no equivalents in IE11, and other things such as replaceWith() and before() are not available even in Edge. For simple sites it is easy enough to remove jQuery, but for more complex javascript applications, especially apps that have a lot of interactivity, removing jQuery will result in more code, or you will end up writing a lot of utility functions thereby creating your own little clone of jQuery.

adventured 8y ago
I agree. I still use it from time to time when initially hacking together a project. It makes my development process faster and easier. I never have problems with it. The primary concern between start and launch is getting to done, not shaving 20kb or 30kb off (if it was 300kb or 500kb that would be a different matter). As I get to roughly 85%-90% done, or sometimes post launch, I'll then allocate time where it makes sense to removing jQuery and pursuing further optimizations. Eliminating jQuery is toward the bottom of the list of reasonable concerns when it comes to making a new product successful. I have more than two decades of experience with JavaScript, and there are numerous things that are simplified to a point of fast, no concern development triviality with jQuery. If it's useful to your development process, use it.
dylan604 8y ago
> Look at how simple things are in the left column, and how much more code is needed in the right column. This is misleading. Sure, that immediate code is cleaner in the left column. However, to do that, you have to have the entire JQuery library loaded as well. Sure, it's hidden, but the library looks like the code on the right column. I'm not knocking JQuery, as I use it a lot.
- 8y ago

baby 8y ago

I still use jQuery, it still works quite well. IMO it still has a better API for a lot of stuff.

derptron 8y ago

Imagine basing all your dependencies on their last update time in Github. I guess you don't have to imagine though.

petre 8y ago

> can be replaced with features that are native to JS - what's there not to like about that? I don't feel like writing document.querySelector() all the time and then checking if it really got anything. Aliasing it to $ will break jq upon which some libraries still depend.