Web frame­works – overview and clas­si­fic­a­tion

More and more desktop ap­plic­a­tions are appearing over the internet. They are available to users in the form of web ap­plic­a­tions via the browser. Classic examples are web mailers and browser games. Software-as-a-service has also es­tab­lished itself as a licensing model in a business context. There are web ap­plic­a­tions for customer re­la­tion­ship man­age­ment, product man­age­ment, news­let­ters, project planning, employee time and at­tend­ance recording, and financial ac­count­ing. Small busi­nesses in par­tic­u­lar benefit from demand-oriented billing models and a central position online. This reduces the costs for main­ten­ance and ad­min­is­tra­tion and offers maximum flex­ib­il­ity through platform and device in­de­pend­ence.

When de­vel­op­ing web ap­plic­a­tions, pro­gram­mers generally resort to web frame­works. But what is a framework? And what makes a framework specific to web ap­plic­a­tions?

 A framework is a program structure that is used as a basis for software de­vel­op­ment. If a developer wants to create new software, it makes no sense to start from scratch each time. Numerous standard functions in software de­vel­op­ment offer tried and tested solutions in the form of program codes. In object-oriented pro­gram­ming, classes are usually used and these act as blue­prints for de­vel­op­ing software objects. A framework usually rep­res­ents a col­lec­tion of different co­oper­at­ing classes and thus de­term­ines 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 ap­plic­a­tion, it is referred to as a web ap­plic­a­tion framework (ab­bre­vi­ated to web framework).

As a found­a­tion for software de­vel­op­ment, web frame­works should provide a simple, clear structure that is easy to maintain and allows de­velopers to create powerful web ap­plic­a­tions in a short space of time. In order to fulfil this aim many web frame­works rely on three basic design prin­ciples:

• Don’t repeat yourself (DRY): the motto don’t repeat yourself aims to avoid re­dund­ancy in the context of software de­vel­op­ment. Redundant in­form­a­tion such as code du­plic­ates should be avoided since they have a negative impact on the main­ten­ance 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 ap­proaches to a solution, you should choose the solution with the least as­sump­tions and variables. In order to use a framework or to fix a specific problem, as little code as possible should be used.

• Con­ven­tion over con­fig­ur­a­tion: the more con­fig­ur­a­tion there is, the more complex the operation. Con­ven­tions, on the other hand, provide a way to reduce com­plex­ity. Therefore, web frame­works should provide the best ap­proaches in their default settings, and op­tion­ally offer ad­di­tion­al cus­tom­isa­tion options.

If these design prin­ciples are taken into account, using web frame­works in software de­vel­op­ment offers numerous ad­vant­ages. The framework spe­cific­a­tions also limit de­velopers. These struc­tur­al lim­it­a­tions are sometimes viewed as a dis­ad­vant­age.

Web frame­works are used to reduce time and cost of software de­vel­op­ment since codes are basically re-used. This mainly refers to basic features such as database con­nec­tions, website templates, caching methods, and security features that are provided by frame­works as pre­fab­ric­ated code modules. Thus, the de­vel­op­ment effort is limited to the specific program code of a new web ap­plic­a­tion. Since most web frame­works are offered as free software, there are usually no purchase costs.

In addition, frame­works promote the gen­er­a­tion of clean source codes, since de­velopers can rely on tried and tested building blocks for standard features. The program com­pon­ents provided by frame­works usually go through numerous de­vel­op­ment cycles and are con­tinu­ously optimised. Those in the community act as testers and co-de­velopers. This way, security gaps in new com­pon­ents are quickly found in large projects and rectified. Users and de­velopers converse in forums dedicated to the project with some of these being moderated by support teams.

The web contains an almost un­man­age­able number of frame­works for web de­vel­op­ment. These differ in basic design prin­ciples as well as in the features they offer. Different software projects may therefore require the use of different web frame­works. De­velopers are faced with the problem of selecting the ap­pro­pri­ate framework for the intended project. There are quick-fix com­prom­ises, in which the intended software project is adapted to the framework’s limits. Since frame­works are designed as universal solutions, de­velopers rarely use all the features of a given structure. Depending on the scope of the framework, an ap­plic­a­tion may contain more code than necessary.

In addition, the de­pend­ency in the re­spect­ive web framework is seen as dis­ad­vant­age­ous by the developer. In in­di­vidu­al cases, using a framework is linked to specific license terms, which can be prob­lem­at­ic when any further de­vel­op­ment of the framework is stopped. Since de­velopers have to fa­mil­i­ar­ise them­selves with the structure of the re­spect­ive program framework and the usage pos­sib­il­it­ies, they need time to adapt. Luckily ready-made features and code snippets save some time. Critics ac­know­ledge that there’s the risk of basic knowledge becoming lost. Users who only program on the basis of frame­works may deal less fre­quently with pro­gram­ming languages.

Since the source code of most web frame­works is freely ac­cess­ible, everyone has the op­por­tun­ity to get ac­quain­ted with it. If ap­plic­a­tions are developed for company use based on publicly available code com­pon­ents, they may be more trans­par­ent to hackers than apps whose source code isn’t public.

Just like the case with frame­works in general, web ap­plic­a­tion frame­works are also defined by program libraries and web de­vel­op­ment tools. While libraries provide only in­di­vidu­al features a framework can be viewed as an in­ter­act­ive program framework for standard pro­ced­ures – like a semi-complete ap­plic­a­tion.

The central basic com­pon­ents of a software framework con­sti­tute co­oper­at­ing classes with as­so­ci­ated methods. These are code blocks that describe the prop­er­ties of software objects and their  behaviour. Some of these com­pon­ents are static and therefore in­vari­able. Others can be adapted by the user e.g. by over­writ­ing methods. This allows the program structure to be adapted to a specific task. The term 'hot spots' was es­tab­lished to refer to a framework’s flexible com­pon­ents. The static com­pon­ents are called 'frozen spots'.

Web frame­works generally follow the concept of inversion of control (IoC). This is an abstract principle de­scrib­ing an aspect of some software ar­chi­tec­ture designs in which the flow of control of systems is inverted, unlike the case with pro­ced­ur­al pro­gram­ming.

In simple terms, IoC means that the re­spons­ib­il­ity for program execution does not lie with in­di­vidu­al com­pon­ents, which are developed and carried out on the basis of frame­works, but with the framework itself. This takes over the function of the main ap­plic­a­tion that co­ordin­ates the flow of control. Further com­pon­ents, which are im­ple­men­ted and re­gistered by the user in the framework, are available to the user when required.

In order to perform this cent­ral­ised control function, web frame­works offer a special interface that must be im­ple­men­ted by all com­pon­ents regarding the structure. Through this design principle, the framework is ready at all times to move resulting com­pon­ents and implement callback methods. These also enable the framework to inject in­form­a­tion into the com­pon­ents as needed, or to trigger a specific behaviour through method calls. While classes and their de­pend­en­cies are hard-coded in classical ap­proaches in software de­vel­op­ment and are therefore already defined during the com­pil­a­tion, the inversion of control concept enables a software to create objects dy­nam­ic­ally during the period.

In software de­vel­op­ment, IoC possesses the status of a general design concept. This is applied by design patterns such as De­pend­ency Injection (DI) and De­pend­ency Lookup.

The majority of all web ap­plic­a­tion frame­works are based on an ar­chi­tec­tur­al pattern called the Model View Con­trol­ler (MVC). This is a strict sep­ar­a­tion of ap­plic­a­tion logic and present­a­tion layer and divides software into three areas: model (data model), view (present­a­tion), and con­trol­ler (program control).

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

• Present­a­tion: 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 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 con­trol­ler.

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

The aim of the MVC ar­chi­tec­ture pattern is to achieve a flexible program design. Sep­ar­at­ing the ap­plic­a­tion logic and present­a­tion layer should mean that it’s easier to make changes later on as well as adding ex­ten­sions and reusing in­di­vidu­al com­pon­ents. This reduces the amount of pro­gram­ming required to adapt software to different platforms (Windows, Mac, Linux) or as a web ap­plic­a­tion, since only the con­trol­ler and the view have to be adapted ac­cord­ingly.

In the form of JSP (Java Script Pages) model 2, a design model based on MVC is also used in Java-based web frame­works. A JSP page cor­res­ponds to the view, servlets to the con­trol­ler, and Java Bean to the model.

The market for web ap­plic­a­tions is very diverse. Apps that are available to users via the browser don’t just differ in size and ap­pear­ance, but also in software design, depending on the ap­plic­a­tion and range of functions. The reason for this is the variety of available web frame­works, which are based on different tech­no­lo­gies and follow different ap­proaches in software design. It’s possible to compare single and multi-page ap­proaches, server-centric and client-centric ap­proaches as well as web frame­works, which are action-based or component-based.

Multi-page ap­plic­a­tions consist of several HTML pages, which are usually opened by entering the re­spect­ive URL into the browser, and they are connected using hy­per­links. The user interface of a single-page ap­plic­a­tion, 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 re­gis­tra­tion cards. The URL of a single-page ap­plic­a­tion does not change within the scope of the nav­ig­a­tion.

The pro­gram­ming model of a classic web ap­plic­a­tion cor­res­ponds to that of the World Wide Web whose ar­chi­tec­ture is char­ac­ter­ised by the Hypertext Transfer Protocol (HTTP). If a user accesses a web ap­plic­a­tion, it means that one or more servers and a client program (usually a web browser) are involved in each case. Depending on how the com­mu­nic­a­tion between server and client is designed, they are known as server centric or client centric ap­plic­a­tions.

• Client centric: if an entire HTML user interface (including ap­plic­a­tion logic) is loaded on the client when the computer is started, this is known as a client centric ap­plic­a­tion. Changes to the interface due to user input are im­ple­men­ted in this case by client-side pro­gram­ming languages such as JavaS­cript. A design approach like this is re­com­men­ded 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 de­vel­op­ment of single-page apps and is supported by JavaS­cript frame­works such as Angular JS or EmberJS.

• Server centric: for server centric ap­plic­a­tions, the ap­plic­a­tion logic remains on the server that creates the user interface and delivers it to clients for the present­a­tion. For changes to the user interface, server-side pro­gram­ming languages are available and the de­vel­op­ment is largely in­de­pend­ent of client-side un­cer­tain­ties. This approach is typically used in multi-page apps where the various views are retrieved from the server. A software design like this is as­so­ci­ated with longer loading times, but reduces the computing effort on the client device. Some apps avoid swapping the control logic due to security reasons. Im­ple­ment­ing the server centric approach can be found with Django, Zend, and Ruby on Rails frame­works, for example.

A server centric pro­gram­ming approach is found mainly in frame­works that have been developed to create classic web ap­plic­a­tions with a multi-page structure and a classical HTML interface. Only the interface is displayed in the web ap­plic­a­tion and generally uses browser nav­ig­a­tion. Web apps of this kind can be run in­de­pend­ently of the operating system or web browser. The control logic is processed via the HTML-typical request/response com­mu­nic­a­tion from the server. Client centric web ap­plic­a­tions are sometimes referred to as Rich Clients or Rich Internet Ap­plic­a­tions (RIA). The user interface im­ple­ments this kind of ap­plic­a­tion on the client. These are usually loaded when the computer is started. In contrast to classic web ap­plic­a­tions, a client centric approach can be used to implement features such as drag and drop man­age­ment, offline avail­ab­il­ity, and hard-drive access, which are more familiar with desktop ap­plic­a­tions.

At the ap­plic­a­tion control level, web frame­works can be divided into two classes. While action-based web frame­works con­sist­ently display the HTTP-related request-response pattern, it is ab­strac­ted in component-based web frame­works. Action-based web frame­works: when it comes to action-based frame­works, the con­trol­ler 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 ap­pro­pri­ate ap­plic­a­tion logic. This can usually be derived from abstract classes. If the action has been executed, the con­trol­ler 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 frame­works lean strongly towards the MVC pattern and are also referred to as request-based because of the request-response pattern’s strict im­ple­ment­a­tion. Classic rep­res­ent­at­ives are:

• Django

• Ruby on Rails

• Symfony

• Spring MVC

• Code­Igniter

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 de­velopers with great freedom, but requires a deeper un­der­stand­ing of the web framework since de­velopers are re­spons­ible for creating HTML, CSS, and JavaS­cript. Component-based web frame­works: unlike the action-driven approach, component-driven web frame­works abstract the HTTP-related request-response pattern by looking at the user interface of a web ap­plic­a­tion as a col­lec­tion of com­pon­ents. For each of these com­pon­ents, which are linked to software objects on the server side, specific reactions are defined during the de­vel­op­ment of the web ap­plic­a­tion. These follow events triggered by a user in­ter­ac­tion with the component. This is why event-con­trolled web frame­works are mentioned. Classic rep­res­ent­at­ives are:

• Lift

• Apache Tapestry

• JavaS­erv­er Faces

• Apache Wicket

The basic idea behind the component-based approach is to group related actions together. For example, the component, Ac­count­Con­trol­ler, rep­res­ents actions such as login, logout, or get­Ac­count. A software object can therefore be re­spons­ible for several actions. Component-based web frame­works typically provide a large selection of reusable com­pon­ents that conceal details of the un­der­ly­ing request-response pattern from the app developer. In this context, this is known as a black box. Web frame­works of this type are therefore suitable for de­velopers, who primarily want to rely on pre­defined com­pon­ents. Those that want more freedom regarding HTTP, HTML, CSS, and JavaS­cript are better off with an action-based web framework.

Since frame­works have a great influence on the features and design pos­sib­il­it­ies of the web ap­plic­a­tion as well as on the workflow during de­vel­op­ment, the work process usually starts with selecting the ap­pro­pri­ate program framework. On the one hand, the planned software project as well as previous knowledge should be con­sidered.

Key questions relate to the type of ap­plic­a­tion and the desired ar­chi­tec­ture (server centric, client centric). Both aspects have a direct impact on the operation and user-friend­li­ness of web apps.

It is useful to already have existing coding language skills and for the required in­fra­struc­ture to be available before you start searching for the ap­pro­pri­ate web framework. There is a wide choice of well-doc­u­mented web frame­works es­pe­cially for well-known pro­gram­ming languages such as PHP (e.g. Zend, Symfony, CakePHP, and Code­Igniter), Java (e.g. JavaS­erv­er Faces or Apache Wicket) or Python (e.g Django). The pop­ular­ity of Ruby in web de­vel­op­ment is mainly due to the popular Ruby on Rails web framework. Client centric web frame­works typically rely on the JavaS­cript scripting language.

De­velopers who have primarily pro­grammed desktop ap­plic­a­tions in the past often have more dif­fi­culties ori­ent­at­ing them­selves within the request response pattern-oriented program model of action-based frame­works than classic web de­velopers do.