But what if a website (or more likely we should call it a webapp in this
case) heavily relies on js and doesn't work without it anyway? Some random
parts might work but that still doesn't count. In such cases spending time
on implementing and testing the non-js version is irrelevant, IMHO.
Assuming the usual distinction, we have
webapp - provides Javascript-dependent functionality and
client-generated content, with no static or server-
generated content
website - provides static or server-generated content with
Javascript-dependent client-side enhancements
or something in between.
The former should use graceful degradation to provide less
and less functionality as less and less features are available.
At minimum, it should provide text info about the app, its
features, and its dependency on Javascript (no empty pages,
not just an error message).
The latter should use progressive enhancement where the
core content is available without bells and whistles, but the
user experience is improved and additional content may be
provided as more features are available.
I'm not suggesting that every webapp has a website as a
fallback, although if you do not start with a website and
enhance it towards a webapp, that should be a conscious
decision, not an accident. There should be good reasons
why you don't provide (part of) the functionality server-side.
I am suggesting that visiting a webapp or website on the
web with JS disabled and not seeing any hint of what is
supposed to go on is just sad (and reminiscent of the days
of flash-based "sites", and potentially problematic wrt to
accessibility). If you care about this issue, you are already
ahead of your competition.
I am also suggesting that many sites could provide fallback
content (minus interactions) with little or no effort (eg, twitter
is a webapp, but mobile twitter works as a website, too; if
you think about what happens when you follow a link to
a tweet on twitter, with or without JS enabled, you will start
to wonder whether twitter's tweet links are good design;
Google+ actively hides its core content for no good reason).
Some web developers may have limited resources: if one hosts
a webapp as a guest page on someone else's server, one does
not have a dedicated server on which to execute server-side
fallback operations.
At the other end of the spectrum, developers at sites like Yahoo!
not only have servers to work with, they also invest in developing
the technology that will allow them to run the same JS code on
the server, if it isn't enabled on the client side, or if the client is
a device that shouldn't be burdened with such computations:
http://effectivesoftwaredesign.com/2011/11/16/yahoo-cocktails-when-the-client-is-in-the-cloud/
Other examples include Opera Mini, with mixed server and
client side rendering:
http://dev.opera.com/articles/view/opera-binary-markup-language/
I'm just hoping to reach those developers who still care, and
who may simply not know about their options. Whenever I
see a site/app by one of those other developers, those who
don't know or don't care about such issues, I tend to wonder
what else they do not know or care about.
Since this is a security and privacy issue (I disable JS by default
both to reduce the attack surface, where JS is used to leverage
obscure bugs into workable attacks, and to avoid wide-spread
user monitoring), and their sites/apps don't work out of the
box, I tend to stay away. Such users who stay away don't
show up in server stats (and certainly not in JS-based stats).
Happy Holidays,
Claus
--
To view archived discussions from the original JSMentors Mailman list:
http://www.mail-archive.com/[email protected]/
To search via a non-Google archive, visit here:
http://www.mail-archive.com/[email protected]/
To unsubscribe from this group, send email to
[email protected]
