4 ms·

The native alternatives all seem longer. I'll keep jQuery, thanks. (Maybe they should put some of its functionality into the JaveScript standard?)

gameswithgo 8y ago
your choice adds a small convenience for you while increasing the payload size and runtime overhead for how many of your users? as an alternative you could make a very small set of wrapper functions to shorten things without taking on the entire jquery lib.
- dmitriid 8y ago
  You will end up re-implementing half of jQuery anyway because DOM APIs are just so bad.
  - goatlover 8y ago
    Greenspun's tenth rule for the web?
- sebazzz 8y ago
  If you reinvent a wheel you need to maintain that wheel. That is your customer's money. Money which can be put in features instead of striving to technical excellence. Instead, you now put money and time in building a wheel for very little benefit (if you can feel the performance of jQuery, you're doing to much DOM operations and you probably wouldn't benefit much from stripping it out). Some projects are not meant to last long-term, and jQuery would work just fine. Even if it is old fashioned.
- jtdev 8y ago
  Regarding the payload size argument: If you’re pulling jQuery in from one of the popular CDNs (which you should be), your clients will almost certainly already have it cached locally anyway. Can you elaborate on the runtime overhead issue? If you write your own JS functions to replace jQuery, you’re still adding runtime overhead... and jQuery likely wrote a more efficient implementation to begin with; jQuery is battle tested and one of the most widely used pieces of software in history, what makes you think your code will have less runtime overhead?
  - acdha 8y ago
    > If you’re pulling jQuery in from one of the popular CDNs (which you should be), your clients will almost certainly already have it cached locally anyway. Have you ever measured this on a large scale? I’ve never found it to be true because there are many CDNs, versions, and browser caches are not infinite. If performance is a priority it’s almost always faster to serve it directly to avoid things like the DNS and TLS latency from those CDN connections.
    - jjeaff 8y ago
      Plus, I don't think a lot of the engineers on HN are actually even working on first page optimizations. If you are building an application that people are logging in to and using on a regular basis, you can afford a little bit of first load overhead which will then most definitely stay cached for the remainder of the session. All this talk of trying to skim off a few kb of load time only applies to extreme edge cases of landing pages with flighty potential customers.
      - acdha 8y ago
        Yes, it’s an oddly specific focus given how few sites have been optimized to the degree that a single cache-friendly resource matters. Given how many sites I run into where a single failure means that functionality breaks entirely, I really think it should be down the list.
  - deleted 8y ago
    [deleted]
- mythrwy 8y ago
  A whole 28KB that's probably cached anyway? And your suggestion is write your own custom wrappers to avoid overhead? So you or someone else can learn all your custom things. No to all of that. Get off the "too cool for Dad" train and just use jQuery if you already know it and it fits for what you are doing. If something else is better, (including native), use that.
- wolco 8y ago
  If 30k is an issue removing your css framework and going barebones might give you more bang for your buck.
- simion314 8y ago
  Aka, reinvent jQuery probably sub optimally and with less cross browser testing. Use jQuery from a CDN and you should have solved the issue of download size/speed. Also the native versions will be longer so it will increase your code size too.

gameswithgo 8y ago

your choice adds a small convenience for you while increasing the payload size and runtime overhead for how many of your users? as an alternative you could make a very small set of wrapper functions to shorten things without taking on the entire jquery lib.

dmitriid 8y ago
You will end up re-implementing half of jQuery anyway because DOM APIs are just so bad.
- goatlover 8y ago
  Greenspun's tenth rule for the web?
sebazzz 8y ago
If you reinvent a wheel you need to maintain that wheel. That is your customer's money. Money which can be put in features instead of striving to technical excellence. Instead, you now put money and time in building a wheel for very little benefit (if you can feel the performance of jQuery, you're doing to much DOM operations and you probably wouldn't benefit much from stripping it out). Some projects are not meant to last long-term, and jQuery would work just fine. Even if it is old fashioned.
jtdev 8y ago
Regarding the payload size argument: If you’re pulling jQuery in from one of the popular CDNs (which you should be), your clients will almost certainly already have it cached locally anyway. Can you elaborate on the runtime overhead issue? If you write your own JS functions to replace jQuery, you’re still adding runtime overhead... and jQuery likely wrote a more efficient implementation to begin with; jQuery is battle tested and one of the most widely used pieces of software in history, what makes you think your code will have less runtime overhead?
- acdha 8y ago
  > If you’re pulling jQuery in from one of the popular CDNs (which you should be), your clients will almost certainly already have it cached locally anyway. Have you ever measured this on a large scale? I’ve never found it to be true because there are many CDNs, versions, and browser caches are not infinite. If performance is a priority it’s almost always faster to serve it directly to avoid things like the DNS and TLS latency from those CDN connections.
  - jjeaff 8y ago
    Plus, I don't think a lot of the engineers on HN are actually even working on first page optimizations. If you are building an application that people are logging in to and using on a regular basis, you can afford a little bit of first load overhead which will then most definitely stay cached for the remainder of the session. All this talk of trying to skim off a few kb of load time only applies to extreme edge cases of landing pages with flighty potential customers.
    - acdha 8y ago
      Yes, it’s an oddly specific focus given how few sites have been optimized to the degree that a single cache-friendly resource matters. Given how many sites I run into where a single failure means that functionality breaks entirely, I really think it should be down the list.
- deleted 8y ago
  [deleted]
mythrwy 8y ago
A whole 28KB that's probably cached anyway? And your suggestion is write your own custom wrappers to avoid overhead? So you or someone else can learn all your custom things. No to all of that. Get off the "too cool for Dad" train and just use jQuery if you already know it and it fits for what you are doing. If something else is better, (including native), use that.
wolco 8y ago
If 30k is an issue removing your css framework and going barebones might give you more bang for your buck.
simion314 8y ago
Aka, reinvent jQuery probably sub optimally and with less cross browser testing. Use jQuery from a CDN and you should have solved the issue of download size/speed. Also the native versions will be longer so it will increase your code size too.