The Evolution of Web Forms Part-1 — From Plain HTML to AJAX Modern React forms can feel unnecessarily complicated when you first encounter tools such as React Hook Form, Zod, resolvers, controlled inputs, refs, , and server-error handling.
Why do we need all of that?
Why not simply read the value from an input and send it to the server?
To understand why modern form libraries exist, we need to understand the problems developers faced before those libraries were created.
In this series, we will evolve the same idea step by step: This first part covers the first four stages: Plain HTML forms Native HTML validation Vanilla JavaScript validation AJAX form submission By the end, you will understand how forms worked before React and why each new approach became necessary.
Stage 1: Plain HTML Forms Before React, AJAX, or even large amounts of client-side JavaScript, browsers already knew how to submit forms.
HTML forms are not just visual containers.
They are a built-in browser mechanism for collecting data and sending an HTTP request.
A basic registration form There is no JavaScript in this example.
The browser handles the entire submission process.
Understanding the element The element groups fields that belong to one submission.
The two most important attributes are: The attribute The tells the browser where the form data should be sent.
In this example, the browser sends the request to: If the website is running at: the complete request URL becomes: The may also contain a complete URL: The attribute The tells the browser which HTTP method to use.
The two methods traditionally supported by HTML forms are: GET form If the user enters: the browser navigates to something similar to: The data becomes part of the URL.
GET is commonly used for: Search forms Filters Pagination Read-only operations Shareable URLs Sensitive information should not be sent through query parameters.
Never send passwords using a GET form.
POST form POST sends the data in the HTTP request body instead of placing it in the URL.
POST is commonly used for: Registration Login Creating resources Uploading files Submitting private information Using POST does not automatically encrypt the data.
HTTPS is still required.
The importance of the attribute Consider this input: The identifies the input inside the HTML document.
The identifies the field during form submission.
When the browser submits the form, it creates key-value pairs using the attributes.
Without a , the browser usually does not include the input in the submitted form data.
For example: This field can appear on the screen, but its value will not be submitted as part of the normal browser form request.
This distinction is important: Understanding The label's value matches the input's .
This association provides two important benefits.
Mouse and touch usability Clicking the label focuses the input.
Accessibility Screen readers can identify the input as an email field with the label “Email.” Avoid building forms using placeholder text as the only label.
Bad: Better: A placeholder is an example or hint.
It should not replace a label.
Understanding the submit button A button with tells the browser to submit its associated form.
Inside a form, a button may behave as a submit button even when its type is omitted.
However, relying on the default can create accidental submissions.
It is better to be explicit: For buttons that should not submit the form, use: What happens after clicking Submit?
Suppose the user enters: Then the user clicks Register.
The browser performs approximately the following steps: The request may look conceptually like this: The default encoding is commonly: This means form values are encoded into key-value pairs.
Why does the page refresh?
Traditional form submission is also a browser navigation.
The browser sends the request and expects the server to return the next page.
For example: The server might redirect the user: The browser then requests and displays the login page.
This is sometimes called the traditional multi-page application model.
Each important interaction can result in a new page request.
Complete working example Create the following structure: Install and run Open: After submission, notice that: The browser sends a POST request.
The server receives the form fields.
The browser leaves the registration page.
The browser displays the HTML returned by the server.
Advantages of plain HTML forms Work without JavaScript Built directly into browsers Simple to understand Good accessibility when correctly structured Can function on slow devices Support keyboard submission Easy for search engines and assistive technology to understand Useful as a progressive-enhancement foundation Disadvantages of plain HTML forms The page navigates or refreshes after submission There is little control over the user experience Validation depends mainly on the server Error messages often require rendering another page Preserving entered values after a server error requires additional work Loading states are difficult to display without JavaScript Complex interactions are difficult to implement Common beginner mistakes Forgetting The field may not be included in the submitted request.
Using GET for passwords This can expose the password in URLs, browser history, analytics, logs, and server records.
Using placeholders instead of labels Placeholder text disappears when the user starts typing and is not a proper replacement for a visible label.
Forgetting the button type A button intended to toggle password visibility may accidentally submit the form.
Security note A form is not secure merely because it uses .
Production forms should also consider: HTTPS Server-side validation Password hashing CSRF protection where applicable Rate limiting Input sanitization where appropriate Secure cookies Authentication and authorization Protection against automated abuse Never trust data only because it came from an HTML form.
Interview question What is the difference between and in an input? identifies the HTML element and connects it to labels or accessibility attributes. determines the key used when the browser submits the form.
The server receives: It does not receive: Why this evolved Plain HTML forms could submit data reliably, but users could enter completely invalid information.
Developers needed a way to catch basic mistakes before sending the request to the server.
This led to native HTML validation.
Stage 2: Native HTML Validation Imagine a registration form where the user submits: Without validation, the browser sends this data to the server.
The server then needs to reject it and return an error response.
This creates unnecessary work: Browsers introduced validation attributes that allow developers to describe basic input rules directly in HTML.
The attribute The browser prevents form submission when the field is empty.
This is a boolean attribute.
It does not need: Although that may work, the standard shorthand is simply: and This means the username should contain between 3 and 20 characters.
For passwords: can also prevent the user from entering more characters.
The attribute The attribute applies a regular-expression rule.
This accepts: It rejects values containing spaces or unsupported symbols.
A more complete example: The provides additional guidance that some browsers may include in their validation message.
Do not use complicated regular expressions when a clearer validation strategy is available.
Email input The browser checks whether the value resembles an email address.
It may reject: However, this check is intentionally basic.
It cannot determine whether: The domain exists The mailbox exists The user owns the email address The email is already registered Email verification and server-side uniqueness checks are still required.
Number input This field accepts numeric input and applies minimum and maximum rules.
Do not assume is correct for every value containing digits.
Phone numbers, PIN codes, postal codes, Aadhaar-li