I have a dashboard type of page that contains a bunch of sections, each providing different data. Getting all the data and then sending the page is slow. From a perceived performance standpoint, I'm thinking the best way to do this is to load the page with each of these sections containing nothing, then use jquery ajax to asynchronously get the various pieces of data. However, it has been drilled into my head that I should not depend on javascript to be enabled. Is there any way to detect if javascript is enabled in the requesting browser before sending back the page? Or, maybe a better question is what is the best way to go about this?
A:
If your dashboard is part of a backend system, then I would make JavaScript a requirement and use AJAX to update the page. The visual responsiveness will be greatly enhanced, and as the backend of a site (or app) it has a more limited and controllable audience.
Be sure to have some sort of warning that appears if JS is disabled.
Even on front end sites its debatable, but many programmers still opt to plan for no JS support which would a little hard to implement in this scenario.
Doug Neiner
2010-02-03 18:08:36
A:
What I think you want to do is build your page using unobtrusive javascript.
What this will let you do is build a perfectly functional page for non-javascript enabled browsers, which can be enhanced for (the vast majority) who have javascript.
To stop a single request being a heavy payload for non-javascript browsers, make the user have to click a link to get each piece of data.
DanSingerman
2010-02-03 18:09:05
Having the user click a link to get the data is a good idea. I'll just replace the link with the data in javascript. Thanks!
Grant
2010-02-03 19:19:53
A:
You should probably do this in two steps:
Code your page as if javascript never existed. Use semantic markup and a good css structure (that will be easier to tamper with once you do start playing around), but don't use any javascript whatsovever.
When everything works, start adding javascript beautifications. Animations, asynchronous calls (that might require further implementation on the server side) and other stuff, but nothing that you need to change the html from step 1 for. If you need the html to be different, change it with javascript - that way you won't have destroyed anything in your fallback app.
Tomas Lycken
2010-02-03 18:09:53
I know you are saying this because it is the "right" answer, but would you actually follow this advice if this were a backend system (CMS, etc)? For the tiny % of people with JS disabled, is it worth the effort?
Doug Neiner
2010-02-03 18:12:00
@Doug, I try to follow this whenever I write a web app, regardless of its nature, unless I can agree with the user/whoever ordered it (which may be me) that it's OK to demand that the client supports javascript. But generally I do try to follow this, also when coding back-end systems that won't be used by a large user base.
Tomas Lycken
2010-02-03 21:58:53
+2
A:
Probably 99% of users have JavaScript enabled now. Unless you care a whole lot about the people running browsers that are 10 years old, or about the absurdly paranoid users, I would just use JavaScript. Your case is what AJAX was designed for.
Mike
2010-02-03 18:12:28