Ajax: When to use it

[karentutor1]

Hi,

I get the point of Ajax - you can send pieces of data rather than the whole script. What I am not clear on is when it is best to use it.

i.e. I can see it can be used for most data submission on the page - logging in, out, submitting data etc. From what I can it may be useful to use it to send almost All of my data to server requests (post validation of course).

Is there any hallmark of a useful time to use Ajax script? Or a (almost) flashing light that indicates that this is a good time to use Ajax and conversely when not?

Tx
Karen

[Dormilich]

@karentutor1

I get the point of Ajax - you can send pieces of data rather than the whole script.

That’s not the main point. Which would be to make a request without forcing a page reload (background request).

[coothead]

@karentutor1

Ajax: When to use it?

If you can do without it, never.

coothead

[fretburner]

@coothead

If you can do without it, never.

I suppose that depends on your definition of being able to ‘do without’.

There are lots apps that do basic CRUD (create, read, update, delete) operations that could be done without making Ajax calls. But as @Dormilich points out, Ajax allows you to do these operations without forcing the user to endure a full page reload, which provides a much better experience.

If you’ve ever filled out a registration form online, you’re probably familiar with those that validate your input as you type, checking your choice of username against those that already exist etc. If you had to submit the form and wait for the page reload to find out if your username was already taken, that would quickly become pretty frustrating.

[mawburn]

@coothead

If you can do without it, never.

Always. Anywhere except a first page hit. Do it with AJAX. Don’t make the user rerender the page and don’t make the server work extra. That’s pointless and it’s not 1995.

[coothead]

@mawburn

Always

so long as it meets the criteria that our deceased member @felgall laid out…

Progressive enhancement:
[color=navy]

1. You write your page content as if both CSS and JavaScript are off.
2. You write CSS to style the page the way you want it to look when
   JavaScript is off.
3. You write additional CSS to change the way you want the page to
   look when JavaScript is turned on.
4. You write CSS for the way you want the page to look when specific
   JavaScript commands are supported by the browser.
5. You add a few lines of JavaScript to the head of the page to add
   the necessary classes to the html tag for the styles you wrote in
   steps 3 and 4 to be applied.
   [/color]

coothead

[fretburner]

As knowledgeable as felgall was (and he was a veritable mine of JavaScript history), he overlooked the distinction between web sites and web applications. Those rules make a lot of sense when creating sites, where the primary aim is to communicate information as widely as possible, but the web is now also an application platform and you simply can’t apply the same mindset.

I think it’s important that we keep the distinction in mind when answering questions here on the forums, as not everyone is here just to learn about building sites.

[coothead]

Hi there fretburner,

So for the question…

“Ajax: When to use it”

…can we now agree that the answer lies somewhere between…

        never and always .

coothead

[fretburner]

Or, as is often the response to questions from clients and managers, ‘it depends’

[MartinMuzatko]

I recently thought about how I should obtain data. If there are any performance benefits of inline assigning data rather than retrieving it via ajax. I asked that question on quora. The answers I got were interesting! Even more interesting are the answers to the more specific question: “When should I prefer inline php to js assignments over a REST API”.

For myself, I found out the following problems with that, and why so many developers decide they’d rather do direct php to js assignments.

Information architecture
Most of the times, developers use AJAX to work around the page-reloading limitation of forms.

Forms reflect your information architecture. When developers have to take care about both front-end and back-end, they often set out to create a form, just to discover that they haven’t thought about how to store or process that data.

Predefined data exchange
Back-end frameworks (CMS or fullstack) decide for you how to hand over data from client to server. (IF there is an option)

When I worked with TYPO3 some 4 years ago, the CRUD framework that came with it had no REST interface at all. I had to research about 3 days and even ask the devs how AJAX is officially meant to be implemented.

From Quora, I got the following recommendation:

For small projects that need to be built fast and get the job done and they do not interact with Mobile Apps, Desktop apps, you should not use an API because you make your work a lot harder and you might run into different problems that require some time to understand and fix. Just go with inline coding and that’s it.
On the other hand, if you build a platform/web service/something custom that will have its equivalent mobile/desktop app and you know it will be used in the long-term, build it with a REST API from the beginning. It’s the best thing to do.

I personally wonder, is there something between inline assigning data (generating lots of HTML to load by the user on load) and dynamically loading data via REST API. REST APIS are a huge organizational step and it takes a lot of time to define endpoints and how they should work together with user input.

Best,
Martin

[robertofastec]

Hello, first of all, I think all of us agree, AJAX “is not jQuery”

Yes, the UX with AJAX is much cool. But as much as cool UX, I see soo much cool this:

On the HTML side, the view, AJAX is just some 5 lines of javascript and only plain vanilla javascript, NO libraries required.

The part I like is that with javascript you have more control on/and submit possibilities,

in few words you can forget what an HTML form is. Instead, virtually, you can submit to the server side almost whatever you want.

About whatever you want: DOM is your friend until it ends

You can turn to an input what you like, getting elements by ID, by class, etc,
you can collect an entire HTML table and transfer it to an array (I mean without input fields in the TDs, here HTML5 enhances even more the game with contenteditable) and your fantasy + needs can rise so many combinations as well.

The mechanism is not that different than a normal form submission, but the potential is not comparable.

e.g. you don’t have anymore forms and instead you can have as many “forms”-like as you want on the same page (here I’m thinking about Web applications, think about a simple invoice)

Additionally when needed there is the lightweightness of JSON with an amount of benefits.

In my learning curve I have almost skipped the classic html form part.

Yes you need javascript activated… but nowadays it is almost impossible to meet some disabled js and warn the user about JS is required, is working on every browser with just a line of html.

[John_Betong]

@karentutor1

Is there any hallmark of a useful time to use Ajax script?

I use Ajax for a “Dynamic Ajax Search”. Search this forum for the tutorial and online demo.

The JavaScript passes the form input text characters to an Ajax query that dynamically searches a MySQL database. Limit is used to return the first dozen results which populate a blank placeholder div.

I am impressed with the rendering speed which is virtually instant.

[Andres_Vaquero]

I have a mechanism by which I can request fragments of a page or components via AJAX. The application will make a shortcut just to retrieve the necessary section from a particular page. Then I can refresh and load those fragments at will. The amount of time it takes to render them will be much shorter as it’s skipping all the major rendundant bits such as header, navigation, footer etc… When you have a complex page with lot’s of content, the server and your users will thank you