Develop Reference

Another "how to change the URL without leaving the webpage"

I am creating a website which uses jquery scrolling as the method of navigation that never leaves a single html page.
I have noticed that some websites are able to change the URL and have looked at posts/answers (such as How does GitHub change the URL without reloading a page? and Attaching hashtag to URL with javascript) which refer to these changes being either push states, AJAX scripts or history API's (all of which I am not too savvy in).
Currently I am looking into which method is best for my website and have been looking at some examples which I like.
My question is why do the websites below use /#/ in the path for the changing URL. The only reason I ask is because I am seeing this more and more often with jquery heavy websites.
http://na.square-enix.com/ffxiii-2/
http://www.airwalk.com
If anyone could simply shed some light on what these guys are using to do this, it would be much appreciated so I can possibly create my own script.

My question is why do the websites below use /#/ in the path for the changing URL
If we discount the possibility of ignorance to the alternatives then: Because they are willing to accept the horrible drawbacks in exchange for making it work in Internet Explorer (which doesn't support the history API).
Github take the sensible approach of using the history API if it is available and falling back to the server if it isn't, rather then generating links that will break without JavaScript.

http://probablyinteractive.com/url-hunter
This has a nice example on how to change the url with javascript.

I've not tried it myself, but read many reviews/opinions about History.js
It's supposed to have the "# in the path" option as you said (for older -- incompatible -- browsers) and the facebook-like direct changing of URL. Plus, when you hit the back button, you will get to the previous AJAX-loaded page with no problem.
I've implemented such a feature (AJAX tabs with URL changing), but if you will have other javascript on the pages that you want to load dynamically, I wouldn't recommend you using AJAX-loaded pages, because when you load content with AJAX, the JavaScript inside the content won't be executed.
So I vote for either HistoryJS or making your own module.

Well, they're using the anchor "#" because they need to differentiate between multipla bookmarkable/browser navigatable places in the site, while still having everything on the same page. By adding browser history events of the genre /mySamePage.html#page1, /mySamePage.html#page2 when the user does something that Ajax loads some content in the current html page you have the advantage of (well, obviouslly) still staying on the current page, but at the same time the user can bookmark that specific content, and pressiing back/forward on his browser will differentiate between different Ajax loaded content.
It's not bad as a trick, only issue is with SEO optimisation. Google has a nice page explaining this http://googlewebmastercentral.blogspot.com/2009/10/proposal-for-making-ajax-crawlable.html

Is there a problem with using all AJAX for server calls in a public site?

Understanding that if someone had JavaScript disabled the site would not work then is there any other reason not to do this?
I am in the design phase of a new site and want to make it easy to change the server code without having to change the UI - just like a form.
This is using Python server side.

One problem, arguably, is that Ajax techniques break the back button.
By making all of your calls to the server Ajax calls, the user loses their ability to 'go back' to a previous view. Facebook exemplifies this. Click the back button on Facebook, generally, does not take you to the previous view you were presented with.
In addition, it is more difficult for a user to bookmark their current view of the site. This can make it difficult for them to share what they are seeing with others and can make it difficult to debug problems that users see; rather than just sending you a URL to recreate their problem, they have to figure out the numerous steps they took before they spotted a problem.
Personally, I think the best place for Ajax is for updating small segments of a page. If you have a page that is changing more than, say, 50%, you may want to rethink the sole use of Ajax

Potentially yes, here are two items that come to mind.
Search indexing: this would have profound impact on what content on your site search engines like Google can index. Because the crawlers do not execute any AJAX script when reading your page.
Performance: Too many AJAX calls can actually hinder performance and page load response times. AJAX should generally be used to update only specific parts of a given page if at all possible. If you can emit the majority of content in the first page get request you should, period.

For a desktop-like rich web application, I would say that the all AJAX approach is acceptable.
However unobtrusive JavaScript and progressive enhancement may be a better strategy for most categories of public web-facing interfaces.

Javascript based redirect: will it hurt SEO?

I recently implemented a fix to create separate landing pages depending on whether or not the user has javascript enabled. Basically the way it works is this.
The default page is an HTML page w/ no javascript. Basic version of the site. Upon landing on it, there is a script that says if javascript is enabled then go to another page. That landing page is generated by sending the user request through a JSP file that renders the page (header, footer, etc.). The final landing page is http://whatever.com/home.jsp if the user has javascript enabled.
My question is if this will hurt SEO. Considering 99% of the world has javascript enabled I would hate to compromise any SEO benefit to accomodate the 1% who doesn't enable javascript.
Hope that make sense.

In general, searchbots should be treated as browsers with JS disabled. I think you can now imagine where they'll land.
This whole question is by the way completely unrelated to JSP. It is just a server side view technology which provides a template to write HTML/CSS/JS in and provides capabilities to control the page flow dynamically with taglibs and access backend data with EL. All what webbrowsers and bots sees (and thus all what counts for SEO) is its generated HTML output.

http://www.google.com/support/webmasters/bin/answer.py?answer=66355
Short version, if your JS sends them to entirely different content, it's probably bad, and Google may give you a a hard time. Other than that, you should be good.

If the alternative version is an (almost) full-featured, full-content version, then it's perfectly OK.
Google even advices for making alternatives for Flash-only sites, for example, in regard to usability.
Read google FAQ

You touch two topics, one is described as "Cloaking", the other as "Duplicate Content". With "cloaking", you present different (optimized-with-bad-intention) content based upon identification of the client that accesses it, e.g. by inspecting the User-agent header (google-bot versus Browser). You are not doing this, you just want to present content in a way that suits your client best, like a redirect on a page optimized for mobile clients ("m.example.com").
The other thing is how to avoid duplicate content. There's a way by indicating the original content source with a canonical tag, see here: http://googlewebmastercentral.blogspot.com/2009/02/specify-your-canonical.html

When NOT to use AJAX in web application development? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
I'm building a web application with the Zend Framework. I have wanted to include some AJAX type forms and modal boxes, but I also want my application to be as accessible as possible. I want my application to be enhanced by AJAX, but also fully functional without AJAX.
So as a general guideline...when should I not use AJAX? I mean, should I bother making my application usable without AJAX? Or does everyone have AJAX enabled browsers these days?

If you mean "accessible" in the ADA sense, AJAX is usually a no-no - your site should provide all its content and core functionality using only standard (X)HTML and CSS. Any javascript used should merely extend the core functionality, and your site should be coded to work elegantly in the absence of a javascript-enabled browser.
Examples: if you want a user to click on a thumbnail and get a full-size version of the image as a result, you can make the thumbnail a link. Then, the onclick event will fire a JQuery method that cancels the navigation behavior of the link and pops up a JQuery floating div to show the image on the current page. If the user's browser doesn't support JavaScript, the onclick event will never fire, and the user will be presented the image in a new page. The core functionality is the same with or without scripting.
EDIT: Skeleton example, sans JQuery-specific code.
<html>
<body>
Some URL
</body>
</html>
To cancel the navigation operation, simply make sure that the method invoked by the onclick event returns false at the end.
A neat example of the JQuery image popup I described can be found here.

Use ajax if it adds value for the user.
If the ajax version adds a lot more value than the non-ajax version then it might justify the expense to develop a solution that caters for both clients. Generally i wouldn't recommend doing the extra work (remember.. more code results in more maintenance).

I think one point is missing here: Use Ajax only for content any search engine does not need to know.

98% of users will have AJAX enabled browsers.
A significant percentage of those people won't have it turned on when they first visit your site though (or at all, ever perhaps).
I've seen websites that look like a blank page without javascript on. Don't be one of them. Javascript to fix layout issues is a horrible idea in my opinion. Make sure it loads and looks ok without Javascript. If people can atleast see what they are missing out on, they are likely to switch it on, but if your website looks like it's just broken, then...

I often have noscript block Flash and JavaScript until I make the decision that your site is worthy.
So be sure to tell me what I'm missing if I have JavaScript turned off.

It depends on the complexity of your web application.
If you can, having it functional with javascript disabled is great, because it makes your application usable not only by users on js-disabled browsers but also by robots. The day you decide to write an application to automatically fill your forms, for example, you don't have to write an API from the ground up.
In any case, do not user AJAX for EVERYTHING! I have just inherited a project that basically consists of a single page that is populated by a ton of AJAX calls and I can tell that you just thinking about it gives me physical pain. I guess the original developer didn't like the concept of using the back/forward button in the browser as a mean of navigation.

Unless you are targeting mobile devices or other non-standard web users, you can be fairly sure that the vast majority has Javascript enabled, because most major sites (including SO) rely heavily on it.

I want my application to be as accessible as possible.
You can do things like rendering your modals and forms as a page that can operate standalone.
The AJAX version pulls the template into a modal/container, the standalone version checks if it's an AJAX request and renders the page including the header/footer (this can occur from the same URL if planned well)
The AJAX version intercepts the submit and does AJAX submission then provides an inline thank you, the non-AJAX opens a thank you page. Once again you can likely use the same pages for each of these functions if thought out correctly.
Reusing templates and URL's helps avoid additional maintenance for the AJAX/non-AJAX versions.
I want my application to be enhanced by AJAX, but also fully
functional without AJAX.
Thinking through the structure of your URLs and templates can go a long way towards this, if you make most of your AJAX requests pull in completely rendered templates (as opposed to just data) then you can usually use the same URL to serve both versions. You just serve only the guts of the modal/form to the AJAX request and the entire page to a regular request.
When should I not use AJAX?
You should not use AJAX if doing so will cause a poor experience for a significant portion of your user base (there are of course techniques that can be used to mitigate this)
You should not use AJAX if the development time associated with implementing it will be too significant to justify the improvements in user experience
You should not use AJAX for content which has significant SEO value without implementing an appropriate fallback that allows it to be indexed (Crawlers are improving constantly but it's still a good idea)
I mean, should I bother making my application usable without AJAX? Or
does everyone have AJAX enabled browsers these days?
I'd say a lot of the time it's unnecessary as the vast majority of users will have AJAX enabled browsers, but there are scenarios where it's critical such as SEO optimization or when a large portion of your user base is likely to use browsers that are less likely to support Javascript as well or where they're likely to have Javascript/AJAX disabled.
A few examples of these scenarios:
A website for a company or government that uses an outdated browser as standard
A website where a large portion of the users may be disabled in a manner that may negatively impact their experience such as a website for vision or motor-skill impaired people may be negatively impacted by updating content via AJAX especially if it occurs rapidly.
A site accessed regularly via a less common device or browser that will cause a negative impact to a large portion of users
So what should I do?
Think about who is going to be using the site, how they're going to access it, and what they're going to access it with. Also try to think about not just the present but also the future.
Design the site in a manner that will cater to the majority of these users.
Think who will gain and who will loose based on my decision to use AJAX and if in doubt have a look at your analytics data to help weigh up the decision and if you lack the data it may be worth updating your tracking and obtaining a sample to aid the decision
Think does my decision to use AJAX cause any contradictions with core requirements for this project
Use AJAX to enhance content where possible as opposed to making it mandatory ie the content should work with or without JS/AJAX
Consider the additional development time involved with the use of AJAX (if any)

My experience is, we should use ajax after it works without it. For a couple of reasons.
First, if something breaks in the ajax, and you don't have it working without it, the site simply doesn't work. For example, a product list with pagination. It should work with the links alone, then use ajax when possible.
Second, for site indexing and accessibility. If it works without ajax, it's better.
And it's easier to break something (even if only for a few moments). A bad piece of code, an uncaught exception, an external library not loaded, a blocking browser extension,...
After everything works without ajax, its quite easier to add ajax. Just have the ajax catch the action, add ajax=1 and when returning the result, return only what you need if ajax=1, otherwise return everything.
In the product list example, I would only return the products and pagination html, and add to the correct div. If ajax stops working, the whole page is loaded and the customer sees the second page as it loads.
Ajax adds a lot of value to UX. If done right, the user gets a great feel when using the site, and better data usage because it doesn't load the whole page everytime.
But the question being "when not to use ajax", I would say, you should always count on it to improve UX but not rely on it for the site to work (as other users also mentioned). And nowadays we need both, great code and great user experience.

My practice is to use two main pages, let's say index.py and ajax.py. First one is responsible for generating full website, and is default target of forms. Other one generates only output specific for adequate ajax query. Logic behind both of them is the same, only the method of generating output is a bit different.
In jquery I simply change action parameter when sending a request. It works both with and without ajax, although long time have I not seen someone with disabled js and ajax.

I like the thought of coding your application without JavaScript / Ajax and then adding it in later to enhance the UI without depriving users of functionality just because they don't have JavaScript enabled. I read about this in Pro ASP.NET MVC but I think I've seen it elsewhere in reading about unobtrusive JavaScript.

You should not make your service bloated with web 2.0 effects like accordion, modal/etc forms, image zoomers etc.
Use modern tech smarter (AJAX is one of them) and your users will be happy. Do not fear AJAX -- this is very good thing to make user expirience smooth. But don't do things because you like it - do them because your user need it ;)

When you want to make a website that looks like a website, not a fugly imitation of a desktop app?

You should not use AJAX or JavaScript in cases where:
your system needs to be accessible
your system needs to be search friendly
However, by using a modern JS framework with some solid "unobtrusive" practices, you can progressively enhance pages so that they remain accessible and search-friendly while offering a slick UI to users.

This totally depends on the type of application or feature you're developing. If it is crucial that the application is accessible despite the absence of Javascript, then it would help to have fallback methods (i.e. alternative forms) to allow your user to use said functionality/feature. For that, it will require you to invest some of your time developing methods for collecting information not just using client-side scripts but also on the server-side.
For miscellaneous features that only serves to enhance user experience, it's mostly not worth it to develop fallback methods.
There's no reason to totally not use AJAX. AJAX helps minimize your traffic after all.

You can if you wish always use AJAX and update the history state using Push State or for more compatibility use the hash with none HTML5 compliant browsers.
with this you can have your server load a page then javascript read the document.hash and resume the state of the application base on the state of the hash.
for example i got to /index.html i click into something for example a client to open the view client you can change the hash to #/view/client/{client_id}/ then if a reload or go back using the browser the hash with change and you can use the onhashchanged event to capture it and match the sites state to the new hash then same if a favorite a certain state

A couple of other scenarios where one may be better off NOT using AJAX:
Letting someone to log into the web application. Use traditional form submit instead.
Searching and returning more than a few 100 rows from the database. Either break the process down or let the server side language handle it.

Experiences with Javascript History Frameworks

I'm seeking a javascript history framework to handle navigation inside a page when the user selects multiple options which change the page behaviour.
There are multiple artefacts on the page that change the data loading of the page and I'd like to store this as a stacked set of behaviour. In a wider sense, I'd like to add this as a toolkit to my future web projects for the same reasons.
I'm primarily writing in ASP.NET with JQuery but I'm only really worried about JQuery for now. I do write other projects in PHP, Python and Perl (depending on the gig) so it would have to be platform agnostic.
I've been looking on the net and have found a few but only one (covered on OReilly) looked like it would fit the bill. I have started playing with it but I wanted to know what toolkits other people were using and what others would recommend.
So if you have any experience of history frameworks, handling the back button (etc) in Ajax I'd love to hear about what you've used and how it worked out. It would really help me make a final choice on library.
Thanks,
S

I had the similar problem a while ago building a flash only site. We tried:
Really Simple History (which had some problems in combination of safari and flash)
ExtJS which has a history component which worked great for us. (Demo) [Beside we have used this framework already for other projects.]

Maybe this question is usefull to you. In the question I linked to a testpage, where location.hash is used to keep track of the history. I am currently using this method in a testsite and experienced problems with Opera (truncates a location.hash value at the question mark, you'll have to use: location.href.split(/#/)[1]) and of course IE (needs an iframe). In IE with iframe the history is saved for the current session only. If you load another page in the same window/tab and use the back button to go back to the AJAX page, the previous history is lost. It's not that big a deal for me, but may be annoying. I understood that IE8s history should behave like expected with location.hash, it even should have a hashchange handler.
I think most of the frameworks use the same technique (monitoring location.hash for changes, using an iframe for IE). I didn't want to use a framework, because I'm using my own home brew small framework and regular frameworks contain too much functionallity I'll never use.

jQuery History is my preferred choice. It can be found here: http://www.balupton.com/projects/jquery-history/ Provide cross browser support, binding to hashes, overloading hashes, all the rest.
There is also an Ajax extension for it called jQuery Ajaxy, allowing it to easily upgrade your webpage into a proper Ajax application without need for server side changes and remaining SEO and JS-Disabled friendly: http://www.balupton.com/projects/jquery-ajaxy/
Overall they are both well documented, supported and feature rich. They've also won a bounty question here How to show Ajax requests in URL?

Dial.js is a JavaScript browser history framework designed to provide some of the features of a full-fledged MVC framework with jQuery and History.js for single-page applications (SPAs).