21 Oct 2025

Whispering to the Server: The Magic of AJAX

This is part 3. Part 2 is here

The traditional form submission we just discussed is powerful, but it feels a bit clunky by modern standards. Every time you submit, the entire page reloads. What if you just want to "like" a post, check if a username is available, or add an item to a shopping cart without losing your place on the page?

This is where AJAX comes in. 🚀

AJAX stands for Asynchronous JavaScript And XML. That's a mouthful, but let's simplify:

  • Asynchronous: It means your code can send a request to the server and not wait around for the response. It continues doing other things, and when the server replies, a function you've defined will handle it. It doesn't block the user.

  • JavaScript: Instead of the browser automatically building the request from an HTML form, you write JavaScript code to build and send the request. You have full control.

  • XML: This is a bit of a historical name. While you can use XML, today we almost exclusively use JSON for sending and receiving data with AJAX.

The key takeaway is this: AJAX lets you send and receive data from the server in the background, without a full page reload.


## How It Works: JavaScript Takes the Wheel

Let's revisit our login form, but this time, we'll supercharge it with JavaScript using the modern fetch() API.

The HTML (with a small addition):

HTML

<form id="ajax-form" action="/login" method="POST">

  <label for="username-input">Username:</label>
  <input type="text" id="username-input" name="username">

  <label for="password-input">Password:</label>
  <input type="password" id="password-input" name="password">

  <button type="submit">Log In</button>

</form>

<div id="response-message"></div>

The JavaScript Magic ✨:

JavaScript

// Get the form element from the page
const loginForm = document.getElementById('ajax-form');

// Listen for the form's 'submit' event
loginForm.addEventListener('submit', function (event) {

  // VERY IMPORTANT: Stop the default form submission (the page reload)!
  event.preventDefault();

  // Create a FormData object to easily grab the form's data
  const formData = new FormData(loginForm);
  // Convert the data to a plain JavaScript object
  const data = Object.fromEntries(formData.entries());

  // Use the fetch API to send the request
  fetch('/login', {
    method: 'POST', // We still specify the method
    headers: {
      // Tell the server we're sending JSON data
      'Content-Type': 'application/json',
    },
    // Convert our JS object into a JSON string for the body
    body: JSON.stringify(data),
  })
  .then(response => response.json()) // Parse the JSON response from the server
  .then(result => {
    // SUCCESS! Now, update the page without a reload
    const messageDiv = document.getElementById('response-message');
    messageDiv.textContent = result.message; // e.g., "Welcome back, dev123!"
  })
  .catch(error => {
    // Handle any errors that occurred during the request
    console.error('Error:', error);
    const messageDiv = document.getElementById('response-message');
    messageDiv.textContent = 'An error occurred. Please try again.';
  });
});

Here's what this JavaScript does:

  1. It "hijacks" the form's submit event.

  2. event.preventDefault(); is the crucial line that stops the browser from doing its normal page reload.

  3. It manually gathers the data from the form.

  4. It uses fetch() to create and send an HTTP request in the background. Note that we're explicitly setting the Content-Type header to application/json and converting our data to a JSON string.

  5. When the server responds (with JSON data like {"message": "Login successful!"}), the .then() block runs.

  6. Instead of reloading, our code simply takes the response message and uses JavaScript to place it inside the <div id="response-message">. The page itself never changed!


## HTML Forms vs. AJAX: The Showdown

FeatureClassic HTML Form SubmissionAJAX Request
TriggerUser clicks <button type="submit">Any JavaScript event (click, keyup, submit, etc.)
Who Builds Request?The Browser (automatically)You (via JavaScript code)
Page BehaviorFull Page Reload. The entire page is replaced.No Page Reload. The page stays, and you use JS to update parts of it.
User ExperienceCan feel slow and disruptive. 뚝딱Smooth, fast, and interactive. ✨
Typical Use CaseInitial site login, multi-page wizard processes.Likes, comments, live search, shopping carts, modern web apps.

By mastering AJAX, you move from building static web pages to creating dynamic, responsive, and modern web applications that feel like desktop software. It's a fundamental skill for any web developer today.

Your First Conversation with a Server: How HTML Forms Work

This is Part 2. Part 1 is here

So, you've learned that browsers and servers talk to each other using a language called HTTP. That's great! But how do you, as a developer, give the user a way to start that conversation? The most classic and fundamental way is by using an HTML form.

Think of an HTML form like filling out a physical postcard. 📝 You have specific fields to fill in (name, address), and when you're done, you drop it in the mailbox to send it off to a specific destination.


## The Anatomy of an HTML <form>

Let's build a simple login form and see how its parts create an HTTP request.

HTML

<form action="/login" method="POST">

  <label for="username-input">Username:</label>
  <input type="text" id="username-input" name="username">

  <label for="password-input">Password:</label>
  <input type="password" id="password-input" name="password">

  <button type="submit">Log In</button>

</form>

Let's break down the key pieces:

  • <form>: This is the main wrapper, our "postcard." It has two crucial attributes:

    • action="/login": This is the destination address. It tells the browser which URL path on the server should receive this information. This corresponds to the path in the HTTP request line (e.g., POST /login HTTP/1.1).

    • method="POST": This is the shipping method. It specifies which HTTP verb to use. The two most common methods for forms are:

      • GET: The data is appended directly to the URL in the address bar (like writing on the outside of the postcard for everyone to see). Good for search queries, but terrible for passwords!

      • POST: The data is placed inside the body of the HTTP request (like putting your message inside a sealed envelope). This is the standard for submitting sensitive or large amounts of data.

  • <input>: These are the fields the user fills out. The most important attribute here is name.

    • name="username": This acts like a label for the data. When the browser packages up the information, it uses this name as the key. The value the user types in becomes, well, the value! This creates a key-value pair.
  • <button type="submit">: This is the "Send" button. When a user clicks this, the browser springs into action.


## The Journey: From Click to Request

Let's say a user types "dev123" into the username field and "p@ssword" into the password field and then clicks "Log In." Here's what the browser does behind the scenes:

  1. Look at the <form> tag: "Okay, the method is POST and the destination is /login."

  2. Gather the data: It finds all <input> elements with a name attribute inside the form.

    • It finds an input with name="username" and its value is "dev123".

    • It finds another with name="password" and its value is "p@ssword".

  3. Build the HTTP Request: The browser now constructs the HTTP request you learned about, automatically. It looks something like this:

    HTTP

    POST /login HTTP/1.1
    Host: yourwebsite.com
    Content-Type: application/x-www-form-urlencoded
    
    username=dev123&password=p%40ssword
    
    • Notice the Content-Type header. This is the default for HTML forms, telling the server how the data in the body is formatted (key-value pairs joined by &).

    • Look at the body! It's the data from our form, neatly packaged. The browser even URL-encoded the @ symbol to %40 to ensure it's transmitted safely.

  4. Wait for the Response: The server processes this request. If the login is successful, it might send back a brand new HTML page (like a welcome dashboard).

  5. Full Page Reload: The browser receives this new HTML page and discards the old one completely. It then renders the new page from scratch. This flash and reload is the classic behavior of a form submission.

That's it! An HTML form is simply a user-friendly tool for constructing a standard HTTP request, which results in a full navigation to a new page.

8 Sept 2020

Here are 7 tips for working remotely

1. Get started early

One way to work from home productively is to dive into your to-do list as soon as you wake up. Simply getting a project started first thing in the morning can be the key to making progress on it gradually throughout the day.

2. Get your technology in order

Make sure to take your laptop home, and don't forget your charger — anything that might make working on your laptop from home a little easier. Make sure you have the right applications. Lots of remote workers are leaning heavily on Slack, Microsoft Teams, Skype, Zoom, or GoToMeeting.

3. Structure your day as you would in the office

To stay on schedule, segment what you'll do and when over the course of the day. If you have an online calendar, create personal events and reminders that tell you when to shift gears and start on new tasks. Google Calendar makes this easy.

4. Creating an “Office Environment” is important

Just because you're working from home doesn't mean you can't have a dedicated workspace or office. Try to set up your workspace in a well-lit room or one with as much natural light as possible. Have a good chair. Stand up.

5. Track your every hour

You must track how you're spending every hour of your day. Self-tracking will help you to decide when you're most productive (and when least). And where you're wasting your precious time.

6. Manage expectations

Have a discussion with your boss about what can actually be accomplished from home. Ask your manager what the priorities are and discuss how tasks will get done.

7. Schedule a distraction break for you

You schedule your tasks, meetings, and calls in the calendar, right? There's one more thing that you MUST plan: Distraction Breaks. Set the time when you'll use the phone or social media. Set the time for lunch. Set the time for a nap. These breaks will recharge you.




24 Sept 2018

CSS learning resources

To understand the fundamentals, http://learnlayout.com/ is a really good website.
  
Documentation

https://developer.mozilla.org/en-US/docs/Web/CSS (This one is the best and most comprehensive, much better than w3school)


Important concepts to understand:





- clear fix (this one is by far the best and easiest to implement) - http://nicolasgallagher.com/micro-clearfix-hack/



Advanced links to improve techniques and code clean and maintainable code:

- this is a mini-game that helps understanding flexbox and all its possibilities, very fun and interesting! - http://flexboxfroggy.com/





CSS/Sass frameworks and tools that can be helpful

http://postcss.org/ - css post-processor, provides very useful tools such as an autoprefixer to handle browser-compatibility

http://bourbon.io/ - sass library

https://purecss.io/grids/ - there are many other grid frameworks. knowing at least one can really help understanding how to create clean and standardised layouts


Blogs of great front-end developers, full of interesting posts!










19 Feb 2018

Conversation between 2 developers in 2016

I bet you won't stop laughing. for front end people ->
https://hackernoon.com/how-it-feels-to-learn-javascript-in-2016-d3a717dd577f

for open stack backend people->
https://circleci.com/blog/its-the-future/

It also made me realise how much I don't know/understand. Again speed at which industry is changing in terms of "new needs after every new solution" and that is a cycle.

19 Jan 2017

Understanding a merge commit - git

This is what I sent today to my colleagues while explaining the reason for mysterious changes in a pull-request
That blank merge commit is the culprit. All changes which should be result of merge are blown away.
Explanation:-
First let's understand that a merge commit is also a commit with changes. Changes in source branch since its diversion (from destination branch) are auto-magically done as part of merge commit in destination branch. 
So a merge occurred without any changes (if its been blown away as it has been the case) in merge commit, is basically a reversal of all changes that have occurred in source branch since the destination branch diverged from it. Hope this clarifies the mystery.
To visualise how chain of commits are formed, diverged and merged, you can refer to the image in Understanding what GIT does under the hood rather than only learning commands and wondering

22 Aug 2016

Basics of Basics of Web Application Development - Crash Course

I've not made mistake of repeating the words "Basics of" as you might have been thinking. I'm just calling these things so basic and integral to web development that they are basics of "basic concepts of web application development"

1. Protocol - Protocol means,
    • same terms that are understood or agreed by two or more parties (e.g. client browser and server).
    • a language (or call it sign language or code words) that is understood by two or more parties
2. HTTP - is a protocol/language of web. Web clients and web servers talk in this language with each others. For e.g.

Client says (in its code language i.e. HTTP Request) -

POST /v2/sessiontoken HTTP/1.1
Host: app.kashflow.com
Content-Type: application/json
Accept: application/json

{"username":"ismails", "password":"********"}
Interpretation of code language -
  • Firstly, it is said by client which means it is a request - HTTP request.
  • POST - it's an HTTP method. This means it is a request to create a resource (related to REST concepts). More details here.
  • /v2/sessiontoken - it is a part of URL i.e. it will be appended to value of host header which is provided in 2nd line. So whole URL will form like http://app.kashflow.com/v2/sessiontoken. It is address of the recipient of this message i.e. for whom this code worded message is meant for. 
  • HTTP/1.1 - This request is created using HTTP/1.1 version of sign/code language. It's modern. It might contain modern slangs ;-)
  • From 2nd line starts all request headers and their values follow after colon sign i.e. `:`. Each header has a different meaning and the other party understands it's value accordingly. 
    • Host- request will go to this server address. Address of the server for which this message is intended. Client is saying "Hey Mister! I'm talking to you"
    • Content-Type - It is a message for the server that the body of this request that follows (last line), is in JSON format. If you want to interpret it please make a note about this. Client says "I'm talking in Spanish. Use interpreter accordingly ;-)"
    • Accept - means "As a client I will only understand if you return me a response body which is in JSON format (Spanish language)" 
  • After an extra line break comes body of the request. That is actual talk/speech of client to server.
So this is what client has told to the server. Now server gets the request. It understands/interprets/decodes the request. It processes i.e. takes action as per the request. (In this case, client expects the server to verify the username and password, create an authentication token  and respond with the same if username and password are valid. This part is creation/invention of a developer's mind. You as a developer will decide what you want the client to request and program the server to do as per the request.) Finally server informs back (HTTP Response) to the requester (client) about what action it took and/or its results.

Server says (in it's code language i.e. HTTP Response)
HTTP/1.1 201 Created
Content-Length: 829
Content-Type: application/json; charset=utf-8

{"SessionToken":"f3f14a8b-d370-4318-a629-0a124e47c014"}

Interpretation of code language -
  • HTTP/1.1 - it specifies version of sign/code language this request in.
  • 201 Created - It's HTTP status code. This means as per your request authentication token has been created. Different status codes mean differently. Look for more details here, here or here.
  • Then starts HTTP response headers. Similar to request headers, each one has a meaning. 
    • Content-Length specifies how long the content of body is
    • Content-Type specifies format of response in the body (remember JSON format? Yep, It's client's wish answered)
  • After an extra line break comes body of the response
If for example the username and passwords are invalid, the response would have been different

HTTP/1.1 400 Bad Request
Content-Length: 71
Content-Type: application/json; charset=utf-8

{"Message":"Invalid username or password", "Error":"InvalidCredentials"}

Look at HTTP status codes to decode this response.


3. Browser is an HTTP client.
So let's understand how browser talks HTTP.
  1. Fire up chrome 
  2. Hit F12 key to open up chrome dev tools. Context click and select inspect element if you are on Mac
  3. Select network tab on chrome dev tools
  4. Tick "Preserve log" checkbox
  5. Type google.com in address bar (in chrome main window)
  6. Hit enter.
  7. Select the first request from the list in chrome dev tools window. 
This is what I get to see. Let's decode it.



HTTP Request
  • GET request to `/` (it's a forward slash) i.e. root of the host google.com using HTTP 1.1 version of language
  • Browser `Accept`s or understands only one of these "text/html, application/xhtml+xml, application/xml" other certain image formats etc
HTTP Response
  • 302 Found . It means server is saying that "You have reached at correct address and with valid parcel (request), unfortunately, the information (resource) you are looking for has moved to other place (specified in location header)"
  • Look at the 2nd request in the list (chrome dev tools). Is it a request to same URL which is specified in location header? Yes it is. Browser has interpreted the response correctly and requested other URL as per the response it got from the server.
More walk-through
Basic concepts of web applications, how they work and the HTTP protocol
HTTP in depth

Basic HTTP codes for quick reference
  • 2xx - Success codes
    • 200 - Success - OK - this simply means whatever you have requested is served. Meaning differs as per the request method and content.
    • 201 - Created - this is generally a response of POST or PUT requests
    • 204 - No Content - The server has successfully fulfilled the request and that there is no additional content to send in the response payload/body.
    • 3xx - Redirection codes
      • 301 - Redirction - the information you have requested is now available at some other URL which is provided in `location` header of response
      • 302 - Redirection  - same as above. But a newer version. Look for more details on HTTP specs
      • 4xx - Bad Request codes
        • 400 - Simple bad request i.e. something bad with the request body. Change it correct it and send whatever server expects. Detailed explaination should be provided in response body