Earlier quoted context omitted.
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.
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 existin…
jQuery CDN having SSL issues
51–59 of 59 posts
Re: jQuery CDN having SSL issues
#52Earlier quoted context omitted.
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 s…
No. It's just a problem of laziness, and possibly ego, of developers. There are apps using browser as execution environment and there are websites. You wouldn't expect a client-side drawing tool, WebVR game or real time visualization of blockchain transactions to work without JS enabled. However, you can easily expect a social network, mail client, news page, task app, and to some extent even things like IM to work w…
We're talking about large organizations. No single developer is making these decisions. And the question is about resource allocation, if the choice is between improving the core experience or implementing an experience that > "That's core" is just an excuse for poor architecture - it's only core because you chose to make it so.
It is core because the internet has democratically made it so. You're speaking for a very vocal minority. We're choosing not to implement a special mode for people who self-selected to receive a broken web experience. Fortunately that same demographic knows how to resolve the issue they caused.
> no progressive enhancement for no good reason.
A richer user experience is a very good reason. If the choice is between making the site richer and more immersive for 99% of users, and leaving 1% of users who wish to be contrarian for no reason out in the cold? So be it. A worthy sacrifice, in particular as this 1% selected themselves for punishment.
You're welcome to pick and choose any arbitrary part of the web to disable, maybe JavaScript, maybe CSS, maybe font rendering entirely, maybe disable images, but it gets a little silly when you blame others for your self imposed breakages. You don't want it broken? Don't break it.
Re: jQuery CDN having SSL issues
#53Earlier quoted context omitted.
No. It's just a problem of laziness, and possibly ego, of developers. There are apps using browser as execution environment and there are websites. You wouldn't expect a client-side drawing tool, WebVR game or real time visualization of blockchain transactions to work without JS enabled. However, you can easily expect a social network, mail client, news page, task app, and to some extent even things like IM to work w…
> No. It's just a problem of laziness, and possibly ego, of developers. We're talking about large organizations. No single developer is making these decisions. And the question is about resource allocation, if the choice is between improving the core experience or implementing an experience that > "That's core" is just an excuse for poor architecture - it's only core because you chose to make it so. It is core becaus…
Re: jQuery CDN having SSL issues
#54One more reason to use Decentraleyes. https://decentraleyes.org
Re: jQuery CDN having SSL issues
#55Earlier quoted context omitted.
> No. It's just a problem of laziness, and possibly ego, of developers. We're talking about large organizations. No single developer is making these decisions. And the question is about resource allocation, if the choice is between improving the core experience or implementing an experience that > "That's core" is just an excuse for poor architecture - it's only core because you chose to make it so. It is core becaus…
I’d dearly love to have stats that aren’t a few years old, but when GOV.UK last ran an experiment it was 1.1% of people who arrived without JS (~1m page views a month) split into 0.3% who’d deliberately disabled JS and 0.8% who had a broken JS environment for another reason. Like I said, it’s a reliability issue, not pandering to people who choose to go out the way to ‘break’ their environment. So yes, by choosing a…
Even according to your own statistics, we're prioritizing 98.9% of user's needs over 1.1% of user's needs (or more accurately 99.2% of users against the broken 0.8%, since we won't do anything for the 0.3% who decided to break it on purpose).
Resources allocated to 0.8% of the userbase aren't free, they come from time that could be better spent improving the experience for everyone else.
> That’s potentially fine if the cost balance equation works out that way for you, but it’s a specific choice you’ve made to not support people who through no fault of their own don’t meet the requirements of the environment you’ve decided to create.
That's fine. The same 0.8% with a broken browser or proxy won't find elsewhere on the internet any more friendly to them. The best they can hope for is a small slither of sites with fallback, but the user experience will be so terrible they're better off just fixing the issue than continuing.
I find it funny that people spent years making these same arguments, but used assistive technologies as their cornerstone, now that assistive technologies (and the aria standards) fully support rich JavaScript sites, the argument has shifted to some hand waving minority that cannot even be quantified. We both know this is really about the NoScript crowd (and similar, like RequestPolicy), the other people with a broken web experience have far more significant issues that no one site can hope to mitigate.
Re: jQuery CDN having SSL issues
#56Earlier quoted context omitted.
No. It's just a problem of laziness, and possibly ego, of developers. There are apps using browser as execution environment and there are websites. You wouldn't expect a client-side drawing tool, WebVR game or real time visualization of blockchain transactions to work without JS enabled. However, you can easily expect a social network, mail client, news page, task app, and to some extent even things like IM to work w…
> No. It's just a problem of laziness, and possibly ego, of developers. We're talking about large organizations. No single developer is making these decisions. And the question is about resource allocation, if the choice is between improving the core experience or implementing an experience that > "That's core" is just an excuse for poor architecture - it's only core because you chose to make it so. It is core becaus…
There is no choice. You can either make it properly, in accordance to best engineering techniques, that make it work good enough with those restrictions and still work as rich as you want when you don't impose them. Or you can make it broken by doing it the lazy way.
Also, there are plenty of reasons to disable JavaScript. It often makes the web browsing experience better, faster and more energy efficient. Sometimes you care about those things way more than any perceived "richness". In many cases, lazy webdevs and their broken code are the only reasons why it might be worse.
Re: jQuery CDN having SSL issues
#57Earlier quoted context omitted.
I’d dearly love to have stats that aren’t a few years old, but when GOV.UK last ran an experiment it was 1.1% of people who arrived without JS (~1m page views a month) split into 0.3% who’d deliberately disabled JS and 0.8% who had a broken JS environment for another reason. Like I said, it’s a reliability issue, not pandering to people who choose to go out the way to ‘break’ their environment. So yes, by choosing a…
> So yes, by choosing a JS-only environment you’re prioritising developer needs over user needs. Even according to your own statistics, we're prioritizing 98.9% of user's needs over 1.1% of user's needs (or more accurately 99.2% of users against the broken 0.8%, since we won't do anything for the 0.3% who decided to break it on purpose). Resources allocated to 0.8% of the userbase aren't free, they come from time tha…
Re: jQuery CDN having SSL issues
#58One more reason to use Decentraleyes. https://decentraleyes.org
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.