واژه ajax را برای اولین بار jesse james garrett در فوریه سال ۲۰۰۵ در مقاله ajax: a new approach to web applications استفاده کرد . اگرچه نام ajax برای نخستین بار در سال ۲۰۰۵ ابداع شد ، اما تاریخچه اکثر فناوری هایی که به ajax منتهی شدند به حدود یک دهه قبل و ابتکارات مایکروسافت در اسکریپت نویسی از راه دور باز می‌گردد . با این حال تاریخچه فناوری هایی برای بارگذاری غیرهم روند محتویات یک صفحه وب ، بدون نیاز به بارگذاری دوباره صفحه ، به عناصر ( frame )که در سال ۱۹۹۶ در نسخه ۳ ie ارائه شد و عناصر layer  که در سال ۱۹۹۷ در نسخه ۴ مرورگر netscape ارائه شد ، اما در نسخه‌های اخیر موزیلا متروکه شده ‌است  باز می‌گردد . هردوی این عناصر ، یک خصوصیت src دارند که می‌تواند یک آدرس url خارجی را شامل شود و به این ترتیب اگر صفحه‌ای شامل یک کد جاوااسکریپت بارگذاری شود که صفحه والد را دستکاری می‌کند ، نتیجه‌ای شبیه ajax خواهیم داشت

اسکریپت نویسی از راه دور مایکروسافت ( یا msrs که در سال ۱۹۹۸ مطرح شد ) جایگزین مناسب‌تری برای تکنیک‌های گذشته به نظر می‌رسید . در این روش ، داده‌ها به‌ وسیله یک java applet دریافت می‌شد ، و در سمت کلاینت برقراری ارتباط به ‌وسیله جاوااسکریپت انجام می‌گرفت . این روش در نسخه‌های ۴ و بعدتر اینترنت اکسپلورر و نت‌اسکیپ پشتیبانی می‌شود .
مایکروسافت در نسخه ی ۵ اینترنت اکسپلورر شیء xmlhttprequest را ارائه کرده و برای اولین بار در out look web access که در microsoft exchange server2000  ارائه شد ، از این روش با استفاده از شی xmlhttprequest بهره جست .
در نهایت با تغییر و تحولاتی که در این مسیر به وجود آمد و جایگزینی شیء xml http request به جای java applet ، اکنون روشی برای اسکریپ نویسی از راه دور متداول شده که آن‌را با عنوان aJax می‌شناسیم .
اما آنچه باعث شد پس از این مدت ، ناگهان توجه‌ها به سمت ajax جلب شود ، تمرکز شرکت گوگل بر این معماری بود . وب‌سایت‌هایی از قبیل google map ، gmail و google suggest پروژه‌هایی بودند که باعث شد توجه کاربران ، چه کاربران عادی و چه کاربران حرفه‌ای ، به نحوه کار آنها جلب شود   .
ajax به عنوان معماری جدیدی برای وب روش کار برنامه‌های کلاسیک وب چیزی شبیه این است :
اکثر تعاملات کاربر با رابط کاربری باعث ارسال یک درخواست به سرور می‌شود . سرور پردازش‌های لازم را انجام داده و سپس یک صفحه html به کلاینت بازمی‌گرداند . این مدل بر اساس هدف اصلی وب ، یعنی ایفای نقش یک رسانه برای ابرمتن است . اما آنچه وب را برای ابرمتن‌ها مناسب می‌کند ، الزاماً آن را برای برنامه‌های نرم‌افزاری نیز مناسب نخواهد کرد . مسئله اینجاست که برنامه‌های وب برای کاربرد ( application )  بودن طراحی نشده‌اند و این باعث شده‌است که در بسیاری موارد کاربر را نادیده بگیرند .
فرض کنید کاربر می‌خواهد در یک فروشگاه الکترونیک ، مشخصات جنس بعدی را ببیند ، یا یک جنس را به سبد خرید خود اضافه کند . اتفاقی که می‌افتد این است که برای انجام هریک از این کارها ، چون نیاز است با سرور ارتباط برقرار شود ، باید یک درخواست به سرور ارسال شده ، سرور پردازش های لازم را انجام دهد و سپس یک صفحه به عنوان نتیجه بازگرداند . کاربر هم در این میان می‌تواند با انگشتانش بازی کند !
گرچه ما به صفحات وب ، با همین روند انجام فعالیت هاعادت کرده‌ایم ، اما واقعا روش کلاسیک برنامه‌های وب ، گرچه از نظر تکنیکی مزایای بسیاری دارند ، اما مشکلات عمده‌ای هم دارند . یکی از عمده‌ترین مشکلات صفحات وب را می‌توان هم روند کار کردن آنها دانست . ( یعنی همین که وقتی درخواستی از سرور داریم ، صفحه وب مقابل مان مسدود شده و باید منتظر بمانیم تا سرور کارش تمام شود و صفحه‌ای به عنوان پاسخ برگرداند ) .