Web frameworks – overview and classification

More and more desktop applications are appearing throughout the internet. They are available to users in the form of web applications via the browser. Classic examples are web mailers and browser games. Software-as-a-service has also established itself as a licensing model in a business context. There are web applications for customer relationship management, product management, newsletters, project planning, employee time and attendance recording, and financial accounting. Small businesses in particular benefit from demand-oriented billing models and a central position online. This reduces the costs for maintenance and administration and offers maximum flexibility through platform and device independence.

When developing web applications, programmers generally resort to web frameworks. But what is a framework? And what makes a framework specific to web applications?

 A framework is a program structure that is used as a basis for software development. If a developer wants to create new software, it makes no sense to start from scratch each time. Numerous standard functions in software development offer tried and tested solutions in the form of program codes. In object-oriented programming, classes are usually used and these act as blueprints for developing software objects. A framework usually represents a collection of different cooperating classes and thus determines the basic design structure of any software developed on the basic of the framework. If a framework is used as a basis for a web application, it is referred to as a web application framework (abbreviated to web framework).

As a foundation for software development, web frameworks should provide a simple, clear structures that is easy to maintain and allows developers to create powerful web applications in a short space of time. In order to fulfil this aim many web frameworks rely on three basic design principles:

• Don’t repeat yourself (DRY): the motto don’t repeat yourself aims to avoid redundancy in the context of software development. Redundant information such as code duplicates should be avoided since they have a negative impact on the maintenance of the software: if redundant sections of code need to be adapted, changes must be made at different points in the program code.

• Keep it short and simple (KISS): one problem, one solution. This is the basic principle of the KISS idea. It’s based on the principle of parsimony (economy principle): if there are several approaches to a solution, you should choose the solution with the least assumptions and variables. In order to use a framework or to fix a specific problem, as little code as possible should be used.

• Convention over configuration: the more configuration there is, the more complex the operation. Conventions, on the other hand, provide a way to reduce complexity. Therefore, web frameworks should provide the best approaches in their default settings, and optionally offer additional customization options.

If these design principles are taken into account, using web frameworks in software development offers numerous advantages. The framework specifications also limit developers. These structural limitations are sometimes viewed as a disadvantage.

Web frameworks are used to reduce time and cost of software development since codes are basically re-used. This mainly refers to basic features such as database connections, website templates, caching methods, and security features that are provided by frameworks as prefabricated code modules. Thus, the development effort is limited to the specific program code of a new web application. Since most web frameworks are offered as free software, there are usually no purchase costs.

In addition, frameworks promote the generation of clean source codes, since developers can rely on tried and tested building blocks for standard features. The program components provided by frameworks usually go through numerous development cycles and are continuously optimized. Those in the community act as testers and co-developers. This way, security gaps in new components are quickly found in large projects and rectified. Users and developers converse in forums dedicated to the project with some of these being moderated by support teams.

The web contains an almost unmanageable number of frameworks for web development. These differ in basic design principles as well as in the features they offer. Different software projects may therefore require the use of different web frameworks. Developers are faced with the problem of selecting the appropriate framework for the intended project. There are quick-fix compromises, in which the intended software project is adapted to the framework’s limits. Since frameworks are designed as universal solutions, developers rarely use all the features of a given structure. Depending on the scope of the framework, an application may contain more code than necessary.

In addition, the dependency in the respective web framework is seen as disadvantageous by the developer. In individual cases, using a framework is linked to specific license terms, which can be problematic when any further development of the framework is stopped. Since developers have to familiarize themselves with the structure of the respective program framework and the usage possibilities, they need time to adapt. Luckily ready-made features and code snippets save some time. Critics acknowledge that there’s the risk of basic knowledge becoming lost. Users who only program on the basis of frameworks may deal less frequently with programming languages.

Since the source code of most web frameworks is freely accessible, everyone has the opportunity to get acquainted with it. If applications are developed for company use based on publicly available code components, they may be more transparent to hackers than apps whose source code isn’t public.

Just like the case with frameworks in general, web application frameworks are also defined by program libraries and web development tools. While libraries provide only individual features a framework can be viewed as an interactive program framework for standard procedures – like a semi-complete application.

The central basic components of a software framework constitute cooperating classes with associated methods. These are code blocks that describe the properties of software objects and their behavior. Some of these components are static and therefore invariable. Others can be adapted by the user e.g. by overwriting methods. This allows the program structure to be adapted to a specific task. The term 'hot spots' was established to refer to a framework’s flexible components. The static components are called 'frozen spots'.

Web frameworks generally follow the concept of inversion of control (IoC). This is an abstract principle describing an aspect of some software architecture designs in which the flow of control of systems is inverted, unlike the case with procedural programming.

In simple terms, IoC means that the responsibility for program execution does not lie with individual components, which are developed and carried out on the basis of frameworks, but with the framework itself. This takes over the function of the main application that coordinates the flow of control. Further components, which are implemented and registered by the user in the framework, are available to the user when required.

In order to perform this centralized control function, web frameworks offer a special interface that must be implemented by all components regarding the structure. Through this design principle, the framework is ready at all times to move resulting components and implement callback methods. These also enable the framework to inject information into the components as needed, or to trigger a specific behavior through method calls. While classes and their dependencies are hard-coded in classical approaches in software development and are therefore already defined during the compilation, the inversion of control concept enables a software to create objects dynamically during the period.

In software development, IoC possesses the status of a general design concept. This is applied by design patterns such as Dependency Injection (DI) and Dependency Lookup.

The majority of all web application frameworks are based on an architectural pattern called the Model View Controller (MVC). This is a strict separation of application logic and presentation layer and divides software into three areas: model (data model), view (presentation), and controller (program control).

• Data model: the model is the section of a framework that contains the data to be displayed as well as the application logic and rules. Data retrieval and change requests are processed by the methods provided for this purpose.

• Presentation: the basic task of view is to display the data provided by the model. For this purpose, the view makes inquiries on the state of the model via through different methods and is informed of any changes. Another task of the view to receive user input (keyboard strokes, mouse clicks) and then forward them to the controller.

• Program control: the controller acts as an interface between the model and the view. To do this, it manages one or several views, evaluates user input and reacts accordingly e.g. by passing data to the model or by making changes to the view.

The aim of the MVC architecture pattern is to achieve a flexible program design. Separating the application logic and presentation layer should mean that it’s easier to make changes later on as well as adding extensions and reusing individual components. This reduces the amount of programming required to adapt software to different platforms (Windows, Mac, Linux) or as a web application, since only the controller and the view have to be adapted accordingly.

In the form of JSP (Java Script Pages) model 2, a design model based on MVC is also used in Java-based web frameworks. A JSP page corresponds to the view, servlets to the controller, and Java Bean to the model.

The market for web applications is very diverse. Apps that are available to users via the browser don’t just differ in size and appearance, but also in software design, depending on the application and range of functions. The reason for this is the variety of available web frameworks, which are based on different technologies and follow different approaches in software design. It’s possible to compare single and multi-page approaches, server-centric and client-centric approaches as well as web frameworks, which are action-based or component-based.

Multi-page applications consist of several HTML pages, which are usually opened by entering the respective URL into the browser, and they are connected using hyperlinks. The user interface of a single-page application, on the other hand, consists only of an HTML page, on which all user inputs are made. This can be divided by panels, tabs, or registration cards. The URL of a single-page application does not change within the scope of the navigation.

The programming model of a classic web application corresponds to that of the World Wide Web whose architecture is characterized by the Hypertext Transfer Protocol (HTTP). If a user accesses a web application, it means that one or more servers and a client program (usually a web browser) are involved in each case. Depending on how the communication between server and client is designed, they are known as server centric or client centric applications.

• Client centric: if an entire HTML user interface (including application logic) is loaded on the client when the computer is started, this is known as a client centric application. Changes to the interface due to user input are implemented in this case by client-side programming languages such as JavaScript. A design approach like this is recommended for apps where users work in the same view over a long period of time because only the data displayed on the user interface is reloaded by the server. The client-side approach is primarily used in the development of single-page apps and is supported by JavaScript frameworks such as Angular JS or EmberJS.

• Server centric: for server centric applications, the application logic remains on the server that creates the user interface and delivers it to clients for the presentation. For changes to the user interface, server-side programming languages are available and the development is largely independent of client-side uncertainties. This approach is typically used in multi-page apps where the various views are retrieved from the server. A software design like this is associated with longer loading times, but reduces the computing effort on the client device. Some apps avoid swapping the control logic due to security reasons. Implementing the server centric approach can be found with Django, Zend, and Ruby on Rails frameworks, for example.

A server centric programming approach is found mainly in frameworks that have been developed to create classic web applications with a multi-page structure and a classical HTML interface. Only the interface is displayed in the web application and generally uses browser navigation. Web apps of this kind can be run independently of the operating system or web browser. The control logic is processed via the HTML-typical request/response communication from the server.

Client centric web applications are sometimes referred to as Rich Clients or Rich Internet Applications (RIA). The user interface implements this kind of application on the client. These are usually loaded when the computer is started. In contrast to classic web applications, a client centric approach can be used to implement features such as drag and drop management, offline availability, and hard-drive access, which are more familiar with desktop applications.

At the application control level, web frameworks can be divided into two classes. While action-based web frameworks consistently display the HTTP-related request-response pattern, it is abstracted in component-based web frameworks.

Action-based web frameworks: when it comes to action-based frameworks, the controller serves as a central instance that accepts client requests, validates them, and triggers a suitable action. For each possible action, the app developer must first create a software object that contains the appropriate application logic. This can usually be derived from abstract classes. If the action has been executed, the controller updates the data model and forwards the result to the view, which in turn creates the response and sends it back to the client.

Action-based web frameworks lean strongly towards the MVC pattern and are also referred to as request-based because of the request-response pattern’s strict implementation. Classic representatives are:

• Django

• Ruby on Rails

• Symfony

• Spring MVC

• CodeIgniter

Since the possible actions of an action-based web framework are defined in detail by the app developer, it is referred to as a white box approach. This provides developers with great freedom, but requires a deeper understanding of the web framework since developers are responsible for creating HTML, CSS, and JavaScript.

Component-based web frameworks: unlike the action-driven approach, component-driven web frameworks abstract the HTTP-related request-response pattern by looking at the user interface of a web application as a collection of components. For each of these components, which are linked to software objects on the server side, specific reactions are defined during the development of the web application. These follow events triggered by a user interaction with the component. This is why event-controlled web frameworks are mentioned. Classic representatives are:

• Lift

• Apache Tapestry

• JavaServer Faces

• Apache Wicket

The basic idea behind the component-based approach is to group related actions together. For example, the component, AccountController, represents actions such as login, logout, or getAccount. A software object can therefore be responsible for several actions. Component-based web frameworks typically provide a large selection of reusable components that conceal details of the underlying request-response pattern from the app developer. In this context, this is known as a black box. Web frameworks of this type are therefore suitable for developers, who primarily want to rely on predefined components. Those that want more freedom regarding HTTP, HTML, CSS, and JavaScript are better off with an action-based web framework.

Since frameworks have a great influence on the features and design possibilities of the web application as well as on the workflow during development, the work process usually starts with selecting the appropriate program framework. On the one hand, the planned software project as well as previous knowledge should be considered.

Key questions relate to the type of application and the desired architecture (server centric, client centric). Both aspects have a direct impact on the operation and user-friendliness of web apps.

It is useful to already have existing coding language skills and for the required infrastructure to be available before you start searching for the appropriate web framework. There is a wide choice of well-documented web frameworks especially for well-known programming languages such as PHP (e.g. Zend, Symfony, CakePHP, and CodeIgniter), Java (e.g. JavaServer Faces or Apache Wicket) or Python (e.g Django). The popularity of Ruby in web development is mainly due to the popular Ruby on Rails web framework. Client centric web frameworks typically rely on the JavaScript scripting language.

Developers who have primarily programmed desktop applications in the past often have more difficulties orientating themselves within the request response pattern-oriented program model of action-based frameworks than classic web developers do.