Edit: in addition to the earlier edits below about points being moot if you're doing an SPA, this entire question becomes essentially moot with the use of progressive enhancement SSR frameworks like Remix.

Prior to widespread AJAX use and DHTML a form was submitted and the browser would refresh by loading the response to that POST HTTP request which replaced the previous (form) page in the viewport. Now, with AJAX being in common use, there are two ways to go about it.

I am trying to come up with some general guidelines of when it's better to use each particular approach. Here's what I came up with. I'd love to see if there is an existing set of use cases that is better than my rough attempt, or if there are other general use cases I haven't considered.

use AJAX submission when:

  • form submits 'to itself' (we show the same form after submission)
  • form is only a part of a larger view (such as a search form where search results may be dynamically added to an area on the page, such as a table or thumbnail grid)

use regular form submission when:

  • following submission we intend to have the user end up at a different page edit: this point is moot if using a single-page application architecture
  • form data submitted will change the data in the db or the application state in such a significant manner that the page should be 're-run' rather than attempting to submit via AJAX and then do an inordinate amount of work on the client to make the existing page reflect the changes (though I think in many cases changes may be simple enough that client-side view manipulation to reflect the new data/state will be appropriate) edit: this point is moot if using a reactive view library/framework (such as React)

Also be good to know if there are reasons why these guesses might produce a sub-optimal UX.

  • I'm not sure if it's relevant, but I have noticed that banking websites log in forms do not trigger the browser's password save feature. This is probably by design. Could it be that one other reason to use AJAX is to not trigger the password saving feature for security reasons? Oct 7, 2019 at 11:31

2 Answers 2


From a UX standpoint I think AJAX is going to be better 100% of the time IF you can provide ALL of the proper visual cues that the form is processing and not just giving the illusion of being broken.

Some things to consider are:

  • Provide a visual spinner within the <button>Submit <img src="spinner.gif"></button> and make sure to remove it once processing is complete

  • Upon submission disable the button programmatically, and visually and programmatically prevent double-submission of the form

  • Provide an easily identifiable message box with clear error vs success vs further action required messages

  • Take into account network and server errors which can cause unexpected results to occur, make sure to catch them

  • If you need to display a different page upon success then JS can certainly handle that

From a programming standpoint it makes your life easier because you do not have to worry about carrying through the POST value of a field especially since that field could have been dynamically generated through user interaction.

If you are doing a very large POST then the user has to sit and wait until the browser can send all of those bytes to your server before the page changes and I assume your users are not anymore patient than mine.

  • 1
    Good idea to show the spinner inside the button Jun 14, 2016 at 18:31
  • 1. Why "from a UX standpoint [...] AJAX is [...] better 100% of the time if <etc>"? In what sense will it be better? This is a big claim, and it's not at all clear to me. 2. "From a programming standpoint <etc>" - could you rewrite this more clearly? I don't understand the point you are trying to make. Apr 9, 2021 at 13:36
  • @JanŻankowski I wrote this answer 7 years ago and included all the details deemed necessary which 14 people seemed to have agreed with. If you have a particular disagreement then please let me know, write an answer yourself, or post your own question detailing your confusion with my answer.
    – MonkeyZeus
    Apr 12, 2021 at 12:54

Overall your list of assumptions are heading in the right direction, though I wouldn't exclude yourself from the possibility of using both when it makes sense. Here are a couple other ideas:

  • Use AJAX to validate a form as a user moves along so they can see errors (or successes) more quickly.
  • Consider using AJAX for input fields which could help you make smarter defaults/assumptions about other areas. For example, ask for a zip/postal code first to pull back the city and state/province or even the telephone area code.
  • Use AJAX to temporarily (or actually) save content the user has written so far. Things happen. Browsers freeze. Computers lock up. Internet connections drop. Keeping track of drafts will help a user feel not so deflated when something interrupts what they were trying to do. You could still provide a "Save Draft" button. Clicking the button would just re-send the AJAX call.
  • Use a typical submit method when creating content that requires a refresh of the page or redirection to another page.
  • re: "using both when it makes sense". I've been recently starting to use Remix, which gives both by default in a progressively enhanced way. Next.js is also now moving in the same direction as Remix, and I expect other frameworks will eventually make the "both" far more approachable and smooth out the whole thing for developers (and users). Good time to be in web development :) Jun 14, 2022 at 22:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.