4 ms·

>If your site needs several different CDN’s to load it’s assets, for seemingly no reason then I generally leave; unless I need something from that particular pa

>If your site needs several different CDN’s to load it’s assets, for seemingly no reason then I generally leave; unless I need something from that particular page, in which case I give it about 2 or 3 goes of playing “which CDN serves the information I actually care about?”. >Any domain you use that isn’t obviously yours or a CDN or obviously related to what’s on the page (web stores get to load shoplift for example) is blocked because assume it’s just another advertising/analytics company. I'll generally agree with you (for the most part). With the exception of using a CDN to serve static assets that I control (like amazon s3 for instance), I have no issues with you or anyone else blocking all requests that they don't like! (and hell, i'm fine with you even blocking first party requests, but since you are the one doing it you'll know that it is the reason the site breaks). > Sites that load the DOM and contents into memory, but display a blank page until I unblock a bunch of JS are my pet peeve, and I make a note to never return to them. But I'm talking about applications, not static web pages or documents. Complaining that an application needs a programming language is like refusing to turn on any computer that runs any code at all. The code is the application, and if you don't want to run JS, then you don't want to use the program. (outside of viewing some static assets like images, or possibly the minimal DOM put into the HTML for bootstrapping, there's literally nothing else). >The carté Blanche approache is used because it’s faster and easier for me to find the minimal set of domains and resources to load than it is to get every website out there to not stuff their site full of trackers and unnecessary JS. Again, I'm more than happy to let you block what you want, i'll even help support your use case if you want and it's possible. But when you take your approach, and you start making a large percentage of the web use it, and you auto-update their browser plugins to use your approach so that things that were once working yesterday are now broken, and users don't have any real reason or understanding why. Or even worse, you begin making wild assumptions about why I need data backed by nothing but scaremongering (displaying warnings like "this site is trying to track you" when I give the option of offering the app in multiple languages...), then we have a problem.

FridgeSeal 8y ago
Well there's a strong argument to be made that there are plenty of people making web applications for information that doesn't need to be a web app. For example: your generic company website does not need to be a SPA with every conceivable JS feature thrown in. You are only presenting me some information, HTML and CSS is more than adequate, stop making things more complex than they need to be. In these case, I'm more than happy to break their stuff as it's seemingly the only way to get them to pay attention.
- Klathmon 8y ago
  But that's an entirely different argument, and it's one that always muddies up the conversation whenever I bring this up. This isn't a blog that loads 50 trackers and tons of superfluous animations and video, this is an application which is designed to do things for the user. It's stuff like a music making app, or a medication reminder and tracker application that takes a lot of your personal information to help you find accurate dosages. It's stuff like games or offline-caching documentation browsers with IDE integration and powerful client-side search, or self-hosted home automation controller systems, or chat applications, or a barcode scanner app that checks for coupons for things that you scan in a web browser, etc... And again, i'm fine if you don't want to run one aspect of it, you are the client and I can't technically control what you do, but complaining that the car won't work when you ripped the spark plugs out is dumb, and a mechanic that goes around taking out spark plugs every chance he/she gets so that people won't speed isn't helping.

FridgeSeal 8y ago

Well there's a strong argument to be made that there are plenty of people making web applications for information that doesn't need to be a web app. For example: your generic company website does not need to be a SPA with every conceivable JS feature thrown in. You are only presenting me some information, HTML and CSS is more than adequate, stop making things more complex than they need to be. In these case, I'm more than happy to break their stuff as it's seemingly the only way to get them to pay attention.

Klathmon 8y ago
But that's an entirely different argument, and it's one that always muddies up the conversation whenever I bring this up. This isn't a blog that loads 50 trackers and tons of superfluous animations and video, this is an application which is designed to do things for the user. It's stuff like a music making app, or a medication reminder and tracker application that takes a lot of your personal information to help you find accurate dosages. It's stuff like games or offline-caching documentation browsers with IDE integration and powerful client-side search, or self-hosted home automation controller systems, or chat applications, or a barcode scanner app that checks for coupons for things that you scan in a web browser, etc... And again, i'm fine if you don't want to run one aspect of it, you are the client and I can't technically control what you do, but complaining that the car won't work when you ripped the spark plugs out is dumb, and a mechanic that goes around taking out spark plugs every chance he/she gets so that people won't speed isn't helping.