can confirm this, it works if your change your WP/Lumia browser setting's website preference to desktop version. Though it's still apparently fetching/rendering the wrong sprite size.
I am glad this still exists, it's helped me out a lot while living and working in Africa for the past month. Sometimes I don't have access to a fast connection. That being said, a lot of other Google products are awful across slow links, for no particularly good reason. Google+ doesn't work at all. Even clicking the little bell in the top right of another Google page never loads. I get the feeling Google needs to do more testing of their products over low speed and high latency links.
Very true. I can't understand how bad some of their stuff is over non-super fast links (probably super low latency is my guess). It isn't just very slow links, I have problems with their stuff frequently when no other sites I use have issues (and if the connection is bad enough to cause others problems, Googles site will almost surely not even load - other than search which does load).
I get the feeling they don't bother testing on anything but super low latency, of if they do they don't care about a horrible user experience.
For me the super bad user experiences in this area have been greatly less, for me. Maybe they actually did something to address the problems (they are still far worse than any other sites I used, but still much better than they were for the last couple years).
Just a suggestion: using 'super' as an adjective four times is a bit distracting. But maybe I am the only one who is annoyed be the recent trend of Jobs-ification of noun phrases ;).
I travel to rural areas in the South Indian state of Andhra Pradesh every month. The connection quality is as poor as its availability is flaky. I find that GMail, Google Drive and the Google search page always load. Business correspondence and collaborative editing have not been problems at all. I have not tried Google+, though. I shall try it the next time.
On the other hand, my biggest problems have been with GitHub. Not once in the last 18 months have the GitHub Web pages loaded. That makes reviewing and merging pull requests very painful. I reported this to GitHub long ago, but have not seen any improvement yet.
Weird. I am in Malawi right and have basically the opposite experience. Google is dog slow, but I can get GitHub just about anywhere. Probably has something to do with where the packets are routed.
Having redundancy in a web app like Gmail is just good practice in my opinion. Any Javascript reliant application should still work without Javascript, I haven't tested it, but I seriously doubt something like Asana would work with Javascript disabled nor really any other JS heavy application.
Some people often forget that not everybody has access to a fast Internet connection, as pointed out Africa is one of those nations, but even here in Australia there are people out in regional areas still on dial-up because satellite is too expensive and DSL is not an option because of the distances. Then you have countries like Libya, Iran and even parts of India too.
I do wonder if Gmail didn't build a HTML version out of necessity, if Gmail were built in 2014 or even back in 2009, would it have had a fully functional HTML version to boot or would it have been only partially functional?
Javascript shouldn't be a problem for slower internet connections, it can be even useful by loading only the necessary parts of the site when users navigate.
One problem is that lot of sites are using multiple libraries and widgets.
Other problem is with web applications that show a loading screen (Gmail too) before showing the interface. The first load of most web applications should be static HTML, and JS should be run only after the first state of the interface is rendered. The worse is when the page loads the HTML and then the JS and then JS makes other request(s) to load more content for the first page.
I think it would be safe to say that the vast majority of Africa is connectivity/bandwidth starved.
Even in a (very) affluent South African neighbourhood, I struggled to get one of our remote workers a connection faster than 512kbps. And even that cost significantly more than our local (UK) connections which are comparatively overpriced.
(This was about 18 months ago, the landscape could have obviously changed).
Many of my African contacts rely on low-bandwidth comms such as GPRS or SMS. I guess that's why mobile banking (often via SIM Application Toolkit) is so popular. Same goes for WhatsApp.
I never said anything about Flash. JavaScript 0-days for Firefox or Chrome are very rare, and you'll never see them if you keep your browser updated. Disabling JavaScript is how stupid people make the lives of web devs more difficult.
Have you actually looked at, say, the lists of security vulnerabilities fixed in each version of Firefox? Many (if not most) of them say Thunderbird is not vulnerable because scripting is disabled. There's a hint for you.
Have you actually looked at real or proof of concept exploits targetting Firefox or Chrome? How did you miss all the Javascript in them? Even if the underlying vulnerabilities are not in the implementation of Javascript itsfelf, having the scripts makes it so much easier to actually interact with all that attack surface, do tricks against things like aslr, load shellcode everywhere, etc.
Some real bugs are just nightmarishly hard to exploit if you can't have a script hammer on it.
Did you forget Panopticlick? Did you forget all the various ways scripts can snoop around and track you?
Making hard dependencies on javascript and including 4MB of jquery junk just to make an animated effect that wastes your CPU time is how stupid people make the lives of anyone who isn't running the bleeding edge at default settings on a fast low latency connection more difficult.
If something lets people mine bitcoin on your computer without your consent, it's a risk. That means javascript.
I agree with Paul. A website that does not function without JS is a poor design choice. I have JS disabled by default and only whitelist specific domains.
If your website content doesn't load up, there's a good chance I'm not sticking around unless it's imperative.
Good engineers don't make judgements like this in a vacuum. Design choices are about tradeoffs and are not inherently good or bad. For a system like gmail where you have tens (hundreds?) of millions of daily active users, coming from countless different types of clients, a mode that eliminates JS dependency seems critical.
Most sites are not gmail, they're not even close. Decoupling JS, particularly if it's done just to ensure the tiny fraction of people who disable it can use the site, can rightfully be very low on the priority list if it is a non-trivial engineering cost.
While there is sense in what you are saying you don't have to create the problem for yourself. Don't create situations where you rely on javascript in the first place.
Granted there are some cases where it is an acceptable decision to get yourself into the problem (because the advantages you gain by doing so are worth the costs). But often companies just create the problem for themselves for no good reason - they could have avoided becoming dependent on javascript to do stuff they didn't need to do in a way that broke (degraded un-gracefully) if javascript wasn't available.
I said that if the functionality of a website is broken without JS there were poor design choices made; not that a web developer should focus on people who disable JS.
You can't seriously be implying it takes more time to write functional HTML than JS. One requires the other to work, when you flip it around it's bad design.
By that standard GMail is a bad design. They have a completely different UI for users who do not have JS. This is almost surely an enormous amount of work to build and maintain. To me this tradeoff usually only makes sense when a sizable % of your users are going to use that alternative.
But it's not just HTML and CSS - you need to create a completely new user journey because you can't make asynchronous requests to the server. In some instances you may even need to manage server requests completely differently. UI elements may have to be changed as well as you can no longer rely on Javascript to animate them.
You're essentially maintaining a second UI that is divorced from your main UI. There's significant cost in that. It's the same reason most sites don't support IE6 anymore.
Another long-time default-JS-off user here. The majority of exploits rely on JS to work, and by turning it off I've eliminated a huge attack area. I got hit with drive-by malware a long time ago, turned off JS not long after that, and have been malware-free ever since; and I visit some of the more shady parts of the Internet often.
A lot of others keep telling me "but you're missing out on tons of cool stuff", to which I reply "most of what JS is used for, I do not find 'cool'."
Points 2 and 4 are doable with CSS. The rest is possible to approximate with some combination of forms, iframes and continuation-based backend. No "onkeyup" of course, but enter key can work nicely.
Actually, I agree with both sides of a debate here: progressive enhancement is a really great idea and moreover it's completely insane to require JS and lots of potentially buggy and maybe even harmful JS libraries just to see what the page is about. On the other hand, non-JS and JS-based designs and implementations are just too different to be developed together - I know, I tried, multiple times - and what you really get is a blatant violation of DRY principle and twice as high cost.
In short, until we have a set of non-JS components (HTML5 new input types are an example), which are common and make it possible to translate JS-based design to non-JS one without whole page redesign, we're going to see people over-relying on JS and not providing alternatives. Which sucks.
Whether or not something is possible with CSS instead of JS is completely irrelevant to the argument that by turning off JS you are missing out on useful functionality implemented in JS, like the aforementioned GMail features.
Frankly, the concern for users who turn off JS on purpose would be pretty much bottom of my list of considerations unless I'd be making something for a very specific niche demographic.
Disabling Javascript is a security precaution, it makes plenty of sense and will continue to make sense long into the future. You might as well say that the concern of users who run a firewall is at the bottom of your priority list.
That's great and all, but like they said, unless you're running a niche website with super tech-savvy users (this site, for example) you're not going to have to worry about the JS-disabled folks. When the % of users with JS disabled viewing your site is super low, it's not really a concern to cater to them.
Nothing on that checklist precludes javascript-only applications. In fact, the checklist specifically points out that "noscript" content does not constitute a suitable alternative to inaccessible scripting - the solution is to ensure the scripted solution is accessible (e.g. no mouse-only functionality for example).
I don't think this is really a logical stance to take anymore than saying "an application that doesn't function without Java/C++/etc. is a poor design choice. If your application doesn't load up without needing an embedded runtime environment, I'm not bothering with it."
Lots of pages, news-sites in particular, use JS to load more bloat, animated slide-decks and lots of things causing slower loads, including "beacons", and lots of fancy/noisy UI-elements distracting from what you actually came for: the nice, static HTML content that was the news.
You will be shocked to see most pages on the internet load almost instantly the second you disable JS instead of spending several seconds loading all sorts of non-content.
I think it is because performance. Visit techcrunch (23) or huffingtonpost(30+) for example with an extension like ghostery which shows how many external js lib gets loaded. I don't block js but I block flash and it is for the same reason.
My record is around 40+.
I don't know why do they need that many. See reddit, loads 2 I think.
I feel the web runs a lot smoother for me without JS. I don't get pop-ups, bulky advertisements, or other resource hogs that detract from content. I also don't like that Google or Facebook are tracking my movement across websites.
I am not OP but my reasons are security, ad/tracking breaking and general peace of mind. With the latter I mean for example popups, unnecessary animations, you might also like, CPU overload and other modern webdesign features.
speed improvements, privacy and the sense that the web should work without javascript, damnit. that said, js enabled+ghostery works well enough in Opera for me that I've started browsing with it on by default again.
CSS is not a Turing-complete language on which the bulk of security vulnerabilities relies. The majority of CSS used on webpages is truly beneficial to the user.
(That said, I will turn off CSS on a page that abuses it; the majority of them don't, it's not a security risk, and it makes the page look better most of the time, so no problems with having it on by default.)
stupid question - what do you consider an abuse of CSS?
Do people abuse javascript? Absolutely! However, I think JS can make the page look much better. Ajax loads are quicker than page refreshes, autocomplete is very useful, reply boxes that are loaded inline on demand, Hiding of parts of the page if the user wants to, (long comment threads...) table headers that scroll with the table, etc, etc. The really crummy thing about JS is it has gotten so much negative attention because of the abuses and that's what people focus on.
I really don't like the move to JS dialogs myself though. I don't think that they are beneficial to the user in many cases. Especially when a video or picture is displayed in a JS dialog.
> it's Turing-complete so long as you consider an appropriate accompanying HTML file and user interactions
In other words, CSS won't just sit there and consume CPU cycles unless you actively interact with the page, unlike JS. The highest-voted comment on the first answer there says that a bit more explicitly.
Oh yes, I'm well aware of this version of Gmail. I left the military in October of last year and this is the version of Gmail I was forced to use on our piece of shit government computers running IE6 or whatever they had.
yeah, how about all those fancy startups that never even think about building a html only version ? At least give google some credit for actually providing this alternative for a decade.
Not just HTML only, how about "not an app" version? It is really annoying that things which could be accomplished perfectly well in a browser are now apps because apparently the web is terribly unfashionable these days.
When Gmail first came out, I remember having to use Firefox or IE6, both of which were much slower on my 100MHz desktop than Opera was. The basic HTML version was super nice.
The 0 refers to which Google Apps/Gmail user session you want to open. For example, 0 gives me my personal Google account, 1 gives me my work account.
I guess h stands for html.
I find this interface to be slower/all-round worse than the JavaScript one. Maybe it's because I don't live in the US and notice the 500-700ms+ page render times more when the whole page reloads.
https://mail.google.com/mail/?ui=mobile
I'm glad I can force my mobile Browser to use the HTML version instead, which lists all tags at once.
https://mail.google.com/mail/?ui=html
Also you can force[1] your browser to display the normal version no matter what:
http://mail.google.com/mail?nocheckbrowser
Force non-feature complete touch-enabled iPhone view[2]:
http://mail.google.com/mail/x/gdlakb-/gp/
[Edit] current iPhone view
https://mail.google.com/mail/mu/mp/
[1] https://support.google.com/mail/answer/15049?hl=en
[2] http://googlesystem.blogspot.com/2008/10/gmail-modes.html