News for hackers. Stuff that matters.
Re:Native Javascript alternatives to jQuery methods by jtdev on Sunday March 31, 2019 @09:47AM (#19535560)
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?

Re:Native Javascript alternatives to jQuery methods by acdha on Sunday March 31, 2019 @11:28AM (#19536066)
> 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.

Re:Native Javascript alternatives to jQuery methods by jjeaff on Sunday March 31, 2019 @08:59PM (#19539556)
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.

Re:Native Javascript alternatives to jQuery methods by acdha on Sunday March 31, 2019 @09:27PM (#19539680)
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.