Scripts Ruling the World
By Felipe Lodi
Imagine HTML as a limited (though big) set of commands that the Browsers are prepared to interpret and behave accordingly with the programmed mark-ups. As discussed before, there is no way to make HTML evolving and changing its behavior in response to users’ actions, system configuration or database content. HTML is static in the end when it reached the user’s browser, even though it might have been transformed milliseconds before.
This transformation is made by scripting languages and they happen either on the server-side or client-side. There are scripting languages that build HTML and there are scripting languages that transform existing HTML. The latter might be working on either dynamically created pages or static pages. Actually client-side scripting languages do not care how the pages they need to work with were created, as long as the HTML is well formed, they can do their job.
One of the most well-succeed scripting languages is the famous JavaScript. It is important to mention that despite of name and syntax similarity, Java and JavaScript are two completely different things. In the early 1990s when Internet was becoming popular there were basically two different Web browsers, Internet Explorer and Netscape Navigator. The latter was the first to identify that the Web pages would become interactive and they built a language called Livescript. (Chapman, n.d.)
Netscape had this embedded, and pages using this language did not need to be compiled. Users using this Browser were able to use pages developed using this language without having to install anything, differently that pages built in Java which required a plugin to be installed on the computer. What Netscape did was to take advantage of the name Java migrating Livescript to JavaScript. (Chapman, n.d.) That is just a brief history that also includes the beginnings of VBScript and Jscript, also good alternatives to client-side scripting languages.
It shows how important these scripting languages were and are to the user’s experience. Furthermore, not only end users’ experience at stake but businesses and the whole Internet concept and its evolution. The Web 2.0 for instance, would not be possible without scripting languages. Sharon Housley says on hers interesting article that in Web 2.0, “interactive content is the norm” and that the key components of the Web 2.0 are the Web itself, collaboration and syndication rather than power and complex web technologies. (Housley, n.d.)
I agree with her and I would say further that the collaboration is the strongest key. Imagine a user who wants to create his study workplace online. He first finds a (usually) free service that permits him creating an environment likewise his desk: File Cabinets, Calendars, Notepads and others tools. Scripting languages are already there on the Browser when he drags from the Web site’s tool box the desired component (e.g. File Cabinet) and drops onto the virtual desk. Then, after selecting all components he will need for his studying, he organizes his environment, putting the Calendar on the right, Notepads on the middle and File Cabinets on the left. Scripting languages are there too.
What the scripting languages do at this stage is transforming the former HTML page. This is more complex because the scripting languages also changes CSS properties dynamically at the client-side. For example, the coordinates and colors of his components are stored in helpful files called Cascade Style Sheets, that are responsible (in a well-developed Web site) for saving information regarding to positions, colors, borders, fonts and navigation amongst others.
On the other side, on the server-side, this information about his virtual desk is being saved on some sort of database (or perhaps XML files) to be properly retrieved every time he accesses the Web site. At that side, there is another role to be played by another scripting language. This coding will get the user’s information from the database, his used components, how he organized and configured them on the virtual desk and builds the HTML page to be delivered back to his Browser.
This HTML page, though built dynamically, has to keep working as it should, enabling all commands such as dragging and dropping. Therefore it has references to common client-side scripts saved on the server (meaning by “common” that all Web site users also share the same script files as they need the very same functionality). The pages are different, the users can configure as they want and save, but the functionality is common. For the sake of simplicity, they have the same enabled functionality.
Using only HTML would be impossible to build such Web site, such product. As illustrated, different scripting languages are used in different layers and steps to make this simple functionality. I do not see HTML doing this by itself. I cannot see how only HTML would, after identifying the user click, enable the dragging on the page. I cannot see either how only HTML would save the state of the page to be retrieved later.
HTML has though very important events to identify what the user wants to do. But this is the edge, I would say. After identifying what the user wants to do, HTML has to hand over to another powerful language, the scripting language. Whether only the client-side, server-side or both is a technical choice, but certainly scripts have to be there.
REFERENCES LIST
Chapman, S., n.d. A Brief History of Javascript. [Online] Available at: http://javascript.about.com/od/reference/a/history.htm [Accessed 19 March 2011].
Housley, S., n.d. What is Web 2.0? [Online] Available at: http://www.rss-specifications.com/what-is-web-2.htm [Accessed 19 March 2011].