Maybe we could tone down the JavaScript(eev.ee)
eev.ee
Maybe we could tone down the JavaScript
https://eev.ee/blog/2016/03/06/maybe-we-could-tone-down-the-javascript/
12 comments
The "You name a critical .js bundle something related to ads" point is something toward which I'm particularly unsympathetic. The fact that most ad blockers (a) are whitelist-based and (b) contain blunt-edge/naive implementations leads me to believe that false positives are the problem of the ad blocker developer and ad blocker user, not the developer of the website.
If Joe or Jane developer of Acme Demolition Inc. names a Javascript file `ad_main.js`, the burden of resolving the my-ad-blocker-is-blocking-this-file problem is not on them.
This is why I've yet to find an ad blocker that I would recommend to anyone without web development knowledge.
If Joe or Jane developer of Acme Demolition Inc. names a Javascript file `ad_main.js`, the burden of resolving the my-ad-blocker-is-blocking-this-file problem is not on them.
This is why I've yet to find an ad blocker that I would recommend to anyone without web development knowledge.
And I'd argue the opposite, based on desire paths.
People will bend the Web to suit their goals. You as a web dev with a need for ads revenue focus on that. Me as a web user with a need for information and pathological hatred of anything distracting, focus on my needs. Users with visual and motor disabilities (I support a community of same) are quite actively thwarted by many revenue-positive factors.
My fix for a bunch of Web gunk is to have a default set of client-side CSS that kills, well, a bunch of crap. Flyovers, modals, interstitials, fixed header/footer elements, and a slew of other stuff. Ello's front-end guy pretty understandably said it voided my warranty for the World Wide Web. And he's not wrong.
But man does it make things suck ever so much less.
Which gets to the point: much of the stylesheet is glob-match patterns on descriptors that are frequently annoying as fuck-all. Which was why I'd showed it to him. That sheet, or others like it, are going to be in the client world, and soon, and if you're putting flyover and modal keywords in your selectors, they're going to get blocked.
Yes, it's an iterative arms race. Your turn.
(And: ultimately the solution is to fix the revenue/compensation model for published works. Online and elsewhere. That'll take a while, but it'll also fix very nearly everything wrong with the present iteration of the Web.)
People will bend the Web to suit their goals. You as a web dev with a need for ads revenue focus on that. Me as a web user with a need for information and pathological hatred of anything distracting, focus on my needs. Users with visual and motor disabilities (I support a community of same) are quite actively thwarted by many revenue-positive factors.
My fix for a bunch of Web gunk is to have a default set of client-side CSS that kills, well, a bunch of crap. Flyovers, modals, interstitials, fixed header/footer elements, and a slew of other stuff. Ello's front-end guy pretty understandably said it voided my warranty for the World Wide Web. And he's not wrong.
But man does it make things suck ever so much less.
Which gets to the point: much of the stylesheet is glob-match patterns on descriptors that are frequently annoying as fuck-all. Which was why I'd showed it to him. That sheet, or others like it, are going to be in the client world, and soon, and if you're putting flyover and modal keywords in your selectors, they're going to get blocked.
Yes, it's an iterative arms race. Your turn.
(And: ultimately the solution is to fix the revenue/compensation model for published works. Online and elsewhere. That'll take a while, but it'll also fix very nearly everything wrong with the present iteration of the Web.)
I'm a heavy ad blocker user, and I have never needed to whitelist anything myself. All the adblock lists I've ever used consciously avoid anything so generic it'd catch ad_main.js on J. Random Website. (Hell, if anything they undercatch—I have several rules for things which are ads and aren't blocked.)
I think the root of the problem is that browser vendors break stuff all the time. A new browser comes out and now breaks your ten year old web page ... Then the web dev team says fuck it we'll only support Firefox and Chromium, and start using features that only works on those browsers.
Ten years ago, web dev was all about getting your page to work on all platforms. But today we have hundreds of possible combinations of OS x Browser x Extensions, so it's just impossible.
I try to only use browser features that are three years old and "standard". But not even that works.
Phone/Ipad browsers are the biggest offenders of breaking stuff.
Ten years ago, web dev was all about getting your page to work on all platforms. But today we have hundreds of possible combinations of OS x Browser x Extensions, so it's just impossible.
I try to only use browser features that are three years old and "standard". But not even that works.
Phone/Ipad browsers are the biggest offenders of breaking stuff.
You have some valid points about how we use javascript for many parts of our web pages that don't need javascript. I would love for the web to be fully accessible without javascript, but we have to remember that there are a small percentage of people currently using the web without javascript. Im sure twitter has their reasons for using javascript for the simple tasks that are solvable without the assistance of javascript. I would imagine that it wouldnt be cost efficient, if nothing else, not a top priority to make their site accessible without javascript due to the small user base that doesn't use javascript.
There are two substantial online communities which don't use javascript, or don't use it reliably.
Robots and the disabled.
Bots include major search engines -- Google, Bing, DDG, etc. And yes, they may parse some JS, but it's quite spotty. But there are also a bazillion custom Web scrapers (not everything's APId, scraping is MVP) which harvest information for purposes good and otherwise.
The disabled use screen-readers or text-to-speech to render content for those who cannot see your pixel-perfect design.
I'm leaning to a "plaintext first" school of Web design. First plan a plaintext page, then mobile, then full desktop. See where that gets you.
Robots and the disabled.
Bots include major search engines -- Google, Bing, DDG, etc. And yes, they may parse some JS, but it's quite spotty. But there are also a bazillion custom Web scrapers (not everything's APId, scraping is MVP) which harvest information for purposes good and otherwise.
The disabled use screen-readers or text-to-speech to render content for those who cannot see your pixel-perfect design.
I'm leaning to a "plaintext first" school of Web design. First plan a plaintext page, then mobile, then full desktop. See where that gets you.
Given that Twitter is massively successful and used by millions everyday I don't think it is a good target for complaining about slow loading times and poor performing JavaScript. Often in business 'good enough' really is good enough. Gold plating code is something many developers (including myself) make the mistake of trying to do all the time. But the difference between 'good enough' and gold plating is often not worthwhile for the business.
OH GOD YES THIS PLEASE.
I'm curious about two things.
A) What search hotkey to use if not '/'
B) Why does your JS load slow? Did you fix that part?
I build web-apps and try to think "JS second". I've noticed that my customers like fast loading, consistent pages. These "magpie" like decisions harm the customer experience.
A) What search hotkey to use if not '/'
B) Why does your JS load slow? Did you fix that part?
I build web-apps and try to think "JS second". I've noticed that my customers like fast loading, consistent pages. These "magpie" like decisions harm the customer experience.
The issues in the article are very similar to advices in some old book (from "yay, AJAX"-era) about JS I read in the past. Looks like not too many people took them to heart.
The whole of html is full of these. Let's be blunt: it's a terrible platform, just as JavaScript's DOM API is terrible. Everything about the web is bad, but we make it good thanks to the combined might of the computing industry.
JavaScript's a mediocre language being used to pave over the weaknesses of a layout engine that can't centre things vertically and can't navigate without slow server interactions unless you want to confuse the user with one long page full of #anchors.