✨ Actions Before JavaScript

Web has been around since the 90s. The web we use and love nowadays is so different than when it started it is bonkers how powerful, easy and rich it has gotten.

Today we have complex, rich and interactive UI patterns, we have multi step forms user can fill at anytime and abandon it in the middle and when they come back everything is in place, even without storing them on the server.

Now mind you this was not the case when HTML was a new born technology.

Navigation

One of the few actions one could do on Web was navigating, it's when a user clicks an anchor tag, and the browser navigates the user to the URL pointed by the anchor tag, it looked like:

<a href="/news?filter=today">Today's News</a>

Note: the link above assumes we're on a website, so the href attribute is a relative URL, browser knows how to figure out the whole URL.

Link is usually used to refer to an anchor tag.

navigation: is when browser changes the URL in the URL bar and it starts sending a new request to that URL, hence starts fetching the new document and any of it's resources and replaces currently open document.

When you type a URL in the URL bar and submit it, browsers send a GET http request to the server. A GET request, doesn't carry any additional info, it only knows about the URL you typed. Clicking an anchor tag is the same, except, users use one key tap or mouse click and browser knows how to change the URL on your behalf.

You can navigate for so long until you hit your first need for user input, they have to create accounts, sign in to their accounts, fill forms and so on.

Submission

A form is a anchor tag with superpowers. One of the superpowers it has, it can dictate the HTTP request method using the method attribute.

Also with forms we don't use href attribute, instead we use action attribute which dictates a URL the browser needs to send the request to.

For example, this form has the same behavior as the anchor tag example you saw above:

<form method="GET" action="/news?filter=today">
  <button type="submit">Today's News</button>
</form>

But, with forms we can do even more, for example say user wants to choose between last month, this week or today's news, how can we change the filter search parameter?

We can use radio button inputs for that, we give user 3 choices, since the inputs have the same name, user can choose only one of them and submit.

I should mention that, when the method is GET/get the browser takes each input in the form with a name, and it's value and puts into the URL search params

Let's see the code for what we just discussed:

<form method="GET" action="/news">
  <label><input type="radio" name="filter" value="today" /> Today</label>
  <label
    ><input type="radio" name="filter" value="last_week" /> Last Week</label
  >
  <label
    ><input type="radio" name="filter" value="last_month" /> Last Month</label
  >
  <button type="submit">Filter News</button>
</form>

What if we want the user to not just filter buy duration, but also be able to search in the results, well we add an input with type="search".

We can add as many inputs as we want, as long as the URL length stays under the browser, which in Chrome is like 2K characters, in Firefox it's 65K, you should be fine.

Security & Privacy concern

Web is public, but it doesn't mean you shouldn't use everything at your disposal to keep user's privacy and their data secure.

As we've seen before, GET requests doesn't have body, it encodes it's data in the URL. Which means entities that have access to the request in the middle between your user's Browser and your Server, for example their and your Internet Service Provider, and any other computers in between, especially when you use someone else infrastructure, as most companies do.

Not everyone have the luxury to be able to maintain their own internet infrastructure, but that shouldn't be a compromise at the user's expense.

POST

Fortunately, Web has our backs here. A form can specify method="POST", this tells the browser to encode the form's data not in the URL as search params, but in a different format and instead it's put in the body of a request.

A standard HTTP request has 4 essential pieces, in that order:

  1. Method: In an HTML Form that is either GET or POST 1
  2. URL: Dictates the origin and the pathname to which the request should be sent
  3. Headers: These are additional information determining content type, encoding and compression among others
  4. Body: In POST requests, this contains the data that is needed to send to BE, it's content is determined by the name and values from the form inputs, and it's format is defined by the enctype attribute.

Mind you GET requests can't have a Body part, it's data is encoded in the URL as search params.

POST requests are significant for Web since their bodies can be encrypted using SSL/TLS so parties in the middle cannot figure out users data and information while it's transmitted between their browser heading to your servers.

That is why it's highly recommended you use HTTPS instead of HTTP, almost all hosting providers automatically assign an SSL/TLS certificate for you and renew it when it's expired.

So when users submit a Login form, that has their passwords in it, or they enter their Bank account, credit card info or their social security number, no one can obtain that information and steal their identity or impersonate them with any service provider.

Encoding Type

As mentioned, POST requests encode the data from the form, and using enctype attribute you can dictate what encoding you're using.

Make sure you assign a correct enctype that you expect it on your server or the API you're using.

There are possible values for this attribute:

  1. application/x-www-form-urlencoded: dictates that browser encode data using URL Encoding (aka Percent Encoding). This is the most efficient way of encoding and decoding, makes it easy for both Client and Server to parse and interpret the data. It's also the default value of enctype

  2. multipart/form-data: dictates that browser partition the values into multiple parts making it easier to for the network transmission.

    Use this when you have an input file in your form, files are binary data and URL encoding is not suitable, so this format suits better.

    Not recommended if you don't have file inputs as it adds overhead for browser to encode it and for servers to parse it.

  3. text/plain: dictates browser send data as it's values are appended after each other, makes data human readable, but it's not recommended

form submission

When a form is submitted depending on it's method attribute, two things happen.

If method="GET", the browser encodes the form input values into search params, and then navigates (changes URL at URL bar) to the formAction+search params.

GET is straightforward, it's almost like clicking an anchor tag in a sense.

But oh when method="POST", let's see what happens: 1. Browser gathers form input values, uses enctype attribute to encode the data. 2. Sends a POST request where the URL is determined by action attribute, it's body is the encoded data from step 1. 3. It waits for response of the request and navigates to a URL determined by action attribute unless the response status is: - If response status is No content 204 indicates a resource was created and the page stays as it is. - If the response is in Client Error 4xx or Server error 5xx range, the browser stays on the same page as well, and it you might need to show some error



And in case the server wants user on a different page other than what is in action attribute, it might respond with Redirection 3xx range and a Location header will provided.

This instructs the browser to navigate to the content of the Location header instead, which might be a relative or a full URL.

Before JavaScript

It's interesting how powerful the Web is even without JavaScript. Even though this is not enough for most of the application and website we build today as the expectations are raised as Web gets more powerful in all dimensions.

But we need to learn these technology sooner than later, since they're the fundamental parts of the web, anything else on top of it is a progressively enhanced change on top, but this is the bare minimum, I hope you have enjoyed this one.




Notes

There are HTTP methods other than GET and POST, but forms only support those two, but you can use others Using Fetching API if you have to.

webform