Best way to set up AJAX/JQuery process?

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.

Node allows you to run JavaScript on the server (which you can also do in classic ASP and ASP.Net on Windows servers, welcome to the 1990s). NoSQL is certainly not restricted to JavaScript. What about the recent advancements in PHP, Python, and almost every technology used on the server? Server virtualization, Docker, Go, and LESS (yes, you can compile LESS on the client via JavaScript, but that would be slow)?

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're right, I am ignoring it, because the difference in times between a single request and a dual request can be less than the transfer time from the server to the user, and, as I said before, if my server's response times were coming anywhere near 0.5s I would be looking into other optimizations, anyway. Additionally, psychology is a science of statistics and research methods, neither of which were presented in your statement.

In this instance, we're talking about different things in terms of templating, unless you're discussing a single-page app. I certainly wouldn't want to spend all of this time arguing about code reuse only to find that you're advocating duplicating the structure of your HTML document on every single page of your website.

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.

I did not intend to imply that JS should not be used, I simply said that the site should still function without it and should not require it. Going back to my first paragraph, this is the central idea behind progressive enhancement ( http://www.w3.org/wiki/Graceful_degradat...nhancement ). In rejecting the way we did things 10 years ago, you're simply slipping back to the way things were done 20 years ago.

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.

It's completely useless for posting a Tweet, but still works for reading your Twitter feed. Here's my point: how many people log in to Twitter's website to post a Tweet?

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?

1) Making the site work without JS does not mean you are providing a reduced experience for users with JS. That's why it's called progressive enhancement. You make the site work, then you make it look good (via CSS), then you add extra features (usually via JS).

2) I have to comply with the guidelines provided by Section 508 ( http://www.section508.gov/section-508-st...-guide#Web ) and WCAG 2.0 ( http://www.w3.org/TR/WCAG20/ ). In some cases JavaScript can interfere with assistive technologies so users will disable it (or the software will disable it). In most cases it is easier to design a page with these requirements in mind and using progressive enhancement (and/AKA adaptive web design) than to utilize the options available for non-conforming sites (often the option comes down to producing and making available a plain text version of the content).

Finally, the "Graceful degradation versus progressive enhancement" article ( http://www.w3.org/wiki/Graceful_degradat...nhancement ) as well as more recent articles (for instance, the articles which coined the terms "responsive web design" and "adaptive web design") do a much better job of outlining the other significant reasons for making the site work without JavaScript first.

Bonfire

Practical CodeIgniter 3
CodeIgniter Testing Guide