6 ms·

jQuery CDN having SSL issues

61 points by justindocanto 8y ago

justindocanto 8y ago
Starting to see complaints, questions, etc. on twitter about it too. https://twitter.com/search?f=tweets&q=jquery https://twitter.com/search?f=tweets&q=jquery
8bitben 8y ago
Yep, this just broke my project :/
rharb 8y ago
Potentially related to the Chrome 66 update and Symantec stuff?
- justindocanto 8y ago
  Broken on latest versions of Safari, FireFox, Edge, etc. as well
deleted 8y ago
[deleted]
Murrawhip 8y ago
It's not an expiry. It's a cert name mismatch. CN is *.ssl.hwcdn.net
- justindocanto 8y ago
  Updated to a generic "having SSL issues"
- calcifer 8y ago
  My guess is they decided to switch to Highwinds as their CDN (don't know what it was before) and they didn't plan it correctly.
  - johntrimis 8y ago
    FYI: Stackpath owns Highwinds. It was likely an internal configuration issue at Stackpath.
nwah1 8y ago
Great opportunity to strip out unnecessary uses of jQuery, and move to vanilla javascript. http://youmightnotneedjquery.com/ http://youmightnotneedjquery.com/
- bungball 8y ago
  more like great opportunity to use a different cdn
- sergiotapia 8y ago
  I haven't used jquery in about 2 years, pure javascript and maybe some lodash functions imported into my es6. Give it a try, you might not need it!
  - madeofpalk 8y ago
    youmightnotneedlodash dot com
Someone1234 8y ago
It is too bad that the HTML standard has no built in way to fallback. They've added a cryptographic hash/integrity and the async/defer attributes to the script tag, but something as essential as a fallback if a script or stylesheet fails to load (which the browser is best placed to know), has no built in functionality. Instead you're left doing JavaScript tricks which for missing CSS gets a little ugly[0]. But CDN with local fallback (or visa versa) has been common now for decades but yet no official support at all. Honestly if the integrity attribute is specified the browser should just be able to fall back to a cached copy it has (e.g. jquery.1.2.3.min.js has a crypto hash of ABC123, and I have that file already). [0] https://stackoverflow.com/questions/7383163/how-to-fallback-to-local-stylesheet-not-script-if-cdn-fails https://stackoverflow.com/questions/7383163/how-to-fallback-...
- _jmar777 8y ago
  Yeah, I think the latest and greatest in web standards for solving this problem would probably be using a Service Worker to transparently handle the failure and serve up a fallback... but like you said, that's a JavaScript-based solution.
- robin_reala 8y ago
  I mean, the fallback mechanism is progressive enhancement. It’s a reliability mechanism more than anything - if JS (or part of the JS) fails to load the site should fall back to a version that potentially reduces the interactivity but allows essential functions to continue.
  - Someone1234 8y ago
    Progressive enhancement is largely a myth. A lot of libraries, JQuery, Lodash, Angular, Vue, React, Bootstrap's JS, module loaders, etc aren't simply offering "improved interactivity" they're offering core functionality. In essence the site runs on these libraries, if you remove them there's nothing left to regress too. I've worked in several companies and never seen progressive enhancement used. It might have made sense back in the IE6 era when JavaScript was just for whiz-bang, these days JS libraries are holding the whole site's data context/state and generating Ajax as needed (Vue, Angular, React, etc). That's core, there's nothing progressive that can be removed from that. Progressive Enhancement only makes sense for small toy sites or for academics to play with. Even Netflix's famous examples are about web services going offline, not losing core JavaScript libraries.
leepowers 8y ago
This is why you self-host all project dependencies.
- Someone1234 8y ago
  But that costs you cache hits, increases the real world size of your site, and slows loading. I'm sure mobile users with metered internet would prefer you didn't download that 100 KB JavaScript library for the nth time.
  - madeofpalk 8y ago
    Does it really?
  - leepowers 8y ago
    It's more complex than that. Mobile networks are mostly hampered by latency - each additional HTTP request to a different domain requires another TCP coldstart and handshake, DNS lookup, TLS setup, etc. Many times the 100KB of JavaScript is faster to load when minified and combined with other site code and served compressed over a single HTTP request or streamed via HTTP/2. It's almost always faster to use an existing connection than to start a new one. Also there isn't one canonical version of jQuery. There's dozens of potential versions available[1]. So it's not immediately clear that a user will have the version a site depends on. [1] https://mathiasbynens.be/demo/jquery-size https://mathiasbynens.be/demo/jquery-size
    - Someone1234 8y ago
      It isn't faster than not re-requesting the resource at all because it was previously downloaded from the CDN which is what the discussion is about.
jimaek 8y ago
https://www.jsdelivr.com https://www.jsdelivr.com is a good alternative. We actually monitor for https failures and automatically remove the problematic CDN.
kreitje 8y ago
Looks like it's working again.
jakobdabo 8y ago
I always self-host my JS/CSS libraries: the connection is already open (thanks to keep-alive) so what's the problem of serving a couple of more KiBs of compressed data instead of making an additional DNS request and a new connection to a CDN? I understand that the CDN version of the library may have already been cached by the browser while visiting other websites, but does it really save that much time/traffic compared to self-hosting?
- penagwin 8y ago
  I'm not taking a side, just trying to add some numbers. Let's ignore the privacy/uptime concerns for the sake of this comment. If every site you visit has 350kb of stuff that would benefit from a CDN JS but also some CSS and fonts (google fonts, bootstrap, etc.) If you visit 50 pages a day in a 30 day month, that's a little over 500mb of data. .35mb x 50sites x 30days = 525mb That would be a ton of easily avoidable data in regards to mobile plans depending on where you are. This number isn't 100% accurate though, many "normal" (read - not techy hackernews readers) might only visit say a dozen sites a day or less (let's ignore apps like facebook/snapchat/etc). Even that might be a stretch. Then again students and other "savy" users might be going across hundreds of new sites a day. For you the host? Unless you're a massive beast, most of us "hobbiests" fit within the free bandwidth of 5$ vps services anyway.
  - manigandham 8y ago
    Unfortunately everyone still ends up using many different versions or adding other unnecessary querystring parameters so that each site still effectively ends up with their own file to download.
  - robin_reala 8y ago
    That’s assuming every site is using the same CDN and the same version of the library. Seeing as that’s not the case you can cut that by at least an order of magnitude. Secondly, most users visiting 50 pages a day will not visit 50 sites a day but more like 5 pages a site across 10 sites, or even 10 pages a site on 5 sites. Now let’s add in to the user the external privacy cost of being tracked across multiple sites and it starts to look a little less appetising again from the user’s point of view.
keane 8y ago
Original, jQuery CDN: https://code.jquery.com/jquery-X.Y.Z.min.js Google: https://ajax.googleapis.com/ajax/libs/jquery/X.Y.Z/jquery.min.js Microsoft: https://ajax.microsoft.com/ajax/jquery/jquery-X.Y.Z.min.js Microsoft ASP.NET: https://ajax.aspnetcdn.com/ajax/jquery/jquery-X.Y.Z.min.js jsDelivr: https://cdn.jsdelivr.net/npm/jquery@X.Y.Z/dist/jquery.min.js cdnjs: https://cdnjs.cloudflare.com/ajax/libs/jquery/X.Y.Z/jquery.min.js Yandex.ru: https://yastatic.net/jquery/X.Y.Z/jquery.min.js
- zackbloom 8y ago
  Does anyone have a performance benchmark comparing them?
  - keane 8y ago
    While Google and Microsoft are not included, JSDelivr (StackPath+fastly+CloudFlare+Quantil) compares themselves to MaxCDN (now StackPath which is the official jQuery CDN) and CloudFlare (the cdnjs provider) here: https://www.cdnperf.com/cdn-compare?type=performance&location=world&cdn=cloudflare-cdn,jsdelivr-cdn,maxcdn&datefrom=2018-3-19&dateto=2018-4-19 https://www.cdnperf.com/cdn-compare?type=performance&locatio... KeyCDN has an online asset performance tool that we can use to compare the hosted jquery.min.js files. The numbers included here are results received (to the San Francisco location) in ms of [DNS lookup time] / [time to connect to server] / [overhead of TLS connection on individual asset] / [time from client HTTP request to receiving first byte from server]: Original, jQuery CDN: https://tools.keycdn.com/performance?url=https://code.jquery.com/jquery-3.3.1.min.js?nocache=1 https://tools.keycdn.com/performance?url=https://code.jquery... 8 / 2 / 79 / 85 Google: https://tools.keycdn.com/performance?url=https://ajax.googleapis.com/ajax/libs/jquery/3.3.1/jquery.min.js?nocache=1 https://tools.keycdn.com/performance?url=https://ajax.google... 32 / 2 / 132 / 155 Microsoft: https://tools.keycdn.com/performance?url=https://ajax.microsoft.com/ajax/jquery/jquery-3.3.1.min.js?nocache=1 https://tools.keycdn.com/performance?url=https://ajax.micros... 128 / 3 / 122 / 130 Microsoft ASP.NET: https://tools.keycdn.com/performance?url=https://ajax.aspnetcdn.com/ajax/jquery/jquery-3.3.1.min.js?nocache=1 https://tools.keycdn.com/performance?url=https://ajax.aspnet... 128 / 3 / 114 / 120 jsDelivr: https://tools.keycdn.com/performance?url=https://cdn.jsdelivr.net/npm/jquery@3.3.1/dist/jquery.min.js?nocache=1 https://tools.keycdn.com/performance?url=https://cdn.jsdeliv... 64 / 3 / 118 / 129 cdnjs: https://tools.keycdn.com/performance?url=https://cdnjs.cloudflare.com/ajax/libs/jquery/3.3.1/jquery.min.js?nocache=1 https://tools.keycdn.com/performance?url=https://cdnjs.cloud... 64 / 2 / 118 / 125 Yandex.ru: https://tools.keycdn.com/performance?url=https://yastatic.net/jquery/3.1.1/jquery.min.js?nocache=1 https://tools.keycdn.com/performance?url=https://yastatic.ne... 32 / 139 / 667 / 993 When I tested them, only jsDelivr and cdnjs/Cloudflare recieved green results (under 200ms time to connect and under 400ms time to first byte) from all 16 worldwide test locations. Averaging the results between these two across 16 locations, I would go with jsDelivr who had a faster average TTFB. The fact that they are combining CloudFlare, Fastly, StackPath, and Quantil (who I had never heard of until today) might explain their global results.
guessmyname 8y ago
Years ago, I used to link the library from Google [1] or CloudFlare [2]. Nowadays, with all the Node.js stuff that goes around modern front-end, I don't see the point of embedding a JavaScript library from a CDN, unless that library is dependent on a remote service, e.g. Google Analytics, Google Maps, etc… That being said, if you are still maintaining a legacy website that depends on jQuery, you should consider to embed the library like this instead: <script>window.jQuery || document.write('<script src="/js/jquery.min.js"><\/script>')</script> [1] https://developers.google.com/speed/libraries/ https://developers.google.com/speed/libraries/ [2] https://cdnjs.com/libraries/jquery https://cdnjs.com/libraries/jquery
- 2trill2spill 8y ago
  > Nowadays, with all the Node.js stuff that goes around modern front-end, I don't see the point of embedding a JavaScript library from a CDN, unless that library is dependent on a remote service, e.g. Google Analytics, Google Maps, etc… That being said, if you are still maintaining a legacy website that depends on jQuery, you should consider to embed the library like this instead: What does Node.js have to do with deciding whether to get your static assets from a public CDN or not? I hope your not serving your static assets with Node.js.
  - guessmyname 8y ago
    > What does Node.js have to do with… There are tools like Grunt and WebPack (which depend on Node.js) that can bundle all your dependencies. I cannot provide details about how they work because I don't do front-end development, but I can tell you about years ago when I had to copy & paste both code and links to jQuery and other libraries like BackBone or Ember.js (relevant at the time) into my projects. Nowadays, web developers seem to prefer the use of tools that came from the Node.js ecosystem to handle these dependencies in a more "engineer-ish" way using NPM packages.
    - 2trill2spill 8y ago
      Yea you can still not bundle the actual library and grab it from a CDN, using webpack externals[1]. Using webpack doesn't really change anything. [1]: https://webpack.js.org/configuration/externals/ https://webpack.js.org/configuration/externals/
dusan76 8y ago
Looks like its working now https://code.jquery.com https://code.jquery.com
908087 8y ago
One more reason to use Decentraleyes. https://decentraleyes.org https://decentraleyes.org
- newscracker 8y ago
  I came here to suggest this (I use it on Firefox), but unfortunately, this is not an option for a set of users on smartphones and tablets.
  - 908087 8y ago
    Works great on Firefox/Android, but yes unfortunately that leaves iPhone users out in the cold still.
campuscodi 8y ago
Looks like they fixed it
petraeus 8y ago
Only hobby websites would host jquery off a cdn

61 points by justindocanto 8y ago

Starting to see complaints, questions, etc. on twitter about it too. https://twitter.com/search?f=tweets&q=jquery https://twitter.com/search?f=tweets&q=jquery

8bitben 8y ago

Yep, this just broke my project :/

rharb 8y ago

Potentially related to the Chrome 66 update and Symantec stuff?

justindocanto 8y ago
Broken on latest versions of Safari, FireFox, Edge, etc. as well

deleted 8y ago

[deleted]

Murrawhip 8y ago

It's not an expiry. It's a cert name mismatch. CN is *.ssl.hwcdn.net

justindocanto 8y ago
Updated to a generic "having SSL issues"
calcifer 8y ago
My guess is they decided to switch to Highwinds as their CDN (don't know what it was before) and they didn't plan it correctly.
- johntrimis 8y ago
  FYI: Stackpath owns Highwinds. It was likely an internal configuration issue at Stackpath.

nwah1 8y ago

Great opportunity to strip out unnecessary uses of jQuery, and move to vanilla javascript. http://youmightnotneedjquery.com/ http://youmightnotneedjquery.com/

bungball 8y ago
more like great opportunity to use a different cdn
sergiotapia 8y ago
I haven't used jquery in about 2 years, pure javascript and maybe some lodash functions imported into my es6. Give it a try, you might not need it!
- madeofpalk 8y ago
  youmightnotneedlodash dot com

Someone1234 8y ago

It is too bad that the HTML standard has no built in way to fallback. They've added a cryptographic hash/integrity and the async/defer attributes to the script tag, but something as essential as a fallback if a script or stylesheet fails to load (which the browser is best placed to know), has no built in functionality. Instead you're left doing JavaScript tricks which for missing CSS gets a little ugly[0]. But CDN with local fallback (or visa versa) has been common now for decades but yet no official support at all. Honestly if the integrity attribute is specified the browser should just be able to fall back to a cached copy it has (e.g. jquery.1.2.3.min.js has a crypto hash of ABC123, and I have that file already). [0] https://stackoverflow.com/questions/7383163/how-to-fallback-to-local-stylesheet-not-script-if-cdn-fails https://stackoverflow.com/questions/7383163/how-to-fallback-...

_jmar777 8y ago
Yeah, I think the latest and greatest in web standards for solving this problem would probably be using a Service Worker to transparently handle the failure and serve up a fallback... but like you said, that's a JavaScript-based solution.
robin_reala 8y ago
I mean, the fallback mechanism is progressive enhancement. It’s a reliability mechanism more than anything - if JS (or part of the JS) fails to load the site should fall back to a version that potentially reduces the interactivity but allows essential functions to continue.
- Someone1234 8y ago
  Progressive enhancement is largely a myth. A lot of libraries, JQuery, Lodash, Angular, Vue, React, Bootstrap's JS, module loaders, etc aren't simply offering "improved interactivity" they're offering core functionality. In essence the site runs on these libraries, if you remove them there's nothing left to regress too. I've worked in several companies and never seen progressive enhancement used. It might have made sense back in the IE6 era when JavaScript was just for whiz-bang, these days JS libraries are holding the whole site's data context/state and generating Ajax as needed (Vue, Angular, React, etc). That's core, there's nothing progressive that can be removed from that. Progressive Enhancement only makes sense for small toy sites or for academics to play with. Even Netflix's famous examples are about web services going offline, not losing core JavaScript libraries.

leepowers 8y ago

This is why you self-host all project dependencies.

Someone1234 8y ago
But that costs you cache hits, increases the real world size of your site, and slows loading. I'm sure mobile users with metered internet would prefer you didn't download that 100 KB JavaScript library for the nth time.
- madeofpalk 8y ago
  Does it really?
- leepowers 8y ago
  It's more complex than that. Mobile networks are mostly hampered by latency - each additional HTTP request to a different domain requires another TCP coldstart and handshake, DNS lookup, TLS setup, etc. Many times the 100KB of JavaScript is faster to load when minified and combined with other site code and served compressed over a single HTTP request or streamed via HTTP/2. It's almost always faster to use an existing connection than to start a new one. Also there isn't one canonical version of jQuery. There's dozens of potential versions available[1]. So it's not immediately clear that a user will have the version a site depends on. [1] https://mathiasbynens.be/demo/jquery-size https://mathiasbynens.be/demo/jquery-size
  - Someone1234 8y ago
    It isn't faster than not re-requesting the resource at all because it was previously downloaded from the CDN which is what the discussion is about.

jimaek 8y ago

https://www.jsdelivr.com https://www.jsdelivr.com is a good alternative. We actually monitor for https failures and automatically remove the problematic CDN.

kreitje 8y ago

Looks like it's working again.

jakobdabo 8y ago

I always self-host my JS/CSS libraries: the connection is already open (thanks to keep-alive) so what's the problem of serving a couple of more KiBs of compressed data instead of making an additional DNS request and a new connection to a CDN? I understand that the CDN version of the library may have already been cached by the browser while visiting other websites, but does it really save that much time/traffic compared to self-hosting?

penagwin 8y ago
I'm not taking a side, just trying to add some numbers. Let's ignore the privacy/uptime concerns for the sake of this comment. If every site you visit has 350kb of stuff that would benefit from a CDN JS but also some CSS and fonts (google fonts, bootstrap, etc.) If you visit 50 pages a day in a 30 day month, that's a little over 500mb of data. .35mb x 50sites x 30days = 525mb That would be a ton of easily avoidable data in regards to mobile plans depending on where you are. This number isn't 100% accurate though, many "normal" (read - not techy hackernews readers) might only visit say a dozen sites a day or less (let's ignore apps like facebook/snapchat/etc). Even that might be a stretch. Then again students and other "savy" users might be going across hundreds of new sites a day. For you the host? Unless you're a massive beast, most of us "hobbiests" fit within the free bandwidth of 5$ vps services anyway.
- manigandham 8y ago
  Unfortunately everyone still ends up using many different versions or adding other unnecessary querystring parameters so that each site still effectively ends up with their own file to download.
- robin_reala 8y ago
  That’s assuming every site is using the same CDN and the same version of the library. Seeing as that’s not the case you can cut that by at least an order of magnitude. Secondly, most users visiting 50 pages a day will not visit 50 sites a day but more like 5 pages a site across 10 sites, or even 10 pages a site on 5 sites. Now let’s add in to the user the external privacy cost of being tracked across multiple sites and it starts to look a little less appetising again from the user’s point of view.

keane 8y ago

Original, jQuery CDN: https://code.jquery.com/jquery-X.Y.Z.min.js Google: https://ajax.googleapis.com/ajax/libs/jquery/X.Y.Z/jquery.min.js Microsoft: https://ajax.microsoft.com/ajax/jquery/jquery-X.Y.Z.min.js Microsoft ASP.NET: https://ajax.aspnetcdn.com/ajax/jquery/jquery-X.Y.Z.min.js jsDelivr: https://cdn.jsdelivr.net/npm/jquery@X.Y.Z/dist/jquery.min.js cdnjs: https://cdnjs.cloudflare.com/ajax/libs/jquery/X.Y.Z/jquery.min.js Yandex.ru: https://yastatic.net/jquery/X.Y.Z/jquery.min.js

zackbloom 8y ago
Does anyone have a performance benchmark comparing them?
- keane 8y ago
  While Google and Microsoft are not included, JSDelivr (StackPath+fastly+CloudFlare+Quantil) compares themselves to MaxCDN (now StackPath which is the official jQuery CDN) and CloudFlare (the cdnjs provider) here: https://www.cdnperf.com/cdn-compare?type=performance&location=world&cdn=cloudflare-cdn,jsdelivr-cdn,maxcdn&datefrom=2018-3-19&dateto=2018-4-19 https://www.cdnperf.com/cdn-compare?type=performance&locatio... KeyCDN has an online asset performance tool that we can use to compare the hosted jquery.min.js files. The numbers included here are results received (to the San Francisco location) in ms of [DNS lookup time] / [time to connect to server] / [overhead of TLS connection on individual asset] / [time from client HTTP request to receiving first byte from server]: Original, jQuery CDN: https://tools.keycdn.com/performance?url=https://code.jquery.com/jquery-3.3.1.min.js?nocache=1 https://tools.keycdn.com/performance?url=https://code.jquery... 8 / 2 / 79 / 85 Google: https://tools.keycdn.com/performance?url=https://ajax.googleapis.com/ajax/libs/jquery/3.3.1/jquery.min.js?nocache=1 https://tools.keycdn.com/performance?url=https://ajax.google... 32 / 2 / 132 / 155 Microsoft: https://tools.keycdn.com/performance?url=https://ajax.microsoft.com/ajax/jquery/jquery-3.3.1.min.js?nocache=1 https://tools.keycdn.com/performance?url=https://ajax.micros... 128 / 3 / 122 / 130 Microsoft ASP.NET: https://tools.keycdn.com/performance?url=https://ajax.aspnetcdn.com/ajax/jquery/jquery-3.3.1.min.js?nocache=1 https://tools.keycdn.com/performance?url=https://ajax.aspnet... 128 / 3 / 114 / 120 jsDelivr: https://tools.keycdn.com/performance?url=https://cdn.jsdelivr.net/npm/jquery@3.3.1/dist/jquery.min.js?nocache=1 https://tools.keycdn.com/performance?url=https://cdn.jsdeliv... 64 / 3 / 118 / 129 cdnjs: https://tools.keycdn.com/performance?url=https://cdnjs.cloudflare.com/ajax/libs/jquery/3.3.1/jquery.min.js?nocache=1 https://tools.keycdn.com/performance?url=https://cdnjs.cloud... 64 / 2 / 118 / 125 Yandex.ru: https://tools.keycdn.com/performance?url=https://yastatic.net/jquery/3.1.1/jquery.min.js?nocache=1 https://tools.keycdn.com/performance?url=https://yastatic.ne... 32 / 139 / 667 / 993 When I tested them, only jsDelivr and cdnjs/Cloudflare recieved green results (under 200ms time to connect and under 400ms time to first byte) from all 16 worldwide test locations. Averaging the results between these two across 16 locations, I would go with jsDelivr who had a faster average TTFB. The fact that they are combining CloudFlare, Fastly, StackPath, and Quantil (who I had never heard of until today) might explain their global results.

guessmyname 8y ago

Years ago, I used to link the library from Google [1] or CloudFlare [2]. Nowadays, with all the Node.js stuff that goes around modern front-end, I don't see the point of embedding a JavaScript library from a CDN, unless that library is dependent on a remote service, e.g. Google Analytics, Google Maps, etc… That being said, if you are still maintaining a legacy website that depends on jQuery, you should consider to embed the library like this instead: <script>window.jQuery || document.write('<script src="/js/jquery.min.js"><\/script>')</script> [1] https://developers.google.com/speed/libraries/ https://developers.google.com/speed/libraries/ [2] https://cdnjs.com/libraries/jquery https://cdnjs.com/libraries/jquery

2trill2spill 8y ago
> Nowadays, with all the Node.js stuff that goes around modern front-end, I don't see the point of embedding a JavaScript library from a CDN, unless that library is dependent on a remote service, e.g. Google Analytics, Google Maps, etc… That being said, if you are still maintaining a legacy website that depends on jQuery, you should consider to embed the library like this instead: What does Node.js have to do with deciding whether to get your static assets from a public CDN or not? I hope your not serving your static assets with Node.js.
- guessmyname 8y ago
  > What does Node.js have to do with… There are tools like Grunt and WebPack (which depend on Node.js) that can bundle all your dependencies. I cannot provide details about how they work because I don't do front-end development, but I can tell you about years ago when I had to copy & paste both code and links to jQuery and other libraries like BackBone or Ember.js (relevant at the time) into my projects. Nowadays, web developers seem to prefer the use of tools that came from the Node.js ecosystem to handle these dependencies in a more "engineer-ish" way using NPM packages.
  - 2trill2spill 8y ago
    Yea you can still not bundle the actual library and grab it from a CDN, using webpack externals[1]. Using webpack doesn't really change anything. [1]: https://webpack.js.org/configuration/externals/ https://webpack.js.org/configuration/externals/

dusan76 8y ago

Looks like its working now https://code.jquery.com https://code.jquery.com

908087 8y ago

One more reason to use Decentraleyes. https://decentraleyes.org https://decentraleyes.org

newscracker 8y ago
I came here to suggest this (I use it on Firefox), but unfortunately, this is not an option for a set of users on smartphones and tablets.
- 908087 8y ago
  Works great on Firefox/Android, but yes unfortunately that leaves iPhone users out in the cold still.

campuscodi 8y ago

Looks like they fixed it

petraeus 8y ago

Only hobby websites would host jquery off a cdn