Contents

Background

Thomas S. Sha, Director of Presentation Platform Engineering at Yahoo!, describes web development as one of the software development fields that requires a diverse skill set. Sha recounts that in the late 1990’s, web developers were hired with no more programming experience than the average graphic designer. For a time, these developers were only required to know the technologies of front-end web presentation, such as HTML, Javascript, and CSS. But over time, the web has evolved to support much more complex interactions. Modern web developers are now expected to have a strong Computer Science background, often marked by a Bachelors or Masters degree, and a strong knowledge of front-end presentation, server-side languages, networking protocols, and databases, as well as basic graphic design. While Sha has offered incisive examples on improving front-end engineering, there remain many unanswered questions about successful back-end engineering, specifically pertaining to web platforms and frameworks.

Software engineers interested in building scalable websites require diverse skills not only to develop a web application, but also to understand the frameworks and platforms they choose or are considering initially. Choosing the right platform or framework is one of most frequently asked questions among programmers who are starting a new project for the web. This question carries significant weight, for lack of understanding about a platform from the outset can lead to lack of preparation and therefore costly mistakes, such as loss of users and service, as popular web applications like Friendster, Overture, and Twitter have adversely travailed.

To impart a useful resource for programmers who have these questions in mind, we will probe the strengths, weaknesses, and scalability issues of the most popular platforms and help you make an informed decision for your project type and situation based on the information we gleaned from our research, interviews, and experience.

Short History of Web Development

On August 6, 1991, Tim Berners-Lee publicly introduced a new idea to the world, the World Wide Web. Berners-Lee originally created the Web as a solution for publishing, distributing, and linking information for his colleagues at CERN. The World wide Web was built on hypertext, which was originated in the 1960s and allowed for the markup of and linking among documents. A year and a half later, CERN released the Web to anyone who wanted to use it - free of charge.

Originally, content on the Web was hand-coded into static pages which were then served by a web server. Discussions quickly started about creating dynamic content to be served programmatically. Late in 1993, the Common Gateway Interface (CGI) was created to fulfill this purpose. CGI allows web servers to call external programs (which were often written in C or Perl) that dynamically create static web pages which are then transfered by the server. Soon, many applications were created based on these few short scripts.

As use of CGI gained in popularity, two important developments were made. The first was tight integration of specific languages into web servers, such as mod_perl for the Apache web server. This helped alleviate one of CGI's biggest shortcomings, performance. Instead of relying on a new process for every request, as in CGI, integrated languages could run in the same thread as the response handler.

The second major improvement was the development of libraries for common tasks. Libraries ranged from basic data manipulation and database connectivity to HTML-generating templates and session management. Over time, as these libraries grew, developers applied them into their projects, often adding functionality along the way. Soon, these libraries became large enough to act as their own web development environments. For many projects, the framework's developers realized that they had reached a crucial moment-- they almost created a full framework. This realization led developers to spend some time reorganizing the library into a framework.

Timeline of server-side technologies:

  • 1990 - Tim Berners-Lee creates the World Wide Web at CERN
  • 1991 - Berners-Lee announces WWW to the public
  • 1993 - CERN releases the WWW for use free of charge
  • 1993 - Common Gateway Interface developed
  • 1995 - PHP released
  • 1996 - Microsoft releases ASP
  • 1997 - Sun Microsystems creates Java Servlets
  • 1999 - Java Servlets included in J2EE
  • 2002 - Microsoft releases ASP.Net
  • 2004 - PHP Version 5 released with OO support
  • 2004 - David Heinemeier Hansson creates Ruby on Rails
  • 2005 - Django released

Modern Framework Design

The modern framework design has been a significant development in supporting most websites today that have dynamic content, user work flows, and heavy database integration. More than what Berners-Lee originally anticipated, modern web sites are becoming much more like desktop applications. Almost all current frameworks employ the object-relational model and model view controller - two major parts of the modern framework design.

Object Relational Model

The Object-Relational Model (ORM), also referred to as Active Record, uses database schemata to create objects that developers can use to interact with the database. By default, they support simple SELECT, INSERT, and UPDATE statements, and can be extended to allow for more complex interactions. The ORM decreases the amount of SQL that developers have to write and can help prevent database errors and attacks by normalizing incoming data before it is committed to the database.

Model View Controller

The Model-View-Controller (MVC) is a software pattern often used in developing desktop applications. The MVC pattern is created by separating applications into Models, Views and Controllers. Models are representations of data, often from a database, that can be accessed and modified. Views form the user interface and control the presentation of data to the user. Controllers determine the users' path through the program depending on the data and their interaction with the Views, as well as conducting most of the business logic. The MVC pattern also helps developers create much more modular code and avoid the "spaghetti code" that develops when code and content are intermixed. This convenience allows for faster development times, independent testing of each component, code reuse, and generally more maintainable code.

Overview of Current Frameworks

Enterprise Scale Web Frameworks

Active Server Pages

Overview

Active Server Pages (ASP), first released in 1996, is a server-side scripting engine developed by Microsoft for use with its Internet Information Services (IIS). ASP pages are written in one of the active scripting languages. The most popular of these is VBScript, an Active Scripting language with similar syntax and structure to Microsoft's Visual Basic, but any other active scripting engine can be chosen instead by passing in a Language directive to the engine.

In 2002, Microsoft released ASP.Net, a variant of ASP that uses Microsoft's Common Language Runtime (CLR; also referred to as the .Net Framework) for dynamic code execution. ASP.Net brought more structure to web developers, helping to move them from more traditional procedural programming, which usually resulted in dynamic code to be placed in line with HTML and other content, to a more object-oriented model with ASP.Net controls. Controls are intended to be subsections of full pages and are developed and handled in much the same way as full pages. They can be developed independently and used across multiple pages or sites. Each control dictates its own flow and rendering while a page is often used to control which controls are displayed to create the overall page view.

Development with ASP.Net was also intended to be viewed more like traditional desktop development, instead of typical web development, with the MVC pattern. The MVC pattern is created by separating pages into the Model, often a DataSet object representing the results of a database query, the View, an ASPX page containing HTML, ASP.Net controls, and small amounts of code, and the controller, a "code behind" page which has all of the necessary business logic written in one of the .Net languages (C#, J#, Visual Basic.Net).

Advantages

ASP helped developers create websites by providing them with built-in objects that accomplished frequently-used functionality. In ASP.Net, this idea was expanded to allow users to create their own objects. This modular design makes it very easy for developers to create new pages. There are also libraries of existing controls that they can choose from which cover most of the common features.

ASP.Net is one of the only frameworks that is completely self contained. The default libraries support most common tasks without need for outside libraries. The entire MVC pattern is implemented with these libraries, including full database support and ORM. Additionally, ASP.Net is designed to tightly integrate with Microsoft's IIS web server and SQLServer database server, allowing for fairly low configuration overhead.

Microsoft has also developed Visual Studio.Net to function as a web development environment. The compiler is aware of other languages used in web development, such as Javascript, and can help identify errors in that code as well as the ASP and CLR code. Because of the integration with IIS and SQLServer, Visual Studio also allows the developer to "debug" a site. During debugging, a web browser is directed to the developer's computer and Visual Studio starts a web server on an unused port, which is connected to a development database. The developer can then navigate through the site while using the full debugging capabilities of Visual Studio, as if the web site were just another program. This debugging information can be extremely useful in finding and correcting errors in a web site.

Disadvantages

Because ASP and ASPX pages can contain CLR code, the MVC pattern is not strictly enforced. This can lead to what one author calls the "MoTolliew", where the boundaries of each component get blurred, and the result is similar to "spaghetti code". Good development practices can help to avoid this problem.

ASP and ASP.Net are limited to the Microsoft Windows platforms. This makes this environment is one of the most costly because each server and development machine must be running Windows and Visual Studio, and SQLServer adds even more cost. The open source Mono Project is working to support the CLR on other platforms such as Linux, but because they are not in control of the language, they cannot guarantee full support.

The CLR also has development overhead that makes the ASP.Net development cycle slower than other languages. Until .Net 2.0, ASP.Net sites had to be fully compiled into libraries before they could be pushed to a server. .Net 2.0 removed this requirement by providing just-in-time compilation on the server. However, because the CLR is statically typed, a compilation error in an undeveloped portion of code will cause the page not to be rendered at all and an error message given instead. In a dynamic language, a developer could ignore those errors, allowing her to test specific parts of the site immediately after coding them.

JavaServer Pages

JavaServer Pages (JSP) was originally introduced by Sun Microsystems in 1997. Its design is very similar to that of ASP, an XML-like syntax mixed with HTML for the pages with executable code on the back end. This back end code is written with Java Servlets, objects that receive the HTTP request and process an appropriate response. These servlets must be hosted in a servlet container, a web server that can execute Java code, such as Apache Tomcat or Geronimo Application Server.

Unlike ASP and ASP.Net, JSP's use of Java makes it cross-platform. This makes JSP less expensive and more convenient to deploy on other systems, with full support. However, this results in less tightly integrated components, such as the database, which in turn creates more overhead in getting a site set up, as in this example. The lack of tight integration also seems to have a negative effect on JSP's performance. One report showed a 2-5 fold slowdown with JSP by writing the same application in both ASP.Net and JSP.

JSP also suffers from a deficiency of built-in libraries made specifically for web development. To compensate for this, a number of frameworks have been built on JSP, such as Struts, Turbine, Tapestry and Spring (more complete list). Each of these frameworks adds new functionality, such as stronger MVC implementations, AJAX integration, and site management. These frameworks help improve productivity by reducing the amount of work the developer must do.

Finally, by using Java as the main language, JSP is capable of handling large, complex work flows and is very well suited for applications which require complicated business logic. However, the required boilerplate code and static typing lengthen the development cycle as with the CLR languages.

PHP and PHP Frameworks

In 1995, after Rasmus Lerdorf created the early version of PHP allowing programmers the ability to log visitors to web pages, he continued to develop the language by adding a feature for converting data entered in HTML into symbolic variables. In order to encourage exportation into other systems, he opted to continue development in C code rather than Perl. Later that year he released PHP 2.0, the first version available to the public. PHP gained in popularity, and by 1997 a core team of developers had joined Lerdolf to help him develop Version 3.0. By the June 1998 release of version 3.0, more than 50,000 users were using PHP on their web sites. Development began growing at such a hectic pace that in 1999, Netcraft.com reported a conservative estimate that at least a million people were using PHP.

Two core developers, Zeev Suraski and Andi Gutmans took the initiative to rewrite the PHP parser, which they dubbed the Zend scripting engine. Their work culminated in the release of PHP 4.0, which propelled PHP to what an estimated 3.6 million installations. With the release of Version 5, Netcraft estimates that PHP has been installed on almost 19 million domains. E-soft estimates that PHP is by far the most popular Apache module, available on almost 54 percent of all Apache installations.

PHP 4 to PHP 5

According to W Jason Gilmore, author of Beginning PHP and MySQL 5, PHP 4.0 included several enterprise-level improvements. Since Version 3's primary failings concerned scalability, it allowed for improved resource handling, which was needed to run enterprise-class websites, and object-oriented support such as standard classes, object overloading, run-time class information, and object development methodologies. The MCrypt library, ISAPI support, Native COM/DCOM support, Native Java Support, and Perl Compatible Regular Expressions libary were incorporated into PHP 4.

Although PHP 4 was a considerable improvement from Version 3.X, PHP 5 significantly improved object-oriented capabilities for fuller functionality, string handling , XML, and Web Services support. The SOAP extension was introduced, and XML support is now based on the libxml2 and SimpleXML libraries, known to effectively parse and manipulate XML. Native support for the SQLite database server and try/catch exception handling were introduced in PHP5. These improvements helped to make PHP5 a more robust, full-featured language, but they came at a price. Even though PHP 4 was a predecessor to PHP 5, PHP 4 has been shown to perform significantly faster than PHP 5.

PHP has many frameworks to choose from. This can be advantageous in that there are many existing options; however, it can also be confusing and time-consuming to figure out which adequately meets the needs of the site, whereas other languages only have a few to choose from.

Some seasoned PHP developers recommend PHP 4 over PHP 5 for speed issues. Although PHP 4 is not as well supported with OOP as PHP5.

Nathan Schmidt, CTO of PbWiki.com mentions:

"PHP4 is a lot faster than PHP5. I recommend using PHP4 and implement OOP-where-it-counts model but keeping the object model and internal API as simple as possible. Key areas which you'll want to be abstracted off for later replumbing are data layer (key-value storage and DB access), and authentication/security. These are two places where we've been burned to one degree or another due to a codebase upon when we added a feature, something would break."

On the other hand, W. Jason Gilmore, author of Apress's Beginnning PHP and MySQL 5, rebuts:

"I would certainly recommend going with PHP 5, because it’s a vast improvement over its predecessor. I could offer a long-winded answer as to why, but simply pointing out Yahoo! makes heavy use of PHP 5 should be suffice to prove version 5 hums along just fine. Of course with any language you could build OO abstraction on top of abstraction, which is ultimately going to contribute in a code slowdown, but provided you make judicious choices throughout the application development process, I strongly suspect your PHP 5 application is going to work just fine for a long time to come.Besides, sooner or later PHP 4 development will stop, leaving those continuing to use it in a bind when security issues crop up."

Advantages

PHP has proven to be the scalable platform for most of Alexa's most highly trafficked websites today. For example, the most visited site in the U.S, Yahoo!, uses PHP in nearly all of it's web applications. Wikipedia, Flickr, Facebook, Digg, WordPress, PBWiki.com, and Friendster are also written in PHP.

PHP pairs well with most enterprise and open source databases, providing native support for over 25 database products. In addition, PHP is easy, quick, and cheap to install, configure, and learn, and it is installed and pre-configured on almost all hosted servers. For most programmers, PHP takes the least investment to learn and switch to. One of it's most attractive aspects is its exhaustive set of libraries, containing well over 1000 functions, which allow developers to create and manipulate PDF files, evaluate passwords for guessability, communicate with the Lightweight Directory Access Protocol, parse complex strings, authenticate users against login credentials stored in flat files, and communicate with a wide variety of protocols and credit-card processing solutions. Most importantly, PHP has a much larger community support than Python and Ruby on Rails.

PHP also outperforms many of the other popular web development languages, making it a good choice for high-throughput applications.

Disadvantages

Some of the biggest downsides about PHP is its maintainability, lack of unicode support, and security vulnerabilities. First, many programmers who leave PHP are repelled by the prospect of maintaining other programmers' spaghetti code. Because it fundamentally allows novice programmers to code directly alongside HTML, PHP can encourage hard-to-understand spaghetti code, which obfuscates the comprehension of an existing code base.

In addition, both PHP 4 and 5 both do a relatively poor job with delegate and observer patterns. In order to get around this, workable mechanisms and meta flags are manually configured where there's no baked-in support for them. For example, Nathan Schmidt, CTO of PBWiki.com would like the baked-in support to have his company's spam filters register for a call_delegates('before_save_page',array($page,$content,$user_info))so that some of their clients who are white-label and enterprise users could attach a much more or less aggressive spam filter depending on their needs by specifying add_delegate ($storage_engine,'paranoid_public_wiki_spam_filter').

PHP 5 surprisingly still lacks Unicode support. There is no Unicode string type, and functions for working with the byte strings as UTF-8 strings are missing from the repertoire of standard built-in functions. While there are multi-byte string extension functions, they are not guaranteed to be available and, thus, are unreliable.

The most vociferous complaint about PHP is that it can encourage security vulnerabilities, which the PHP security team has been slow to address, says Alex Sotirov, vulnerability engineer at Determina. Stefan Esser, a well known PHP security researcher, was disillusioned with the PHP security team that he had to start The Month Of PHP Bugs . “It just doesn't seem like a very trustworthy platform, but Wikipedia managed to hack it securely," says Alex. "Inherently, PHP has a lot of features that are easy to misuse if you're not careful," he says. The register_globals feature is the many prominent examples. However, it is certainly possible to write secure PHP code, but one has to be careful about it. A good place to start learning about it is the PHP Security Guide and Essential PHP Security. On the other hand, it is possible to make the same mistakes on other platforms of course, but it depends on how robust the framework's facilities are to properly validate and encode user input. Wikipedia lists more weaknesses of PHP.

Agile Web Frameworks

Overview

Ruby on Rails and Python are frameworks that are designed for programmer productivity, graceful and concise code, and ease in implementation. The term, “agile”, is predicated upon the meaning of agile software development, which favors working software as the primary measure of progress, rapid iterations within 2 to 4 weeks, and face-to-face communication rather than written documentation. The modern definition of agile software development evolved in the mid 1990s as part of a reaction against the waterfall model of software development, which is typified by a highly micro-managed, bureaucratic, unwieldy, slow process of software development that has been traditionally employed.

To give a historical overview, Rails is framework which emerged from the development of a web application, Basecamp, and Django emerged from the development of the highly successful Lawrence Journal World. Ruby on Rails and Python’s Django exhibit the key strengths of the agile software development method for the web. Generally, both use the Model-View-Controller pattern to emphasize good software design principles and Active Record to efficiently and easily interact with the database.

Ruby on Rails

Advantages

Notably, Ruby on Rails enforces a strict MVC model, which helps guide and accustom programmers into good design practice. Rails proponents boast of Ruby on Rail's incredible productivity, with some claims of 10 to 1 over Java development. Productivity and ease in implementation is accomplished through many paradigms. First, Ruby on Rails focuses on the "Don't Repeat Yourself" (DRY) philosophy, which means abstracting out repetitive tasks with methods that often look like extensions of the Ruby language. Each line of Ruby code accomplishes more than that of other frameworks. Second, scaffolding is a rails feature that allows one to create database-backed user interfaces quickly with a few lines of code because Ruby fills in the tedious details. As code is improved, the scaffolding melts away. However, Rails has a laser focus on a single niche: small to medium sized database-backed Web applications.

Ruby on Rails's ORM, ActiveRecord, makes database design and interaction conceptually simple. Active Record, Rail’s persistence engine, is a design pattern that discovers the columns in a database schema and automatically attaches them to your domain objects using metaprogramming. It saves objects to the database and minimizes the pain of object-relational mismatch better than alternatives. ActiveRecord is a hallmark feature that boosts productivity because class definitions don't need to specify column names and developers can avoid writing SQL, thus preventing some security vulnerabilities. In addition, ActiveRecord uses simple conceptual models by allow relationships to be specified as such: as belongs_to, has_one, has_many and has_and_belongs_to_many and make validations like validates_presence_of :name. Also, there is database flexibility. One can override Ruby on Rail's database naming convention to use Rails with existing databases rather than be forced to create new database schemas that conform to Rails conventions. However, it might be difficult and messy.

Importantly, programming on Ruby on Rails should enhance the programming experience. First, there is immediate feedback. One can write a line of code and save, and the change is active when the next Web page is loaded rather than compile, wait, and see. Second, debugging can be effective yet painless, for Ruby on Rail's breakpointers offers a full debugger, through which one can have access to a full interpreter and the ability to execute methods on an application -- capabilities that aren’t provided to you by Java. Third, one can view database changes quickly. For example, there is a built-in Rail’s script that allows for persistent objects in an interactive Ruby interpreter window. One can code a persistent model, make changes to the database through the model, and then run some database queries to see the impact on the system. Java doesn’t provide this amenity.

Ruby on Rails also provides seamless integration. One can write three lines of code, create a table, and then immediately generate a user interface for that model because of the keen integration between ActiveRecord and the MVC framework.

Less configuration is needed. Because Ruby on Rails emphasizes "Convention over configuration", one doesn't have to mess with massive configuration files because Rails does it automatically. Many Web development frameworks, such as ASP.Net and Java, force developers to write and maintain large and sometimes complex configuration files, Rails assumes a common project directory structure and simple, common naming conventions for methods, classes, tables, and columns to infer much of what needs to be configured in Java applications. Following RoR’s suggested naming conventions allows for a reduction in code, often by a factor of 10 or more than Java counterparts. See Example towards the bottom.

Another benefit is Ruby on Rails makes it very easy to build great user interfaces and interactions. One can make AJAX calls easily with one or a few lines of code, because Rails provides easy AJAX support and integration.

There are many easy-to-use and robust tools. First, there is built-in testing. One can extend the simple automated scripts called harnesses and fixtures in Rails, making test cases easier to write and run. It also provides built-in logging support, breakpointer, profiler, and testing frameworks which are all tailored for Web-based applications and two-tier operation.One can then execute all your automated tests with the rake utility. Second, like Smarty for PHP, Liquid is a templating system for Rails. Third, you can employ a simplified architecture by using Rail’s out-of-the box scripts that generate application components that adhere to common architectural goals, such as page-level and fragment-level caching; two-tier design; and environments for test, development, and production. Fourth, Ruby on Rails comes with a webserver for development purposes.


Disadvantages

There is difficulty using existing legacy schemas because Ruby lacks support for ORM for legacy schemas. Java’s approach area eclipses Rails in this area. Since Rails uses a wrapping approach over a mapping approach and because Rails tools assume conventions in the data model, it needs a fraction of the model code found in Java applications. Thus, shoehorning a legacy schema into Rails will go less smoothly.

As Twitter adversely encountered this problem, Ruby on Rails does not natively scale to multiple databases. There is a possible solution, but no case studies have proved its success.

Although Ruby on Rails provides immediate feedback, it has poor error reporting compared to what is provided by a Java or ASP.Net compiler.

Another striking weakness of Ruby on Rails is the limited libraries. One might have to write some specialized routines himself rather than rely on the community for support because Ruby is less mature than Perl and PHP when it comes to third-party add-on libraries. In addition, like PHP, Ruby on Rails provides weak internationalization and Unicode support. On the other hand, Python and Perl are known to have good support in Unicode. Furthermore, there is a lack of reusable modules for typical portal features. Unlike Python’s Django, Rails doesn't come with any generic set of built-in permissions or user registration.

Ruby is slower than Python, Perl, and PHP. However, if the slowness of Ruby deters your application and creates fatigue, David Heinemeier Hansson suggested finding bottlenecks in the Ruby code and rewriting it in C.

Ruby suffers from a similar global interpreter lock problem. The Ruby interpreters are not completely thread safe. When running multi-threaded applications a lock has to be acquired by a thread before it can access any objects. That means that Ruby scales by using multiple instances of the interpreters rather than the Java approach of using multiple threads.

Python

Many popular websites have successfully scaled on Python. These companies at the same time have publicly praised how easy, fast, and elegant Python is for their project. For example, Google uses Python as a primary language other than C++ and Java. Google Groups was written completely in Python. Some parts of Gmail and Google maps, as well as many of its search-engine internals have also been written in Python. In addition, YouTube.com was developed almost entirely on Python. A YouTube.com software developer mentions, "Python is fast enough for our site and allows us to produce maintainable features in record times, with a minimum of developers." Other examples are Reddit, Yelp, and NASA. NASA has used Python to implement a CAD/CAE/PDM repository and model management, integration, and transformation system.

Strengths

Though one of the newest frameworks, Django has been claimed to be faster than Rails and PHP’s Symphony. Django has many features in common with Ruby on Rails. Like RoR, Django uses a strict MVC model, which helps guide and accustom programmers into good design practices. Django also uses ORM, similar to RoR's ActiveRecords, to make database design and interaction conceptually simple. Django comes with easy AJAX support and integration. As on Ruby on Rails, one can make AJAX calls easily with one or a few lines of code.

Unlike on Ruby on Rails, Django offers reusable modules for portal style applications. One can easily apply and extend modules for user registration, permissions, session management, tagging, and commenting. Python libraries also support Unicode. They also offer string functions that programmers have claimed to lead to clear and concise programming. Compared to PHP string functions that seem misleadingly similar, Python’s give programmers ease and clarity in parsing strings.

Python is an overall excellent integration language. It is easily extensible with C/C++/Java code, and easily embeddable in applications. The creator of Python, Guido, suggested, “The best approach is often to write only the performance-critical parts of the application in C++ or Java, and use Python for all higher-level control and customization.”

Weaknesses

Although many programmers enjoy the elegance and brevity of coding in Python, errors can be created by improper white-spacing. Depending on one's preference, the Python style can be elegant or annoying.

Like Ruby on Rails, Python's Django does not natively scale to multiple databases. There is a possible solution such as pointing each application to a separate database, but there is no case studies to prove its success.

Like other interpreted languages, Python is slower than C and other compiled languages and is not recommended for computationally intensive applications. Performance of Python language also pales to PHP.

Another problem Python suffers is its lack of true multi-threading due to the global interpreter lock. When running multi-threaded applications a lock has to be acquired by a thread before it can access any objects. That means that Python can only scale by running multiple instances of the interpreters rather than the Java approach of using multiple threads.

Differences between RoR and Django

One important point is that Django currently only supports Sqlite, MySql and Postgres (although support for Oracle has already been submitted to the project), whereas Rails supports virtually all major relational databases.

Django’s framework can support large, high-volume websites and provides built-in support for a variety of caching options, whereas in Rail's caching is not as flexible. With Django multiple caching backends are supported (in memory, memcached, or DB) coupled with supporting caching at multiple levels – either for a whole site, a specific page or fragment (like Rails), or even a specific object.

Unlike Rails, Django doesn’t allow for management of website transactions, although the feature may be added soon by the community.

Django is strong in providing pluggable applications that can integrate smaller Rails-style applications with larger Django projects, as demonstrated wit Lawrence Journal World, when it added new parts incrementally without deploying the entire site.

Sam Newman, author of the article, A Comparison of Django with Rails, recommends:

If you are developing a simple (in a domain model sense) application where you want to use Ajax to liver a great UI, Rails is probably for you. If however you want to develop an entire site with different types of applications within it – then Django’s plugable applications and general approach might be what you're after. Equally, the better user and administration side of Django favors portal style applications this is something you'll have to do yourself if you want to use Rails.

Future Directions and Conclusion

In retrospect, today's most popular platform and frameworks were created to fulfill immediate short-term goals of the creator. For example, PHP creator Rasmus Lerdorf developed a Perl/CGI script that enabled him to know how many visitors were reading his online resume. He gave away his toolset - dubbed PHP (Personal Home Page), and the clamor for the toolset propelled him to develop the language into a full-fledged version. Similarly, Ruby on Rails creator David Heinemeier Hansson created the platform to facilitate his work in developing BaseCamp for his web design company, 37Signals. Because of the creators' myopic goals and partial views at that time, the frameworks and platforms were initially biased to become tools that address needs of a certain segment but fail to fulfill others.

Key Framework Features

As for future work, there is a conceivable opportunity in the web development space for a framework that will keenly address all of the most significant needs. These significant needs overlap among different user groups, from small business to large enterprise. This can be accomplished by devising a new framework from scratch or improving upon an existing framework -- the latter of which would lead to faster adoption.

The most popular platforms and frameworks among today's most popular websites - namely Ruby on Rails, PHP, and Python-- do not have a comprehensive integrated development environment (IDE) like that of Microsoft Visual Studio. Although each language comes supported by an environment for the language per se, there isn't a comprehensive IDE that understands all web development languages like MySQL, HTML, XML, CSS, Javascript, etc., servers, databases, and common web browsers. Moreover, it should integrate well with a web server and database so that when hitting debug a web server would start and prompt immediate feedback to the developer. The comprehensive IDE will be a significant factor to a faster development cycle and wider adoption. Even adding a light SQL DB that can be used on development machines with no configuration for most tasks would be a tremendous boost.

Since ORM makes interacting with a database efficient, we recommend that the framework make ORM more robust, expressly to provide support for ORM on multiple databases. Presently, the two frameworks that are using ORM is Ruby on Rails and Python's Django. First, while ORM prevents security vulnerabilities that would otherwise be created by improperly writing MySQL code (as often seen in PHP), scaling issues occur when the web application becomes popular and must sustain itself upon multiple databases. Popular social networking application, Twitter, has encountered problems scaling ORM with multiple databases and published their experience travailing those issues. In response, Dr. Nic released a facility that allows Ruby on Rails to talk to more than one database at at a time. Second, other common scalable database architectures should be supported such as allowing for single read and multiple writes. Third, ORM should provide for compound keys, or in other words, multiple columns for the key of each table. Compound keys is paramount in almost every application such as Reddit.com. For example, Reddit.com is a site that would likely implement a voting table which has a primary key that is a combination of the user and item the user votes on, thus preventing the user from casting multiple votes on the same item. Furthermore, ORM should have wide database support, which is a lacking of Python's Django, else extra work is required on the developers' part manually configure and support a specific database which isn't covered by the initial framework.

As Joshua Schachter, founder of del.icio.us, suggests, Unicode and internalization support is a significant aspect of web programming. Current platforms such as Ruby on Rails and PHP lack such support and have led to developers writing workarounds in order to ensure their site is read by a multi-lingual audience.

Another feature which has proved useful in many frameworks is the ability to create modular, pluggable code. Examples of this concept can be seen in ASP.Net's Controls and Django's Applications. When these pieces of code are developed with portability in mind, they can be used across many different projects with no customization and very little configuration. For many frameworks, useful modules such as user registration are created externally in an open-source environment. When these modules reach a threshold of popularity, they become officially included in the frameworks. Django, for example, has dedicated a portion of its library, django.contrib to user contributions.

Finally, for frameworks that are backed by slower languages like Python and Ruby, a Just-In-Time (JIT) compiler could be developed to help optimize the code for better execution times. Psyco, a Python library, does this by using run-time data to optimize functions for the data types they are most likely to see, removing one of the most important bottlenecks in Python's interpreter. The JIT would compile pages after they had been changed and cache the compiled version until the page is changed again, resulting in faster rendering times.

Seamless Upgrade

As we've seen, one of the biggest advantages dynamic frameworks give to developers is the ability to quickly and easily get a new site up and running. By removing the need for massive configuration files and design choices that have little impact on the final product, these frameworks allow developers to design quickly and iterate rapidly in testing with users. We have also seen that agile frameworks are lacking in features to support scalability, and some people believe that a dynamic language cannot be used for serious development in teams larger than 5 people. These fears of scalability problems down the road have caused some developers to choose larger frameworks, even for prototypes. This also leads them to either spend more time in initial development, restricting the amount of user feedback they are able to get, or take shortcuts in languages that do not inherently encourage good design practices, leading to unmaintainable code that will be difficult to scale later.

A better option, and open area of work, would be to allow developers to create prototypes in an agile environment, with a promise that when they reach the limits of that framework, tools will be available to let them easily upgrade to a more scalable framework. There are two possibilities for how this can be implemented.

The first is to take a large, scalable framework, such as ASP.Net and pare it down to a necessary subset of the language, removing many of the time-intensive configuration options .Net allows for and its boiler-plate code, such as class declarations in code-behind pages. Next, the development environment would be modified to remove as many compilation errors as possible by making the interpreter perform a best-effort execution when a page is executed and only throw an error when necessary. This will be easier to do with a smaller language because there will be less errors to account for and would allow developers to focus more on design of the site and less on syntax. When the limits of that language are reached, the developers can expand it to a full language, with little change required to the code, most of which could be augmented programmatically by tools. An example of this concept are the languages Lisp and Scheme. Scheme is a minimalistic dialect of Lisp that can be relatively easily converted if Lisp's features are desired.

The second option is to develop a compiler that can take an existing language and framework, such as Django or Ruby on Rails, and compile it into PHP, JSP or ASP.Net. Clearly, if Java or the CLR were chosen, the compiler must be able to reconcile the dynamic typing of Ruby and Python and form correct statically typed code. Fortunately, this can be achieved fairly easily with some work on type inference and variable substitution. Also, a mapping between libraries must be made by the compiler. This would be the biggest challenge, as few APIs are documented in such a way that a translation could be created automatically. Most likely, much of this would have to be done by hand, though it might be possible to use techniques from Natural Language Processing to help with the conversion. The biggest disadvantage to this technique is that it forces development teams to switch environments and languages, which may make highly productive developers much less productive for a time as they learn the new language.

An interesting example that applies to both of these techniques is IronPython. IronPython is an implementation of the Python programming language built on Microsoft's Common Language Runtime. It is fully compatible with standard Python, but gives developers access to .Net classes. Though there is only one example, it has been shown that Django can be run on IronPython. A combined approach could be taken by developing a compiler to convert the non-CLR parts of IronDjango and convert them into ASP.Net code.

Conclusion

While the improvements we suggest would amalgamate to a very strong ideal platform that would address the needs of most web developers, we will nonetheless consider the current state of web development. Currently and despite lofty goals, there isn't a platform and framework that is a resoundingly strong choice over alternatives. Back-end platform choice, we acknowledge, will always be one of the most difficult decisions among new and seasoned web developers. However, if little progress is made, we hope that our comprehensive report will clarify the advantages, disadvantages, and scalability issues of the most popular web platforms and frameworks today and help new web developers make a prudent decision that meets the needs for their project and situation.

Resources

General

ASP.Net

JSP

PHP

Ruby on Rails

Django

Other

Milestones

Retrieved from "http://cs343-spr0607.stanford.edu/index.php/Projects:Tyler_Hicks-Wright%2C_Diana_Thai"
Last modified June 14, 2007 6:04 pm / Skin by Kevin Hughes
MediaWiki