The development of websites has evolved over the years. They initially originated from simple hyperlinked pages that provided a wealth of information, evolving to complex objects being exposed as URLs at runtime. When wanting to develop a site, there are multiple options that one may choose for development. A briefing on the most widely known methodologies follows.
The 'old school' approach is to use a programming language to create a complete site or application from scratch without using any third-party templating system or framework. In this method, there are three layers:
Client-side
Server-side
Database access
In this architecture, a user requests a page. Every request is processed by executing an appropriate server-side script. A server-side script is any piece of code that is processed and that helps the server to send a response to the client. A common example of a server-side language is PHP. All code that executes in the user's system or the client's system is called client-side script or language. HTML and JavaScript are such client-side languages, as they are processed and rendered by the web browser on the user's computer. Whenever needed, any stored information is fetched by the server-side script from the database, and any new information is saved in the database. This approach is called the Three-Tier Architecture as, generally, the activities of rendering output, processing the script, and manipulating the database are spread across three layers of systems.
One advantage of the conventional three-tier architecture is that it has fewer dependencies. Generally, the only real dependency for such sites is the language itself and the database, if used. Hence, they can be run in any environment that supports the language and, if necessary, the database server. This advantage looks minimal considering the other overheads and the increasing support for CMSs and frameworks among the hosting providers.
The only restriction on what you can do is the limitation of the language itself. Coding everything from scratch, along with the overheads, also brings the flexibility of doing anything exactly the way you want. The only limitation on what can be done and what cannot be done is what is imposed by the language itself. Again, this is not a real advantage as the emerging technologies are being built so abstract that they impose almost no restriction themselves.
The conventional three-tier architecture can be used to develop new development methodologies. Whatever the framework of the CMS may be, beneath the surface, they must all follow the same core rules. Hence, something about these systems takes care of handling requests and generating responses at the lowest layer, which the developer need not worry about. The components that take care of such activities are themselves coded in the conventional three-tier architecture.
Having to reinvent the wheel is a big disadvantage of the conventional three-tier architecture. Any big project will have a common set of functionalities that are repeated. Many projects have, in fact, emulated an existing CMS or framework in the process of building their own tools. This is just repetition of work and time that could have been spent more productively. Most projects written in the conventional three-tier method end up reinventing the wheel, at least for the concepts of "formatting output" and "database abstraction".
Another disadvantage is that the three-tier architecture is error prone. The language allows you to get things done. It doesn't check if they are done cleanly or not. Hence, it is very simple to write code that gets something done, but not so easy to write clean code that gets the same thing done, even in the worst conditions.
The three-tier architecture is also difficult to maintain. It could be said that code is more read than written. And with this approach, because HTML is mixed with server-side code and appears messy, it is hard to read and maintain such code. Also, if the custom-written libraries are not well documented by the developers who wrote them, then the maintenance becomes even harder as one must read the code to understand its functionalities.
URL mapping becomes complex with the three-tier architecture. It must be noted that in most cases, the job of a server-side script is just to generate client-side output that can be rendered in the browser. So, when such an HTML page with further possible actions is created, the server-side script must be able to generate navigational elements and carefully map the links to a server-side script that can handle the particular request. That is, it has to map a URL to server executable code. This can become tedious to maintain as the site grows, or when a new team is introduced to maintain the code.
Security becomes problematic with the three-tier architecture. The language may have security vulnerabilities, such as SQL injection. Alternatively, there may be security bugs introduced by the programmer. Because, in this approach, all of the functionalities are taken care of by the programmer, there must be strong security testing for all developed functionality and different combinations of use-case scenarios. It is also possible that certain situations can go unforeseen. Writing secure code in such an architecture requires strict discipline, and is laborious.
Templating is the idea of using files that are very similar to regular HTML files, to render output. These template files have what is known as variable replacement, or commands, similar to a programming language, called directives, that can be inserted within HTML. Hence this approach clearly separates what is called presentation from logic. Apart from this single concept, everything else is the same as the approach mentioned above. Templating also inherits all of the advantages and disadvantages mentioned previously. The ones in addition to those already mentioned are listed below.
One of the main advantages of templating is that view is separated from logic, as explained in the previous figure.
One of the main disadvantages of templating is that there is a small learning curve for a new templating language. Every new templating language introduces a new syntax and, hence, a small learning curve. The time it takes to learn a templating language depends on the complexity of the system. However, a programmer can generally start using a templating language with just the reference guide or cheat sheets.
Application frameworks are systems built on top of a programming language to let the developer focus only on the logic of the application. The framework takes care of the other repetitive work. All frameworks at least have the well-known features of "URL Mapping", "DB Abstraction", and "Templating". How each of these is implemented internally is specific to the framework. Every framework also exposes a methodology, the most famous of which is called MVC, which stands for Model, View, and Controller. The framework itself will contain documentations and libraries for frequently used functionalities, thus making the developer's work easier. Every framework also tries to ensure cross-browser compatibility, cross-platform support, and many other clean practices, most importantly the RESTful approach.
Note
For more information on RESTful practices, read www.xfront.com/REST-Web-Services.html.
One of the main advantages of application frameworks is that there is a high reusability of code. Frameworks encourage architectures where a higher reusability of code is possible. They also provide enough APIs to do the most common tasks, so that developers don't have to rewrite them.
Application frameworks provide clean practices at no extra effort. Most frameworks follow clean practices, and because they allow you to take care only of the logic, the internals are handled by the framework. Hence, while you may not even know it, you have generated applications that adhere to clean practices!
Application frameworks have good testing mechanisms. Generally, application frameworks also provide some kind of helpful mechanisms to make testing easier. Most MVC frameworks auto-generate test files, or at least generate a very useful skeleton for each unit of functionality being implemented.
In application frameworks, view is separated from logic, which is similar to using a templating language. Most frameworks allow a mechanism for separating view from logic. Some frameworks do this by using a templating language that the framework understands. But this is only one way of doing it, and many frameworks follow different approaches to achieve the same outcome.
Database abstraction means writing a system in such a way that if you were to only change the database server that stores your data, your system would still work without any necessary code changes. Also, most frameworks have an implementation of the concept of Object-Relational Mapping (ORM), which allows the developer to manipulate the database as objects and provide a simple syntax to achieve complex queries.
When working with application frameworks, there is a big learning curve in understanding the development methodology that the framework understands and expects you to follow. Getting used to a new development methodology can take some time.
All application frameworks have framework-specific syntaxes for a lot of functionalities that they expose. It takes some time to be able to get to the exact documentation when you need it.
Most MVC frameworks have a single templating system, or DB abstraction layer, already defined that you have to use. For some applications, this might be a limitation, or maybe you just prefer something else. This is a small disadvantage. Certain frameworks, like "Catalyst", allow developers to choose individual components as well.
Content management systems are a very interesting idea. The focus of any content management system is that the end user must be able to create websites that can be self-maintained without any programming knowledge. A CMS makes it simple to create the kind of sites that are generally known as Web 2.0. Web 2.0 simply means sites in which the content is being displayed is created by the end users and not the developers of the site. There are numerous content management systems, and each has its own exposed architecture. To use a content management system, one must understand the basics of the particular system, and then comprehension and insight into how one performs development using that particular system. Hence, one can quickly start creating powerful and dynamic websites.
When using a content management system, often the only thing that is required to build the site is to let the system know what type of content you want, how you would like it to be displayed, and who can do what. Almost everything else is handled by the system. This allows the developer to focus on the key areas of any website, which are the content itself and its presentation.
Most content management systems come without the prerequisite of needing to know a programming language. Although knowledge of the language helps in many ways, one can still build powerful and custom sites without any prior experience. Moreover, all CMSs are so user-friendly with onscreen help and wizards, that you have all that you need to get started right in front of you. Perhaps, simplicity is the keyword for any CMS. Of course, the simplicity mentioned here is what is called pseudo-simplicity, where a complex system hides within itself all of the complexity but exposes a simple usability.
Content management systems come with the necessary demonstration templates and sample pages that can be used to quickly kickstart the website. In most CMSs, almost without any effort, you have the baseline to start with, and all that is left to do is customizing the site to your requirements.
Simple sites are alright, but when the requirement grows, creating everything with what is already available requires a new mindset. Often, the biggest hurdle that developers find in getting used to a content management system is that everything is defined as content and not objects or functions. So every component that is available for download speaks in terms of what it does with the content. It is often necessary to use multiple components to get what you need. This is the case with any well-abstracted system; it takes a new mindset to learn it!
Many CMSs introduce the requirement of some templating language to be able to customize the look and feel of the site. In such cases, there is an overhead of learning the templating language, as well as learning how to use the templating language to create a new look and feel within the CMS used.
A big disadvantage of a CMS is that you are restricted to the functionalities provided by the CMS. Depending on the exposed architecture, there could be practical limitations on the extendibility of the CMS. Certain CMSs cannot be extended much beyond what they already have to offer. Certain CMSs can be extended a little, but not by much more. Some CMSs can be extended, but only at the cost of learning complex APIs and methodologies that are specific to the CMS. There are also some CMSs that allow extendibility with just the knowledge of the programming language in which they were written.