My default policy is to not allow JS to run, so my experience is already mostly Javascriptless. And, I have to say, my user experience on most web sites is actually better when I don't allow Javascript to execute.
Sites that function without it are the exception, not the rule.
I think there are three or four that both require Javascript and that I want to use badly enough to allow JS.
When I encounter a web site that doesn't work without JS, I just move on. But I understand that others may not want to do the same.
/Applications/Firefox.app/Contents/MacOS/firefox" --no-remote --profile "$(mktemp -d)
Anyway, I was mostly inspired by an article on how to set up Steam in a container - it has all the details, including how to pipe Pulseaudio inside (so in my case, Youtube videos in Firefox can have sound). Except mine is debian-based (so debootstrap instead of pacstrap to populate the container).
Except it really is. Most websites are attached to businesses in some way. If you see statistics that the flash of unstyled content means 10% of your traffic leaves the site after less than a second you do what you can to fix it, and unfortunately that's often hiding everything until it's ready.
Pragmatically, most businesses would give up users who don't like tracking long before they give up users who care about styling, because there are just a lot more people who care about styling. It's an unfortunate fact of web life.
These sites usually aren't successful in that goal. Sure, they may be able to prevent content from showing up until the webfont has been loaded, but in my experience it's still extremely common for content to seriously jump around as the ads continue to load, especially on smaller screens (mobile).
So using "flash of unstyled content" as an excuse just doesn't hold up: users still have to learn to give a site a few extra seconds to settle before it's safe to interact without the content reflowing under your finger to put an ad where you wanted to tap, and breaking accessibility "for the sake of preventing FOUC" is dumb when you still have FOUC.
A similar tactic I've also seen that is even more unjustifiably anti-user is when the <body> element has "overflow: hidden" set until some heinous script that does it's own poor implementation of smooth scrolling can get up and running. These sites are universally improved by blocking such scripts and enabling native scrolling. This is one of the reasons why I believe browsers should be bundling together a large number of permissions that are off by default for every site the user has not flagged as being a web app. Google Maps has a good reason to interfere with scroll behavior; a news article does not.
Really?
Why does this happen at all? After all the "visible=false" is a styling..
Well, presumably it is to some people, or they wouldn't be setting it…
Yet I'm convinced you probably do enable js for various payment portals and govt/financial websites, and they often tend to go blank or loop out far more than the average site.
Apart from carefully cultivating a working noscript over years, the simplest solution may be to use a different browser for these sorts of interactions.
Reminds me to backup my whitelist. It's actually quite valuable.
I mean, it’s all the same framework-min.js working like a modern COBOL, not like custom mathematically significant compression or advanced dynamic P2P webpage distribution, right? Feels to me like a meta rendering engine could be created so none of the functions needs to be runtime evaluated or content be fetched by it or whatnot.
Back when this used to be my default policy, I'd whitelist sites that I deemed worthy. I had maybe 1-2 dozen sites (e.g., my bank among them) enabled.
Yes, that's (one of the many reasons) why javascript needs to die.
> Just loading an image when the webpage loads doesn't give you any insight into what the user 'interacted' with.
That's what I said: regardless of whether the browser, when loading a page, does or does not include hidden images in what it fetches, that cannot possibly tell you anything about what the user interacts[0] with after the page has loaded and browser is no longer communicating with your server.
0: edit: obviously excluding clicking links or other navigation-causing interactions, but that's a separate problem.
> Yes, that's (one of the many reasons) why javascript needs to die.
You're missing the point. CSS allows you to load tracking pixels on hover, so you can do that without Javascript.
0: I decline to treat the unintentional flaws of [Firefox] as more important than the intentional ones.[1]
On hover can be easily done with css.
selector:hover{background-image: url();}
That can trigger a tracking pixel.
What methods are there to exert more control over the JS engine in Firefox? Screw performance, I'd have a lot of fun writing my own hooks/wrappers to overload certain method calls.
It is quite usable, and I probably wouldn't use FB without it.
I thought that was cool.
Thing is, nobody ever said ad supported sites have to be viable.
Is it useful? https://en.wikipedia.org/wiki/Banner_blindness
That's true, but if a site is not ad-supported, and "paywall" is almost an epithet (and circumvented to boot), how is any site supposed to remain viable?
Not every desirable activity in life is profitable. If your business plan is "make website -> get money" then perhaps you're in the wrong business.
Advertisers directly or indirectly impacting the kind of news that gets reported doesn't help.
They're not. Think about news sites that rewrite stories from paywalled sites and collect ad revenue. They are parasites that make money from other peoples work. Same thing for all those YouTube channels (though they are not other sites) that repackage other peoples content and make money doing so.
What we need is not so much a way to advertise on the net, but a way to make small payments and subscriptions simple. If sites needed their users to pay them, the quality of the content might go up dramatically. Places like HN could still exist just fine too.
Having said that, I think there are ways to verify ads without cookies and such. It's just that it takes more effort on the server side.
What do you mean by "if"? There are already many sites that require users to pay them (e.g. The New York Times) but everyone simply circumvents their paywalls.
Every method that high-quality sites use to generate the revenue they need to operate is defeated either by ad blockers or someone reproducing their content outside their paywalls. You may be right that news and reporting are not viable, but it is a shame.
[0] Or used to. I haven't checked them in years.
You only buy something because of an ad occasionally. But data is collected each and every time.
It would be an eternal niche, but it might be a nice, cozy little niche.
But when writing JS-free front ends for my web apps, the ugliest UX is trying to fill out a form that requires either filling out n identical sections (eg a fieldset for each student you want to add) or selecting an item from a drop-down w/ the option of adding to it if the desired option doesn’t exist.
Error validation is now clean and easy with modern MVC frameworks that take as input the same structure of data they used to generate the page in the first place, so it is easy to rebuild the page exactly as it was but also include an error message. There is no jarring user experience when the page is submitted and reloaded with the error shown inline. But having to navigate to a separate page to add an entity then refresh the form to fill out the data selecting the newly added entity sucks.
HTML needs some sort of functionality that would enable a) dynamic non-Turing-complete remote resource backing of form input values, b) allowing a form input to return post submission to a dom element rather than a document (E.g. imagine an input to “add location” to a drop down; submitting that field would return the new content of the select option elements to replace the existing). A JS powered example is intercooler JS.
More generally, a content response type that says “patch the existing DOM with the following” would preserve pretty much all the good parts of Web 2.0 without the crap that came with it; keeping in mind that submissions could only happen when a user explicitly requested them.
Installed plugins? Why would javascript need to know my installed plugins? I'd like my browser to more actively restrict what javascript has access to. I get a popup when it wants access to my location (which I generally deny). Why not do the same with these other features?
"This site wants to view your installed plugins. Allow/deny?" "This site wants to set a non-login cookie" Deny, deny, deny.
By not using a graphical, JavaScript-enabled browser, I have been experiencing the web this way for the last 15 years. It works just fine for the purposes I use if for, mainly informational retrieval. For me, there is no such thing as "page load time". This shifts all awareness to "server response time". This is more or less the same from one website to another and therefore differences are not noticeable, unless a server is misconfigured or has some problem.
Provide an example page and I will demonstrate how I would solve the problem.
Not every user visits the same websites and web pages, so without giving specific examples, discussions about how to deal with these pages never go anywhere on HN.
To be honest, out of all the websites I have visited over entire lifetime using the www, the number where I have had to make any extra effort because of Javascript in order to retrieve some text/html, image or video is very small proportion. Not one that is large enough to justify using a JavaScript-enabled browser as default. For me, these are exceptional cases, not the norm.
The extra effort is usually a one-off script, not something I need to save.
Occasionally it is something I save for future use. One example of a saved script would be for non-commercial YouTube channels. Goal was a 2-column CSV of all videos from a channel in the form of title, url. Goal was not "perfection", just quick solution.
yy025 and yy032 are custom utilties for generating HTTP and decoding HTML, respectively.
Using a short script called "ytc" the process would be something like the following. openssl s_client is used as an example of a TLS client. "XYZ" is the name of the channel.
echo https://www.youtube.com/channel/XYZ/videos|ytc|sed wXYZ
Connection=keep-alive yy025 < XYZ|openssl s_client -connect www.youtube.com:443 -servername whatever -ign_eof > 1.html
ytc title < 1.html > XYZ.1
ytc url < 1.html > XYZ.2
paste -d, XYZ.[12] > XYZ.csv
Here is the "ytc" script case $1 in
"")exec 2>/dev/null;
export Connection=close;
yy025|openssl s_client -connect www.youtube.com:443 -servername whatever -ign_eof |sed 's/%25/%/g'|yy032 > 1.tmp;
while true;do
x=$(sed 's/%25/%/g;s/\\//g' 1.tmp|yy032|grep -o "[^\"]*browse_ajax[^\"\\]*" |sed 's/u0026amp;/\&/g;s/&direct_render=1//;s,^,https://www.youtube.com,')
echo > 1.tmp;
test ${#x} -gt 100||break;
echo "$x";
echo "$x"|yy025|openssl s_client -connect www.youtube.com:443 -ign_eof > 1.tmp;
done;rm 1.tmp
;;-h|-?|-help|--help)echo usage: echo https://www.youtube.com/user/XYZ/videos \|$0;echo "usage: $0 {title|url} < html-file"
;;1|title) sed 's/\\//g;s/u0026amp;//g;s/u0026quot;//g;s/u0026#39;//g'|grep -o "ltr\" title=\"[^\"]*"|sed 's/ltr..title=.//'
;;2|url) sed 's/\\//g;s/u0026amp;//g;s/u0026quot;//g'|grep -o "[^\"]*watch?v=[^\"]*" |sed 's,^,https://www.youtube.com,'|uniq
esacHow do the GDPR popups work if you don't have JavaScript enabled? Are the sites still GDPR compliant if they track you using cookies because you disabled the JS which should have disabled the cookies?
The zapper's fairly easy to use to get rid of annoyances on mobile, until you make a mistake. Editing the rules file isn't the nicest UX even on desktop FF. (It'd be good, for example, to be able to preview what's being blocked, and selectively re-allow them.)
For an example of how it can go wrong: you block 'overlay', then it reveals and you block 'grey-blur-modal-focus', allowing you to click whatever you wanted, except it turns out that it uses 'overlay' and you shouldn't have blocked that one.