Unobtrusive JavaScript: Now it has come to this!

The question is whether or not it can afford to, given its unreliablility.

Isn’t that what they actually do? I’m not sure, but there is a low bandwidth, plain HTML option in Gmail. (Ah, as John point out in #19.)

On one of my fairly modern Macs, JS would hardly load at all, for some reason. I never figured out why, and had to just get a new computer. On that computer, JS had trouble loading on any site, in any browser. Even after wiping the hard disc and reinstalling everything, JS kept failing. It’s one of the things that made me inherently distrustful of the reliablility of JS. There’s just too much that can go wrong for it to be worth relying on solely.

2 Likes

Are you equally as worried about macs?

I don’t follow.

I think the proliferation of client side scripting to the server says much differently. Though I won’t argue that JavaScript is a :poop: language.

Yeah, I’m referring to front-end JS. Too much can go wrong with it—that is, getting it to the end user intact—to rely on it.

1 Like

Yes you’re right, I managed to find a link buried in the docs, but it’s clear they don’t want people to find it or use it.

Do you really want to use HTML Gmail?

You’re about to use a version of Gmail designed for slower connections and legacy browsers. To get all of Gmail’s features, including inbox categories, images, and quick actions, please use the latest version of Gmail (recommended).

Take me to latest Gmail I’d like to use HTML Gmail

1 Like

And people who rely on keyboard navigation must be used to many sites being inaccessible or near inaccessible, but that’s never seemed to me like a good reason to add my sites to the number.

Yes, I agree with you there. I was trying to make that point, but may not have been very clear about it.

1 Like

Maybe I’m missing something, but I always thought that the JS was part of the browser. Or are you talking about JS frameworks, libraries or preprocessors?

It is in those browsers that support it. Most do provide an option to turn it on and off at a site level. Also not all browsers implement the same version of JavaScript so some support commands that others don’t recognise.

Indeed, JS is run in the browser (except of course where it’s handled by the server, via things like Node.js). However—apart from the varying support for JS in different browsers (a minor issue these days, really)—the JS can only run in the browser if it gets properly downloaded to the browser. That’s the sticking point.

For various reasons, JS doesn’t always (down)load properly, so you can’t be sure that it will be available in the user’s browser. In the last few days, JS hasn’t been loading properly on the SitePoint article pages, meaning that the code highlighting script doesn’t kick in and other JS features don’t appear. It’s not clear why that’s happening (but it could be related to the switch to https). Anyhow, it’s fortunate in this case that the code can still be read just fine even without that enhancement. That’s important: the JS is an enhancement, but not a requirement.

3 Likes

[quote=“ralphm, post:30, topic:224661, full:true”]
However—apart from the varying support for JS in different browsers (a minor issue these days, really)—[/quote]

It’s more than a minor issue when it comes to ES6 and beyond.

Support for many features is vary flaky. When providing a reliable experience is important, you may be tempted to transpile from ES6 down to more widely supported ES5 code. I came across this with developers just yesterday. They were using only a subset of ES6 code that was capable of being transpiled down, and even worse, they weren’t actually ending up using ES6, due to it being transpiled down to ES5 code. It become an emporer’s new clothes situation, for what you think of as ES6 really ends up being nothing more than ES5 instead.

Perhaps a bit too much ES5/ES6 stuff there, but browser support when it comes to ES6 is more of a problem now than we’ve had to deal with over the past five years.

1 Like

Heh, I knew someone would challenge that. But as with advanced CSS, we accept that some new things take a while to get cross-browser support. To me, that’s different from waiting for browsers to actually support JS at all (which IE arguably didn’t until very recently).

If you write your JavaScript appropriately you can have it run in browsers that support all the commands and have it not run at all (and present the “noscript” version of the page) in browsers that only support earlier JavaScript versions - that’s the flexibility of JavaScript over the antiquated <noscript> tag that became obsolete when the JavaScript DOM was introduced.

Apps I write, require JS because I use a lot of AJAX. I find that often the reason JS does not seem to load properly, is not an inherent JS loading problem (like internet connection), but a programmer problem. When JS encounters an error, all JS stops working, making it appear like it did not load.

If I find a page from someone else and JS does not work, the browser developer tools 9 times out of 10 that there is a JS error that the programmer has not tested properly.

The other case would be that an AJAX call returns something that JS is not designed to handle.

3 Likes

felgall you really don’t get irony do you,

" leaving certain browser settings alone so that their prehistoric JavaScript will work"

Has our whole office LOLing.

Sort of hard to do that if we still have no idea what settings he is referring to. I’ve yet to see a post that identifies the “settings” that render gmail useless.

I’m personally interested, as the developer in me is wondering, “what settings could render JavaScript useless?” That is of great interest to me.

1 Like

Try setting your browser useragent to identify YOU rather than some theoretical combination of half a dozen antiquated browsers and the browser sensing that gmail does (that was obsolete in Netscape2) breaks their script. Their crapscript coders really ought to learn basic JavaScript and how to use feature sensing properly - then they will not need to spend all that time constantly updating the useragent tests as new browsers are introduced (not that their test recognises 99% of browsers properly in the first place unless they fake the useragent).

Fortunately in the case of Gmail the pages work better without the JavaScript anyway.

Not wishing to seem completely dumb here, but how do you go about setting the browser useragent like that? I can’t be the only one wondering where they are.

2 Likes

I think the better question is why would you alter it to identify you? Most days people are looking for anonymity, not a method for every website to be able to know who you are without the need to sign up for an account.

2 Likes

Not you personally, but your particular browser without the other ones that are in the user agent string.

Here is one for Chrome

Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2228.0 Safari/537.36

Instead of those seven identifiers, what he means is that you should try things when you are identified only as:

Chrome/41.0.2228.0
1 Like

I actually meant so as to distinguish between the owner of the site and visitors in the statistics for a web site.

If I have all my browser useragents set to ‘xxx3456 test’ then I can identify those in the web site stats and know not to include them in the visitor count.

I don’t believe that doing this actually provides a way to identify you - particularly if you change the value every so often. It only provides a way to identify that the same person has visited the site multiple times and not who that person is. In any case whose to say that useragent isn’t the default value for one of the thousands of different browsers that exist and that there are not multiple people using that browser and hence presenting that useragent.

Even if you disagree about identifying yourself personally via the useragent field the fact still is that the field is entirely under the browser owner’s control and the value can’t be relied on to identify a given browser.

It is impossible for a browser created tomorrow to have its useragent included in a broken browser detector script in use todayas there is no way of knowing what useragent that new browser will use.

The reason why most browsers identify themselves in the useragent as being all of the major browsers currently in existence is because of these crapscripts that insist on trying to detect whether a browser supports a given command by testing for what browser it is rather than using the feature sensing method introduced to JavaScript in Netscape 2 that allows to to directly test if a command is supported.

With the exception of capturing browser statistics (where you know the results will not be completely accurate) scripts should never test the useragent value as a part of their processing - any script that does is using a technique that was obsolete in Netscape 2 when feature sensing was introduced.

Chrome: http://www.technipages.com/google-chrome-change-user-agent-string
Firefox: https://techjourney.net/changing-user-agent-for-firefox-web-browser/
Edge: http://www.thewindowsclub.com/change-user-agent-in-microsoft-edge
Safari: http://www.howtogeek.com/211961/how-to-change-safaris-user-agent-in-os-x/
Internet Explorer: http://www.pctools.com/guides/registry/detail/799/

4 Likes

[quote=“felgall, post:41, topic:224661, full:true”]
With the exception of capturing browser statistics (where you know the results will not be completely accurate) scripts should never test the useragent value as a part of their processing - any script that does is using a technique that was obsolete in Netscape 2 when feature sensing was introduced.[/quote]

Yes indeed, feature detection is a much more reliable way of providing support for different browsers.
.
Perhaps more controversial than that, is to do no detection and allow less capable browsers to fail.

2 Likes