Web Applications

Web applications are (more or less) sophisticated systems which are interacted with (mostly) through internet browsers. You can look at the web browser and the internet itself as on an execution environment of web applications. The HTTP protocol is used to transport data between the client and the server. These data also contain chunks of code that is interpreted on the client-side – JavaScript.

Web application do not need to be installed on visitors computer, all he need is a web browser. This makes them very accessible. On the other hand, they cannot use full functionality of a computer unless the browser allows it.

They are usually written in multiple programming languages which differ between backend and frontend. There is actually no given technique to develop web application properly, there are some best practices but they are sometimes contradictory or apply only in certain conditions. Even more challenging is the amount of frameworks and tools that you can use to develop a web application.

This article is a general overview of forms of web applications which should help you to distinguish development approaches and their suitability for different task.

Backend

The “backend” is a word that describes everything that runs on the server or often on many servers. This is a vast thing that cannot be generally described in one article. Servers are under control of developers/administrators and can contain anything – applications, data, services, special hardware etc.

That anytning can be written in arbitrary programming language and a user of web application can merely guess what is going on there. But usually he does not care very much.

The backend is a collection of functions responsible for data manipulation, business logic of application, security, communication with other services or applications and delivery of HTML, CSS and JavaScript to the visitors’ web browser.

In this book I use PHP as the programming language. PHP is very popular for its simplicity, but for even bigger programmer convenience, there are a lot of frameworks which can be used to develop web application – in this book I choose Slim framework.

Database

There is usually some database running on the server. The use of specialized software for data storage is beneficial because the developer of a web application needs to focus on its functionality, not on technical details of data storage. Another great advantage is universal and documented interface of the database which means that other applications can access your data if needed. But again, the choice of database system is arbitrary.

Frontend

The frontend is what the visitor sees in his web browser. It is usually a website which is presented to the visitor using HTML and CSS technologies and some media content. Nowadays usually enriched with JavaScript which makes frontend an application of its own kind.

There are many ways to develop a frontend, but the result of all effort is always rendering of HTML, CSS and media to some graphical form in a web browser. Nevertheless, the HTML code that is rendered can be a static file downloaded from a server or generated by some script or templating engine or even fully generated in backend code. Here is a short excerpt from Nette framework’s documentation which defines a form component that is used to render a registration form:

function createComponentRegistrationForm() {
    $form = new UI\Form;
    $form->addText('name', 'Name:');
    $form->addPassword('password', 'Password:');
    $form->addSubmit('login', 'Register');
    $form->onSuccess[] = [$this, 'registrationFormSucceeded'];
    return $form;
}

The process which is used to generate HTML can differ, but the outcome that has to be delivered to the browser is much more standardized (HTML, CSS, JavaScript). Frontend has rules given by developers of web browsers and must obey them. Still the process of developing a frontend of an application is not easy because there are countless ways how to achieve the same result (as with any programming assignment).

Classes of web applications

In the beginning, there were only web sites. Those were mere static HTML files and they allowed no interaction at all. HTML files were handwritten or generated by a WYSIWYG editor. There are also systems which allow sophisticated generation of HTML files from given rules (this book is written using one of them – Jekyll). Another example is build-in function of many image viewers for static HTML gallery generation etc.

Web site/page becomes a web application in the moment when it allows some level of interaction (it is not read only). As any other industry, the web also evolved in last two decades. Following list tries to summarize approaches to web application development. Even nowadays you can choose among these different approaches according to your assignment, skills and budget.

Classical web applications – form based

This kind of applications accumulate all application logic in the backend. The browser is used only to render HTML code, which is generated using a templating engine or programmatically generated, and some media content and CSS. This kind of application relies on the most basic standards that are implemented in browsers and everything that a user does is interpreted in backend code. It means that every action of a user means a full reload of a page. JavaScript is used only for basic confirmations of actions or not at all. Application is based on forms and standards mechanisms in browser are used to submit them.

This kind of web applications is usually produced by programmers without frontend skills. They try to avoid technologies like JavaScript and CSS or they use some kind of ancient backend framework. There is no much difference between a static page and this kind of application from the browser’s point of view, just that the HTML files are generated on demand.

Advantages Disadvantages
Almost 100% reliable in all web browsers State management issues
Low expectations of client capabilities Slow and heavyweight

Such application is developed usually in a backend framework (not necessarily PHP) and it uses a templating engine. It is a basic type of application suitable for any purpose but very limited.

…with bits of JavaScript

To overcome most simple interactivity problems, developers use tiny bits of JavaScript to make application usage a bit more interactive. JavaScript usage is limited to confirmation dialogs or simple hide/show toggles often collected from online discussion boards.

Rich internet applications (RIA)

This kind of applications started to appear with the rise of users’ appetite for more interaction and more functions. The definition says that this applications has characteristics of desktop application. RIA is opposite of classical web application. It allows the visitors to work without interruptions from long reloading and it does a lot of work on the client-side.

RIA based on plugins or applets

First RIAs were realised using Java or Flash plugins and you can still encounter apps like this (there also was Shockwave or Silverlight technologies). The HTML file defined a place where the plugin should open and pointed to a downloadable compiled piece of code which the plugin executed. It required some kind of application runtime environment to be installed on the computer beforehand.

None of these runtime environments were created by web browser developers and it was user’s responsibility to install and maintain them on his computer. They were used to extend missing functions of web browsers like playing videos and/or audios, vector graphics, 3D rendering, games, interaction with hardware like microphone or webcam and many others. None of the runtime environments became a real standard and because of sloppy implementation and the need to support multiple web browsers, they were buggy and dangerous. Nowadays browsers have standardized JavaScript APIs functions which are needed by RIA developers and most runtime plugins are banned from installing. On the other hand, there were/are some good IDEs for development of plugins and applets (these projects now allow “compilation” into JavaScript).

Advantages Disadvantages
Easier development of plugins using an IDE Security issues
Overcome browser limitations (formerly) Need to install and maintain 3rd party software
Ability to use special hardware Runtime incompatibility issues

Thanks to extended capabilities of JavaScript and due to browser security policies restrictions, it is not a clever idea to develop any applications this way.

RIA based on JavaScript

In the end of this century’s first decade, the advancing JavaScript standardization among browsers and availability of facade libraries, that speeded up the development process, allowed developers to abandon technologies like Flash or Java applets and write RIA in pure JavaScript.

The most difficult decision for every web developer is where to draw the line between backend and the frontend. What should one render using backend templates and what should be the visitor allowed to do without page reload using JavaScript functionality? This kind of RIA uses JavaScript mainly for visitor convenience – it tries to replace full reloads of page with partial redraws when user changes the state of application (e.g. insert a product into a shopping cart) but most of the application logic is still in the backend.

The main characteristic that can define the difference between this kind of RIA and following one, from visitor’s perspective, can be the need to reload the page from time to time. The reload means that the unique state created by visitor by his actions is lost forever.

Another usual characteristics of this kind of SPA is that server still renders HTML using templates but only those parts of HTML code that need to be redrawn are transported to client using asynchronous HTTP requests in the background.

Advantages Disadvantages
Much more usable web application Difficult to design and implement
Using native JavaScript Occasionally need to implement same functionality in backend and frontend

Most of these applications use jQuery or similar library and a framework in the backend.

Single page applications (RIA-SPA)

This approach exploits JavaScript’s DOM interface to modify the structure of current HTML code. With JavaScript, you can control every element in the current page. You can even remove them or create new ones. You can say, that you want to completely replace rendered content with something different without a reload. With new JavaScript’s APIs, you can even control the content of address bar and you can also persist information locally between app executions (maintain state). You can do all of this even with previously described RIA approach, the main difference for SPA is evident division between backend and frontend.

SPA is a new level of web application. It is a standalone application that is executed in your browser completely driven by JavaScript. It has to be stored on a server, but usually as mere static files (containing JavaScript, unparsed HTML templates and media). When a web browser downloads these files, it executes the JavaScript code and the application now runs until you close the browser’s tab or window. Everything the user does is interpreted with JavaScript which tells the browser what to do. It can send asynchronous HTTP request in the background and create or remove some HTML elements as response to user action. These applications use familiar templating with control structures and variable substitution, but templates are interpreted on the client. Thanks to this, templates can reflect changes of data and propagate them into DOM.

The backend of such application also contains business and security logic, but the style of communication is different: instead of sending HTML code, the client and server communicate with each other using JSON or XML data format. Such messages are interpreted and both application react somehow. This kind of communication interface is called REST.

You should see now that the backend and the frontend are two standalone applications that communicate with each other using a defined and documented interface. This is convenient for developers, because backend specialists do not need to worry about HTML, CSS and JavaScript and frontend specialist do not need to worry about whatever programming language is used in the backend and about the database. It also means that frontend developer is no longer somebody who knows how to code HTML and CSS, this approach lays much more responsibility on frontend developers as they now develop a full-fledged application.

As the backend now holds only business and data logic wrapped in an API, you can use it from other applications than your SPA frontend – similarly as you can use same database from multiple applications, only that your API is much more specific. Another kind of frontend can be native mobile client for Android or iOS which also likes to communicate with backend in JSON or XML messages.

Many frameworks are available to help you developing SPAs but once you choose a framework, you cannot change it unless you want to rewrite whole application.

Advantages Disadvantages
Richer user experience, almost like desktop application Need to implement full-fledged frontend application
Many frameworks available Vendor lock-in
Division of responsibility  

Most used frameworks for frontend:

You can use any modern framework capable of handling JSON or XML requests and GET, POST, PUT and DELETE routes to implement API in the backend. You do not require templating engine to be present in backend.

Other RIA flavours

Along with development of new browser capabilities and tooling, we can observe two new application categories related to web applications.

Hybrid application

Hybrid applications is an SPA wrapped into native packaging for Android or iOS which acts like any mobile application. That native wrapper is basically a web-view which executes your JavaScript (web-view is basically a browser without navigation bar). You can mock look and feel of given host OS using CSS. Source codes (JavaScript, HTML templates and media) are not stored on web server, but in that native package which makes the application available even offline.

The main advantage is shared source code between web SPA and native application. This makes the application much cheaper to develop and maintain, but also creates some limitations. Native wrapper can allow you to access some hardware functions of the cellphone.

Tools to wrap your SPA into native package:

Hybrid application frameworks:

  • Ionic
  • NativeScript – focuses on mobile application development using web technologies

Progressive web application (PWA)

PWAs are web application which use capabilities of modern browsers installed in mobile devices to act similarly like native application. Difference between PWA and hybrid application is that PWAs are still web applications running in a browser from a web server, but they can behave similarly to native application (i.e. you can have desktop icon for PWA).

Summary

This article is an overview of web applications forms. You should be able to classify a web application based on its behaviour (full reloads VS no visible reloads), its architecture (monolithic VS separate backend and frontend) or its capabilities (form based application VS asynchronous communication).

Another story is to tell which approach to use for a new application – this depends on the character of assignment. A rule of thumb is to use classical approach (backend framework with templating engine) for presentations and e-commerce applications and RIA-SPA approach for applications with high user interaction (e.g. an application which a user will use very intensively – it does not mean that the user has to spend a lot of time in the application, more likely he will interact with it a lot).

New Concepts and Terms

  • rich internet application – RIA
  • single page application – SPA
  • progressive web application – PWA