Is this a good/respected approach?
Is this a good/respected approach?
EDIT: a different question is: If you should provide some minimal functionality of your web site when your visitors don't have JS enabled - that's mostly a good idea, for the reasons some of the commenters have pointed out.
The benefits are things like:
Of course, AJAX is pretty cool, and so are dynamic pages, so don't throw those things away just because some people don't need them.
It's a good idea to avoid unnecessary functionality, period. Frameworks like jQuery make it incredibly easy to add frills that may make sense to add, but sometimes don't. For instance:
Do you really need to animate that?
... or ...
Is traversing the entire DOM really needed for such a trivial selector? Could you limit it using context, and do we need that in the first place?
I would not avoid using JS, but I do take care to not be obnoxious, while looking out for slower machines. The same holds true with some of the fancy new stuff we get in CSS3 - like drop shadows … if used excessively they can make someone on a lower powered machine have a really bad experience.
The exception to this might be writing front end controls for various kinds of appliances, where they must absolutely work with JS disabled (perhaps a strict security policy on a data center management network dictates no JS). So the above should be taken in context with whatever requirements you have.
This same question has been asked on SO, but I cannot for the love of me remember where.
JS has a huge bunch of features, which can't be replaced by server-side code. Other than those above, I don't think there would be any reasonable argument to limit JS usage.
Minimum accesss requirements are OK if you're really building an application - you target some specific platform to gain advanced features that couldn't be built otherwise. It's just like developing for Python or Java or .Net. Don't let buzzwords like HTML5 and the promise of "run anywhere" fool you; you can have portable code between devices only as long as the whole platform is supported on those. Any change to the development stack, and the software will break.
Thus the price to pay is that you're following a moving target, as new versions of the platform are released; you'll have to play catch-up to keep your app working as the platform evolves. The only benefit you get is a semi-universal delivery mechanism for your app that doesn't depend on packages nor application stores; but you lose the main feature that differentiates the web from previous networked computer systems.
Content-centric websites are a different beast; they are in the tradition of the classic World Wide Web. Content is loosely interpreted by the client, which can made any desired transformation before presentation. The site is expected to be accessed by an ecosystem of different platforms that may or may not support the current standards:
The benefit to this approach is less testing and upgrading required, and more shelf-life. The first static webpages from 20 years ago are still browsable in any web client, but the first web applications are forever broken. If your site has any archiving value at all, you'll benefit in the long run from using the web as a content delivery system, not an application platform.
Old-fashioned approach is totally outdated. For example I've made an ajax-deletion for moderator on one of the sites and he is just happy because of the obvious speed increase.
Of course developer can do two versions both for JS and non-JS users, but in most of the cases it's extremelly expensive and doesn't worth 1-2% of the website audience (if you are not Google, of course).
Many corporate networks responded by disabling JS, a policy that (rightly or wrongly) still exists in many organisations today.
Quite simply, I suggest that no site should rely on JS to operate
As most of the answers here explain, using
coffee-script which will save a lot of effort typing