mwhitney Wrote:This is only the case for sites developed by people that believe this. There has been a long tradition on the web of progressive enhancement, and an equally long tradition of people ignoring (or disputing) the benefits of progressive enhancement. None of the significant advancements in the "modern" web have done anything to change this.
All of the recent advancements in web technology are based off JavaScript. Node, Ember, Angular, noSQL, PouchDB, asm.js, the list goes on and on.
mwhitney Wrote:Situation A isn't really the case, except in very extreme situations (in which case you should probably look at other areas for optimization). In my case, a static page usually spends more than half of its time in code which is executed on every request, and 1/6 to 1/4 of the remaining time will be spent in template code or other code related to returning a page (which isn't executed for an AJAX response). So, an AJAX response doesn't take as long as a full page, but it's rarely faster to add an AJAX call to a response than to simply make the database call as part of the original response.
In other words, if it takes 0.5s to generate the page and 0.5s to generate the search results, it might take 0.75s - 0.8s to generate the page with the search results included, but it shouldn't take 1s. Plus, the time for the AJAX response would really be 0.5s + 0.1-0.5s transfer time + 0.5s + 0.1-0.5s transfer time + ~0.1s+ to modify the DOM and re-paint the page vs. 0.75-0.8s + 0.1-0.5s transfer time + ~0.1s+ to paint the page. In other words, the time you save the user in displaying the initial page (without the data) decreases (as a percentage of the total time they spend loading your page) as their connection quality and/or bandwidth to your server decreases.
You're completely ignoring what I said about the psychology of wait times and visual loading. It doesn't matter if it does take longer it appears to load faster. In this case it does not take longer. If you use DOM fragments you only trigger a single repaint. Templating is just as fast client side as server side and puts less strain on your server allowing you to handle more concurrent users.
You should be using more JS not less. If you want to ignore the tools in front of you and continue building things the way we did 10 years ago that's your prerogative but I would not recommend this method to anyone.
mwhitney Wrote:Twitter appears to let you do nearly everything except send a Tweet when JavaScript is disabled. If not for this limitation, it probably would be preferable to use Twitter's site without JavaScript, as they add a lot of clutter to the page via AJAX.
So it's completely useless which is exactly my point.
mwhitney Wrote:If your users are never really going to visit your website anyway, then go ahead and force them to use JavaScript, Flash, and whatever else you feel is necessary for a "modern" website. Just make sure you've designed your API well enough and have a compelling enough application that you won't be outdone by someone with a more accessible interface.
Can you provide an example of why a user would disable JS? Why are you wasting effort supporting these idiots (which are less than 1% of all users) at the expense of providing all your other visitors with a subpar experience?
