Hacker News Reader

Comment by tcd | Hacker News Reader

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.

View on HN

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.

> 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/

Personally, I'm currently working on projects that still use Bootstrap 3. It still works, just a jQuery still works.

Not only are you recreating it, but your universe of users is smaller. Love it or hate it jQuery is being battle tested day in and day out by __a lot__ of sites and site visitors.

Sure there's some baggage. There's always some trade off somewhere, isn't there. But if things working is a priority then jQuery isn't such a bad thing.

> Personally if you are spending all that time and energy recreating the wheel just to say "you don't use JQuery "

Heavy movie trailer voice Consider a world, where there is no problem that required jQuery.

I refer to React and such.

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.

FWIW, git is actively being developed. I see both pull requests and traffic on the git mailing list pretty much every day.

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.

So you are like Barney from How I Met Your Mother? “What’s my other other number one rule Ted? New is always better!”

How many times can you update a URL parser or leftpad? Do you need to update them just to up your GitHub activity meter?

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

HN and Arc are still being updated, though, just not by Paul Graham.

Is whatever benefit you see worth the hassle when sharing scripts or setting up servers?

If you mean for exa specifically, then yes. It’s mostly compatible with ls. Never caused problems in years now.

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.

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.

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_63c61dc3d45cb95ec8a...

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_e2da91a07e2b2bc0234...

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.

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.

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.

Or, if you actually read the thread you’re replying to, “modern frameworks” where none of that is true.

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.

https://gist.github.com/Restuta/cda69e50a853aa64912d react is 31kb vue is 20kb preact is 4kb. depends on the framework but 500% isnt far off

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.

https://gist.github.com/Restuta/cda69e50a853aa64912d

react is 31kb vue is 20kb preact is 4kb

JQuery Minified and GZipped is also 30KB: https://mathiasbynens.be/demo/jquery-size

When doing comparisons, don't be disingenuous. Compare like numbers.

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.

whoops i assumed the 85k was already gzipped. fair enough

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.

> 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.

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.

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.

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.

Safari shards their cache by first party domain, so you don't get that caching benefit there.

Didn't know that. Looks like Safari is continuing it's devolution into becoming the next IE.

Advertisers have abused every single factor possible for tracking, including ETAGs and many other aspects of cache. Don't blame Safari for protecting it's users from disingenuous and dodgy tracking.

A single stable identifier would've solved the whole situation and Apple already had it with Advertising ID. Exposing that to the browser would've been enough so Safari could've been ahead of the curve.

Yeah, all you need to do is include a persistent identifier shared across all sites in the world! In fact, this solution is so great you don’t even need cookies anymore and you never get logged out if you accidentally delete them!

Is this sarcasm? The Advertising ID system is from Apple and in use in all apps, and it can be reset at anytime. It increases privacy, security, and efficiency.

Yeah, it’s efficient alright. Therefore the advertising ID is only accessible to apps that have declared their interest and these have to meet specific requirements. Not just any random website.

I don’t care what you or your industry today decides it ’needs’, you’re not getting a persistent webwide tracking ID.

"Solved the whole situation"? From what perpective? Completely killing privacy is not a solution, quite the opposite.

Advertising ID is Apple's own standard and already in use. It's what mobile apps use but it's the most privacy conscious method since it has no personal details and can be reset at anytime.

Making that available for apps and websites would've eliminated 99% of cookies and user syncing pixels since the industry could use a short-term stable ID to track engagement and conversions.

> since it has no personal details

Unfortunately the industry doesn't work like that, the name of the game is "collect everything and anything at any cost".

It is so bad that there is barely any difference between the behavior of "legal/legit" players (established advertisement businesses like Google) and scammers, Google for example bypassed 3rd party cookie restrictions on Safari, just like sophisticated scammers use any means to collection information on their targets for social engineering.

What this means is that not only there is no reason to believe that advertisers will be happy with a short-term stable ID akin to Apple's Advertising ID, they have time and time proven to go above and beyond to track users by any and every mean possible.

So what introducing something like Apple's Advertising ID to web will do is merely add yet another identifier to endless bucket of targeting methods already in use, sadly, it won't make advertisers stop abusing other things like cache so we can have nice things.

That's exactly how the industry works. I've spent more than a decade in it. We're talking about IDs, not tracking other information.

IDs are needed for 2 primary reasons: controlling ad frequency and attributing clicks and conversions to an ad impression.

Cookies worked for a long time but they were always considered loose short-term and anonymous identifiers. Apple had a opportunity to offer a better device-level option that had the same privacy but much better efficiency, and yet decided to break APIs and user experience instead, while also entrenching the big companies at the detriment of everyone else.

It's a privacy thing. I expect we'll see Firefox and Chrome sharding cache as well.

jQuery still does a lot of useful stuff. The best advertisement for jQuery, ironically, is this site: 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.

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.

> 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.

>>However, to do that, you have to have the entire JQuery library loaded as well.

But you didn't have to write that code or debug it.

Nowadays you'd use fetch anyway which would reduce that code to not much more than the jQuery samples.

That is, if you don't need to support IE (And I feel like we're finally in the phase where it slowly, but steadily dies off). Otherwise you can ponyfill it.

> 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.

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.

Just curious, what's your opinion on their decision to remove the headphone jack?

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.

That’s what people would’ve felt about floppys. I can say I don’t really care about the removal of headphone jack. But I’m not assuming most people feel that way.

Now you know how everyone else felt when Apple killed the floppy.

I don't follow your logic. When the floppy was killed, there were better replacements available. There were devices just as portable, larger capacity, and faster access. It just plugged into a different port, and came in a different form factor.

Switching from wired to wireless giving up performance capabilities (ex: over ear headphones vs ear buds) forcing one to recharge batteries etc is not even in the same ballpark as the loss of the floppy.

You had to buy another device. You couldn't use your collection of data and programs stored on those floppies. Many questioned, "What's wrong with floppies?". And the collection of same questions being mentioned in this thread about earphones.

> when they released the first machine without a floppy I had already said good riddance to lame 1.5MB slower than christmas devices.

Yeah, but you're probably a nerd. I was working in a university computer lab at the time and people were always bringing in their (usually infected or damaged) floppies so they could print out an assignment or whatever. I was very happy about the decision but it freaked a lot of people out.

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.

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.

@sam0x17 If you have the time, take a look at this JS framework I put together ( https://github.com/elliotnb/nimbly ) and it's observer library dependency ( 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.

This sounds super nice. Checking it out!

@sam0x17 Awesome! The best way to get started is to take a look the basic set of sample components: https://github.com/ElliotNB/nimbly/tree/master/sample

The README is more like a reference manual. If you try to learn how the framework works just by reading the README, it'll probably just lead to confusion.

Polymer or the more light-weight LitElement.

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

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.

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.

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

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.

> 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.

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

Reply on news.ycombinator.com