Web Lexicon

Home » Web Lexicon » Web Scripting


Scripting is the magical fairy dust that makes websites interactive. In the early days of the internet, websites were static HTML pages. The only interactivity was in the Hypertext links that took you to another static page. Soon after, forms were implemented into HTML and the Common Gateway Interface was developed which allowed programs to interpret information sent via the forms. These early programs were written on an adhoc basis, in high level programming languages not designed for the web. Later programming languages were developed specifically for the web, including Perl, PHP, Java and JavaScript.

Initially scripting was used for trivial purposes like changing images when hovered over with the mouse or page view counters. Today, scripting enhances the majority of websites with millions of eCommerce websites and social media juggernauts like Facebook and Twitter.

Scripting is essential for any of the following web applications:

Client Side & Server Side

Scripting can be divided into server side scripting and client side scripting. Client side scripts are executed on the client. The client is the device viewing the website. Server side scripts are executed on the server – the same server that provided the web page to you. Both modes of scripting go hand in hand, passing data to each other through web page loads and AJAX function calls.

Server Side

Server scripts run when the server responds to a request. Requests are received when:

  • Visitors navigates to a dynamic web page in their browser.
  • Client side scripts send a request programmatically via AJAX.
  • A separate server side script sends a request programmatically via data transfer tools like CURL.

The script looks at information in the request and constructs a suitable response. Sometimes the response will constitute a whole new web page to be viewed on the visitor’s browser, and other times the response will be a small chunk of data.

In most modern dynamic websites, the server side script fetches the information it needs to fulfil a request from a database. Server side scripts can add new information to the database, and/or edit and delete existing entries. Server side scripts are usually the main interface between the user and the database. The database structure and the server side code are usually developed hand in hand.

A typical use scenario for server side scripting would follow the chain of events below:

  1. Client requests web page for a product on an eCommerce website.
  2. Server side script receives the request and does the following:
    • Searches the database for the product and retrieves product information like price, description, title etc.
    • Loads template for a product page and fills in empty spaces in the template with product information to form a web page.
    • Send the completed web page to the client.
  3. Client receives customised HTML page and renders it on the screen as a web page.

Server side scripts are written in a variety of programming languages. At Phoenix Web Development, we mostly write server side scripts in PHP. Other server side scripting languages include ASP, Java and Perl.

This Upwork article contains additional information about server side scripting.

Client Side

Client side scripts are downloaded from the server to the web browser and then executed with the browser’s script engine. They are used to make changes to the user’s screen and send requests to the server for processing by a server side script. These operations are triggered by events. A few examples of events which function as triggers:

  • The page is loaded.
  • The user clicks or presses certain elements.
  • Timers.
  • The user scrolls to a certain part of the page

To change the user’s screen, the client side script interacts with and manipulates the HTML on the page and/or changes how elements look by changing the CSS. To make requests to the server, the client side script uses AJAX technology.

A typical use case scenario for a client side script would be the following:

  1. Administrator clicks a button to delete a user from a table of users in an admin interface.
  2. Using AJAX, the client side script sends a request to the server side script to delete that user.
  3. Server side script deletes user from database and replies with a response to inform the client the deletion was successful.
  4. Client side script reads the response and informs the user the deletion was successful with feedback on the interface. Alternatives include deleting the row of the table corresponding to the user – preferably with an attention-grabbing animation or showing a pop-up message.

Client side scripts runs faster than server side scripts, as they do not have to wait for a HTTP request to be sent and received. This makes operating an interface seem more seamless for the user. For this reason, functionality that could run on either server or client, is moved to the client whenever possible.

Today virtually all client side scripting is written in JavaScript. JavaScript established inertia early on when it became the first client side scripting language to be utilised across all web browsers.

Good Practices

Writing scripts that meet the needs of a specific business scenario is the bread and butter of web agencies like Phoenix Web Development. Over the history of the web, several good practices have emerged that should be adhered to. Just a few include:

  • Don’t go willy-nilly with the scripting. Scripts slow down the loading of a website while downloading. They should be used only when necessary.
  • Extend existing software whenever possible. Don’t build new programs from scratch.
  • Ensure your scripts are secure. Web scripting opens websites to all sorts of mischief. Because they respond to requests, the requests can be tailored to attack. Web developers must guard against attacks like cross site scripting, SQL injection, code injection, good ‘ol data breaches and more.

Read More

Read more about web scripting at these resources:

Search Site
Phoenix News Desk

Please note that we are currently unable to take on new client projects due to filled capacity.

Back to top