Yes it has improved, mostly thanks to Cloudflare network. From my machine (gigabit fiber), for git clone https://github.com/torvalds/linux --depth=1 --no-checkout a warmed clone through gitdelivr.net took ~5s versus ~18 directly from GitHub (Github seems to cap clones at around 30 MB/s or 250 mbit/s) so about 3x faster in that case.

You're right, that line was overstated in the homepage. I guess security model as with any public mirror in FOSS world?

Git hash checks protect object integrity, so GitDelivr can't silently corrupt a packfile without Git noticing, but that still doesn't make it fully trusted.

Yes the code could still lie about refs/HEAD and serve a different but internally valid history, and Git would accept it. The endgame here is if this is something Cloudflare would pick up (or any other big player) to offer it for free, then you'd trust it because it's a big name (and not a new domain bought yesterday after a weekend project heh)

So the accurate security model is a) GitDelivr preserves Git object integrity b) it does not by itself guarantee authenticity of refs in a way you can verify it c) in that sense it's as close to using any other HTTPS Git mirror or CDN?

To me, all of the JQuery examples are much nicer to read and write. Sure, you can use raw JS, but why copy annoying boilerplate? (I'm not a JS dev, so I don't have a dog in this fight).

The authors of that page seem to be making their suggestions principally for library authors, to avoid an otherwise unnecessary dependency on jquery.

That page does an excellent job of convincing me to carry on using jQuery.

  if (el.classList)
    el.classList.contains(className);
  else
    new RegExp('(^| )' + className + '( |$)', 'gi').test(el.className);

vs

  $(el).hasClass(className);

<shivers>

I don't think anyone would suggest you write all of the first codeblock every time you want to check a class. You'd put it in a function and call that, much like jquery does.

The point is that this site explains how you do it because a) that's probably easier than trawling through the jquery source b) including this polyfill when you know you need it might save you from requiring all the rest of jquery.

In that case I'd be much more likely to use a minimal jQuery replacement such as umbrella.js mentioned elsewhere here. That's 3k (vs about 28k for jQuery) so counters most of the 'bloat' objections with jQuery. I'm sure it will still irk some some purists on other grounds however.

Yep, the use of RegExp is enough.

Is that comparison supposed to show that jQuery is bad or what exactly? Because it's clear that jQuery is much more concise in every single case.

No. That site is giving helpful alternatives so that library authors can avoid having jquery as a dependency.

They are just recreating jQuery, no?

Greenspun's tenth rule of js apps?

You aren't recreating jQuery by using basic JavaScript syntax.

isn't JavaScript what jQuery is written with?

Yes, but why drag in 30k of additional library unnecessarily?

Yes use jQuery if it's really providing benefit, but if you're only using it for a few things, you may be better off just doing in in plain javascript, even if it's a bit longer.

Every library you add has an overhead cost on the end user as they have to fetch it and process it. It's easy to lose track of that when you're developing and testing against local webservers or on computers vs mobile, but there is strong value in keeping things small and with as few unnecessary dependencies as possible :)

Not sure if you read the page, but many of the examples are not "basic JavaScript syntax", the fadeIn approach is a function that attempts to replicate jQuery's, probably poorly.

No, jQuery did not invent the concept of fading in. It doesn't even have a unique implementation of it, it just does a few CSS changes that you can easily do without jQuery to get the exact same result.

This is as ridiculous as having a "addition" module in jQuery and saying that people who do addition in JavaScript are just reinventing jQuery.

Wrapping jQuery around something simple (like fading in) does not make it into jQuery. If anything this just demonstrates who incredibly unknowledgeable people are about where jQuery ends and JavaScript begins.

The reason the site exists is explained on the site itself.

A good example of why I will continue using jQuery for the time being.

Yes, but it's always good for us to remember that everything has a cost, and so does jQuery (memory footprint/new dependency/complexity). It's a conscious decision we should make on every project, and yes in most cases it would take 0.5s to make a decision in jQuery's favor. We should do so anyways, since it's good practice. Taking into account the presumed state of Moore's Law and all.

I'm surprised that there's no youmightnotneedprintf.com

I'm surprised you are comparing jQuery (a non-trivial additional dependency with reasonable dependency-less alternatives) to printf (a small piece of a dependency you most likely pull in already with).

One man's trivial is another man's bother. I consider 30k (less than some images or the rather popular fonts) to be quite trivial for most purposes, and if it gives me a nicer syntax for common operations, it's probably worth it.

On the other hand, I've seen actual backlash against printf implementations in libs and the bloat they're causing, never mind potential bugs [1].

So there you go.

[1]: https://www.fefe.de/dietlibc/FAQ.txt

I'm not advocating for or against jQuery or printf. I'm just pointing out that equating the two (in size, utility, or potential gains by avoiding them) doesn't make a lot of sense.

jQuery's ratio of size-versus-additional-utility is much larger than printf's, even more so if you consider typical use cases of each.

But it isn't even a fair comparison to begin with. How about comparing jQuery to libc. I'd still argue the ratio is in libc's favor, but no one would have written "I'm surprised that there's no youmightnotneedlibc.com".

libc seems much more substantial, maybe we can split the difference and call it "youmightnodneedstdio.com", although that sounds much less pithy.

I still wouldn't be so sure about that ratio. The people decrying the printf family of functions are often targeting small statically linked binaries. Where a few kb shaved off might be a bigger chunk than 30kb are for your usual multi-megabyte front page of today's web.

People who target tiny static binaries are by far in the minority of libc users.

Isn't it more like comparing jQuery with libc?

It would have been if he said "I'm surprised that there's no youmightnotneedlibc.com".

As soon as you do that though (put the two on equal-ish grounds), you realize it doesn't make much sense and it might as well not have been written in the first place.

libc would be more like the standard DOM specification.

printf is a part of the standard C library.

I don't think it's a question of necessity, it's just more convenient and usually a lot less code than doing the same thing without it.

HN is a social bookmarking site.

Anything that gets voted to the first page IS de facto HN content, as voted by HN users, unless it specifically violates some rule.

That rule would be the first rule in the guidelines:

Off-Topic: Most stories about politics, or crime, or sports, unless they're evidence of some interesting new phenomenon. [...] If they'd cover it on TV news, it's probably off-topic.

From https://news.ycombinator.com/newsguidelines.html

> unless they're evidence of some interesting new phenomenon.

I think this article fits the description.

That fight was lost a long time ago.

Without commenting on this specific article, if there's one thing I learned from reddit, it's that heavy moderation >>> "the users choose and everything is free".

An example of the latter is pretty much any big subreddit you think of as awful and full of nonsense. Some examples of the former include the most well-respected science and history-related subreddits. I would honestly prefer there to be heavy moderation on HN with someone who has a vision for what "HN content" should be (even allowing for the fact that those people may disagree with me) than a free-for-all.

Random sites on the Internet are not the entire Internet, nor are they the government. I believe in Free Speech when it comes to people with power over me, not so much when it comes to websites that I can choose to leave at any time.

Oh, so now you decide whats good for HN and whats not? HN is "democracy", users choose whats right.

I use it everyday and it helps a lot when you connect it to various services (github, trello etc.) It offers dozens of them: https://slack.com/integrations

Ditto this, the integrations are really the icing on the cake for Slack.

We've even written notifications from our own applications to push into Slack, so we get notified on everything from continuous integration test results and deployments through to analytics and sales figures.

love to understand why slack is better - is it primarily because of integrations? or is it something more?

WhatsApp and Slack are similar applications with totally different user base, so no, WhatsApp will not kill Slack, nor it will "attack" its user at all.

Thanks, works!

The problem is I never archive the e-mail and I'm looking for simple is:unreplied.

So what would happen with all the e-mail you get that doesn't require a reply?

(This is where the strength of Archive comes in)