The Internet revolution has completely changed society in so many ways, it’s difficult to list them all.
Before the Internet, reading the news was either about watching the evening news on television or waiting for the paperboy to throw the daily edition of a NEWSPAPER on your doorstep (or more likely in your lawn or hedges).
Now news is in your face 24/7 delivered instantaneously on your mobile smartphone just about as soon as a newsworthy event happens.
We can also thank the HTML (Hypertext Markup Language) standard for making it possible for any computer or mobil device in the world to use to create eye pleasing websites and useful internet applications.
The beauty and power of HTML based applications are twofold.
- Easy to update
- Easy to deploy
- Platform independent
An HTML based internet application uses a client/server architecture. Client/Server architecture revolves around the basic concept of a request and a response.
When you fire up your favorite web browser and navigate to an internet address, you are making a REQUEST to the web server where all the HTML related files, images, stylesheets and server code live.
The web server takes your request, finds all the corresponding HTML related files that make up your request, and returns an HTML RESPONSE back to your browser.
When you boil it down, that’s all there really is to an HTML based application.
When you want to change or add functionality to your HTML application, you make your changes to your code files, re-upload them to the server, and the moment they are uploaded, the next time any person make a new browser request to your application, they INSTANTLY see all your changes.
Even if your website has millions or billions of visitors, they all see your changes, as soon as you upload them to your web server.
HTML applications are also platform independent. The means that pretty much any computer, tablet device or smart phone of any variety, can run your HTML application as long as it can run a web browser.
It’s probably one of the number one reasons why web application development has become the dominant form of modern software development.
Before the advent and rise of the Internet, deploying applications to your customers, was a major and royal pain.
Back at the start of my professional software developer career, I developed client/server desktop based applications.
If I wanted to deploy my desktop application, I would often have to PHYSICALLY WALK to the customer’s computer to help install my application on their computer.
Boo hoo, right?
Ok, definitely not the Iron Man marathon. But that’s just one customer.
Now multiply that by the total number of users who wish to use your application. Given enough users, suddenly your whole day is filled with nothing but roving around your work campus either installing applications for new customers or updating your application, whenever you need to make a new version of your application.
It’s one of the reasons, I believe, internet application development took off the way it did. It pretty much eliminated the hassle and headaches of software deployment.
Back in the early days of the internet, that was good enough.
But internet applications have some serious shortcomings that every web developer quickly learns.
While internet applications have nicely solved the tedium and hassle of deployment, they have introduced new problem which continue to plague web application developers even today.
As previously mentioned, web applications operate under a client/server architecture. All of us web browser users are the clients. The destination internet address represents the server.
We browser users represent the REQUEST. What we get back from the browser once it finished loading the contents of our web page, represents the RESPONSE.
REQUEST. RESPONSE.
Repeated over and over, thousands, hundreds of thousands, millions of times. High traffic websites like EBay and Amazon operate under this architecture, but at the cost of requiring massive “web farms”, that consist of hundreds, if not thousands of computer servers, which help to spread the high traffic load of user client requests, much in the same way that high traffic restaurants have large staff of waiters and waitresses to handle their large number of customers.
This is the price to pay for enterprise level internet applications … a requirement of expensive hardware, not to mention an army of knowledgeable staff who know how to deal with the extensive requirements of such high traffic websites.
Probably the biggest problem that internet application development introduces is the problem of STATELESSNESS.
As described before, when I type in a web address into my web browser and hit ENTER, the browser makes an HTML request to the web server located at the web address I just typed into the browser.
The browser intercepts my HTML request, and formulates the appropriate HTML response and back it returns to my web browser application.
Request. Response.
When you make another visit to the same internet address, the web server belonging to that internet address, serves up another HTML response to your browser.
But it has no “recollection” of your first request. In essence, by default, a web server only thinks about one thing, responding to HTML requests.
More importantly, it doesn’t keep track, nor “cares” who made the request.
This is what the concept of STATELESSNESS means.
This poses a problem for many kinds of web applications, especially e-commerce and banking related websites.
Say you want to check the status of your bank account online through your bank’s main website.
You fire up your trusty browser and enter in the internet address of your particular bank.
If, by default, a web server has no idea who is making an HTML request, this creates a problem.
Say you want to navigate to different sections of your online bank account. Maybe first you want to visit the account balance page of your bank account before you do anything else.
Then, after sure you have sufficient funds, you wish to make a bank transfer to one of your other accounts.
A web server would have to keep track of every single request you make to itself and verify it is truly YOU that is making this request, and not somebody else.
After all, you don’t want any person off the street the ability to trounce around in your personal online banking account, would you?
The same goes for ordering stuff online. Say you want to purchase a bunch of stuff on Amazon.com
The same principle applies. You want Amazon to only allow you to navigate around through their online catalog and only allow YOU to make online purchases.
As a web developer, interested in providing this kind of rich functionality, you are in essence, fighting against the stateless nature of how web pages work.
There are mechanisms you can use to help internet applications remember who you are, across multiple HTML requests to the same web server.
Mechanisms like html cookies, querystrings and session objects.
But that kind of functionality doesn’t come for free.
Client desktop applications, on the other hand, don’t have the problem of statelessness. A client application remembers who you are by default.
And as the name suggests, internet based applications require an active internet connection to properly work.
Client desktop based applications, if designed properly, can theoretically work without an internet connection … for example, I don’t need an internet connection to be able to use Microsoft Office properly.
Native applications can also fully take advantage of a computer’s processing power.
You might recall that Facebook’s CEO, Mark Zuckerberg, initially tried to build their mobile smartphone version of Facebook as an HTML based internet application.
In other words, all you had to do was fire up whatever web browser came on your smartphone, and point it to Facebook’s address.
That HTML experiment didn’t last very long. The mobile version lacked the responsiveness and speediness that native applications could provide.
Mark Zuckerberg ordered his staff to create fully native apps for each major smartphone ecosystem out there, iOS, Android, and Windows mobile.
HTML is continuing to improve and I have no doubt HTML based applications will continue to improve and be able to better harness the underlying processing power of the devices they run under.
But I doubt native app development will ever go away. The advantage of statefulness and better responsiveness are powerful advantages that any developer should think twice about taking advantage before automatically assuming web development should always be the way to go.
