Web 2.0 startups. Choice of server-side technology.

Introduction

If you were to rewind your startup's lifecycle to the very beginning, you would probably find that an exciting idea was born first and everything else came second, including the underlying technology choice. Still, at some point technology decision had to be made, and this decision was a crucial one. It may have created many risks for your fledgling venture. In hindsight, these risks could have been removed from the very beginning, had the technology choice been the right one.

This paper is dedicated to people who are stakeholders in early-stage web enterprises - and who have reached a point when core software technology for their product has to be chosen. This paper is for web startup CEOs, CTOs, engineering teams and all those who are involved in the technology decisions for their products and services.

Practice shows that defining the right software stack for your product is often not an easy choice - there are many options out there and supporters often claim that their technology choice is the most optimal. We at Cogniance are often asked for advice on this topic. Having spent 4+ years in a startup environment we have developed a rather strong opinion that some technologies are better suited for early stage startup companies than others, and this paper accumulates this knowledge and experience. It aims to help startup entrepreneurs and technologists address technology-related questions effectively and make the right decisions.

Is your startup a Web 2.0 one?

So, what is Web 2.0 and what do we mean by a "Web 2.0 startup"?

As "classically" defined by Tim O'Reilly, "Web 2.0 is the business revolution in the computer industry caused by the move to the Internet as a platform…" This definition is quite vague as it is, so let us try to expand it into more tangible statements. Historically, the term "Web 2.0" was coined to demonstrate a revival of web community, business and technologies after the burst of the Y2K bubble. With some simplification, Web 2.0 describes a transition to second generation of the World Wide Web, which is characterized by:

• Moving away from static webpages to dynamic and shareable content.
• Development of tools that let users collaborate and share information online, such as social networking sites, wikis, communication tools, folksonomies, blogs, podcasts, etc.
• Broad introduction of user-generated (also known as cloud-sourced or crowd-sourced) content.
• Emergence of a new set of web technologies that enable abovementioned trends. Key such technologies are Ajax, RSS/Atom, REST/SOAP.
• Introduction of SaaS/SaaP (software as a service/platform) approach. This approach supports the concept of "web as a platform" and is independent of underlying operating systems.
• Success of a new set of web-based business models, such as advertisement, premium services, SaaS.

Getting back to O'Reilly's views on Web 2.0, here are the four levels in the hierarchy of Web 2.0 sites:

Level 3: The application can ONLY exist on the net, and draws its essential power from the network of people or applications. These are applications that harness network effects to get better the more people use them. EBay, craigslist, Wikipedia, del.icio.us, Skype meet this test.

Level 2: The application could exist offline, but it is uniquely more valuable by being online. Flickr is a great example. You can have a local photo management application (like iPhoto), but the application gains remarkable power by leveraging an online community.

Level 1: The application can and does exist successfully offline, but it gains additional features by being online Google Docs & Spreadsheets and iTunes are good examples.

Level 0: The application has primarily taken hold online, but it would work just as well offline. MapQuest, Yahoo! Local, and Google Maps are examples in this category.

For the purpose of this white paper we will define an application as Web 2.0 app if it matches principles above and falls into one of 4 levels described.

What requirements are important when choosing technology for Web 2.0 startup?

Before considering and comparing existing options we have to clearly define comprehensive requirements which are important when choosing a technology stack. As our experience in Web 2.0 startup environment shows, the following requirements are most important for consideration:

Speed of development - this parameter defines how quickly, easily and with what level of quality you can implement typical features of your web solution - such as user registration and profile management forms, RSS and podcast feeds, browser-based logic etc.

Performance - this defines the degree of scalability and responsiveness of your solution.

Level of adoption by the industry - this factor defines how much of an industry standard given technology is. When defining this criterion, things such as number of well-known web products built on this technology, size of the supporting community, availability of documentation and other learning materials should be taken into consideration.

Learning curve - a level of effort and time required for the project team to develop expertise with this technology. The less known the technology is, the higher the learning risk would be.

Cost of ownership - this variable defines total cost of ownership and includes initial acquisition costs, operating and maintenance costs, and (possibly) switching costs.

After comparison criteria are defined, various technology stacks can be considered.

What options are there on the market?

Web technology market is quite mature - there are both new technologies that have recently proven themselves successful and mature technologies which have been available for 5+ years and are still actively evolving. Table 1 below contains a list of technologies that will be analyzed in this paper. Generally speaking, each of these stacks are viable and worth considering – so making the right choice requires a deeper investigation.

Technology	Current version	Technology knowledgebase
J2EE/EJB3	Java 1.6.x, EJB 3.0.x	http://java.sun.com/products/ejb
J2EE/Spring-Hibernate	Spring 2.x, Hibernate 3.x	www.springsource.org, www.hibernate.org
Ruby/RoR	Ruby 1.x, RoR 2.x	www.ruby-lang.org, www.rubyonrails.org
LAMP/Python	Python 3.0.x	www.python.org
LAMP/PHP	PHP 5.x	www.php.net
.NET	.NET 3.x	www.microsoft.com/NET, www.asp.net

Table 1. Key Web 2.0 technologies

Let's provide brief description to each technology platform above.

J2EE/EJB3

Along with Spring/Hibernate stack Enterprise JavaBeans 3 is one of two modern industry-standard Java-based technologies which are very viable options for building Web 2.0 applications.

EJB3 is the technology which is officially promoted by Sun as a framework to be used with Java 1.6. It has evolved out of EJB2 as significantly re-designed framework. For example, its persistence layer is now heavily based on Hibernate ideas, its bean invocation mechanisms are significantly optimized – these are just a few of many improvements. EJB3 works effectively with all modern Ajax frameworks on one hand and with all major databases, including MySQL PostgreSQL, Oracle, MS SQL Server on the other hand.

J2EE/Spring-Hibernate

Being a second strong option of Java-based Web 2.0 technologies, Spring/Hibernate is actively supported and promoted by development community. In many aspects Spring/Hibernate is similar to EJB3 - both of them are built on same J2SE core language and set of libraries and their distinctions become clear on more detailed level of consideration. Detailed comparison between two stacks is available as a separate white paper, but in summary they turn out to be very similar choices, having approximately same marks along all of criteria above. That is why later on this paper considers "compound" J2EE stack instead of separating it to Spring/Hibernate and EJB3.

Ruby/RoR

Ruby/RoR is the technology which was introduced just a few years ago but has quickly gained popularity. One of the reasons for this is the fact that Ruby was created specifically for web development and with Web 2.0 design patterns in mind. Ruby is tightly packaged with Ruby On Rails (RoR) framework, which provides solutions for both web and data layers. RoR is, in its turn, tightly integrated with highly popular and efficient Prototype and script.aculo.us Ajax frameworks. RoR also supports all major databases including MySQL.

LAMP/Python, PHP

LAMP (Linux, Apache, MySQL, one of Python/PHP/Perl) is a well-known and proven solution which has been available for a number of years but is still "young" and worth consideration as all three languages/frameworks are being actively developed and supported by large community. Still, LAMP stack with Perl as programming language and environment is not included into the scope of this article as we believe Perl is somewhat behind the rest of considered options. One of the most important reasons for this omission is a significantly larger popularity of related Python and PHP stacks. Current evolution of LAMP extends it to using Lighttpd and Nginx web server instead of heavy Apache, and using powerful open source PostgreSQL database as an alternative to MySQL.

.NET

.NET is a universal development platform from Microsoft which is broadly used for building web solutions. Still, majority of these solutions are enterprise level. There are just a few large-scale web startups using this technology for their core systems, but these startups are really popular. Hence .NET is also one of the options considered in this paper.

Option analysis and comparison

Next, we comparatively each of technologies above against specified requirements.

1. Speed and quality of development

J2EE

As mentioned above, both EJB3 and Spring/Hibernate frameworks are based on well defined and broad set of design patterns, have similar solutions to specific problems like memory usage optimization, processing speed optimization, web workflow management, data caching, security etc. Java frameworks are very universal and built to be equally suitable for broad set of applications –from real-time embedded software to web portals. This is both strength but a weakness at the same time – being universal, Java frameworks are comparatively slow in development speed, despite the fact that both EJB3 and Spring/Hibernate have specific web sub-frameworks which provide high-quality web applications. EJB3 has JSF as its main web framework while Spring relies on Spring MVC/JSP as a primary choice. Both JSF and Spring MVC seamlessly integrate with Ajax frameworks.

Ruby/RoR

Created specifically for web development, Ruby/RoR solves typical web site development tasks impressively quickly and easily. RoR has so called a "golden path" - a set of receipts/patterns/software components created to solve the most common problems in web-development. "Golden path" makes a task of creating a simple web site similar to writing "Hello World" app - you even do not have to know JavaScript or AJAX – all related functionality can be implemented directly with Ruby code. At the same time, solving a complex problem with Ruby/RoR may become a real pain – you have to dive deeply into RoR code and oftentimes implement lots of workarounds to get what you need. In other words, Ruby/RoR is fast in development speed in case of standard or routine tasks, and medium-to-slow speed in case of complex tasks , such as real-time processing, high computing power processing, extra heavy-load management, etc.

LAMP/Python

Python, backed by a set of frameworks like Pylons, Django, Turbogears provides a powerful stack for web development. Django is faster in the beginning, since it provides some features like ‘admin page' out of the box. Pylons and Turbogears are slower than Django, but more flexible and very powerful tools for web development. Python has one of the greatest choices of libraries for all use cases, so it's much easier to solve complex and non-standard problems. Also due to the specifics of the language, python code is much less verbose and very easy to read, which gives an advantage in both speed and quality of the development.

LAMP/PHP

PHP had improved crucially when its 5.x version was released – with 5.x version it had acquired standard and well established OOP/OOD features which raised it to the same level as the rest of modern programming languages. When backed by such frameworks as Symphony , Zend Framework , Drupal and several efficient template engines like Smarty , Savant and FastTemplate, PHP 5.x becomes a choice clearly worth consideration. One of the strongest points of PHP is PEAR / PECL mechanism. PEAR is a framework and distribution system for reusable PHP components (which are called Extensions), and PECL is repository for PHP Extensions based on PEAR. Thanks to PEAR/PERL, PHP community received many extensions that allow doing many things in different ways. And yet, speed of development of non-trivial web solutions in PHP is somewhat slower than that of Ruby/RoR, Python and .NET.

.NET

.Net framework was very "developer friendly" from its very inception. Starting with its first version 5 years ago .Net provided comprehensive set of development tools, libraries and patterns. With its ASP.NET technology .Net provides an impressively quick way to build web applications. Yet, as discussed below, .Net is tuned for usage with a very narrow set of technologies and software, from operating system, which is only Windows OS, to web server software, which isonly Internet Information Server.

Table 2 below provides benchmarking of "speed of development" parameter for technologies under consideration. Here and in all following benchmarking tables 10 is the highest mark, 1 is the lowest.

Technology	Speed of development
J2EE	7
Ruby/RoR	10
LAMP/Python	9
LAMP/PHP	8
.NET	9

Table 2. Speed of development. 10 is best, 1 is worst

2. Performance

J2EE

Java has undergone development of six major versions during its 13-year history. As a result, its performance has been tuned drastically, and for most applications it is practically close to performance of native applications (those that run outside of virtual engine). In additional to strong performance of the Java core, there is a number of clustering solutions like Hadoop which help to handle scalability and heavy load tasks. When real-time application development is being considered as part of Web 2.0 solution, Java becomes a best choice.

Ruby/RoR

Ruby performance is still one of its weakest points. Ruby is quite slow itself, and the way Ruby code is being interpreted when loaded into web server environment adds to performance deterioration. Although often negligible for small-2-medium web solutions, performance problem becomes a real challenge for big web portals working under heavy load and especially for real-time processing tasks.

LAMP/Python

Despite the fact that Python does not use JIT techniques, web applications written with Python are usually faster than those written in Java. The major reasons are Python's heavy usage of C/C++ on the library level (for example when you resize an image or parse xml files or connect to the database) and that Python WSGI stack is much more lightweight than J2EE servlet specification implementations.

These factors combined with numerous examples of high load web application like YouTube written with Python make Python platform a very decent choice for high-performance web applications.

LAMP/PHP

Although PHP itself is a little slower than Python versions 3.x or below), its actual performance in web applications depends strongly on LAMP configuration being used. In fact, assuming optimized configuration of all LAMP components, PHP is a fast run-time environment for web applications. Different PHP accelerators can offer significant performance gains by caching the compiled form of a PHP script in shared memory to avoid the overhead of parsing and compiling the code every time the script runs. Still performance of many PHP frameworks (like Symphony) is slower than that of RoR and Python frameworks.

.NET

ASP.NET platform is quite heavy as it relies on multi-layered stack of different environments. Compared with competing technologies ASP.NET is slower under heavy load conditions.

Table 3 below provides benchmarking of "performance and scalability of Web 2.0 applications" parameter for technologies under consideration.

Technology	Performance and scalability
J2EE	9
Ruby/RoR	8
LAMP/Python	10
LAMP/PHP	9
.NET	8

Table 3. Performance and scalability. 10 is best, 1 is worst

3. Industry adoption

J2EE

In addition to being a technology of choice for many e-commerce applications in banking, ERP, and CRM, Java is really popular as a web stack and is a core technology for Ebay, AdWords, Gmail, Amazon, hi5, Techcrunch, Flickr, FeedBurner and other industry leading portals.

Ruby/RoR

Ruby/RoR is adopted in thousands of applications around the world. Most prominent of RoR applications are:

Twitter with over 6 million users, Basecamp with over 1 million users, 43Things with over 700 000 users, Odeo and others.

LAMP/Python

Python is also used by thousands of web applications including YouTube, reddit, Yandex and different Google projects.

LAMP/PHP

As of April 2007, over 20 million Internet domains were hosted on servers with PHP installed, and PHP was recorded as the most popular Apache module. Most prominent of PHP applications are Facebook, Wikipedia, Yahoo!, Digg, and Wordpress. Popularity of PHP is added to by the WordPress blog engine, which is very often integrated into Web 2.0 sites regardless their core technology.

.NET

Although there are thousands of e-commerce and intranet applications written in .NET, there're just a few Web 2.0 startup projects written with this technology. Out of these few most prominent are myspace.com and plentyoffish.com with 1.2 billion page views/month .

Table 4 below provides benchmarking of "Level of adoption by industry" parameter for technologies under consideration.

Technology	Level of adoption by industry
J2EE	9
Ruby/RoR	7
LAMP/Python	8
LAMP/PHP	10
.NET	5

Table 4. Level of adoption by industry. 10 is best, 1 is worst

4. Learning curve

J2EE

Although Java is the most mature compared to other technologies under consideration, and there are volumes of information available, Java learning curve is definitely the longest one out of all technologies being considered except perhaps that of .NET. Java language with core frameworks (J2SE) is difficult to master by itself; J2EE platform is even more difficult. The fact that Java frameworks depend heavily on correct and complicated configuration adds additional time to the learning curve.

Ruby/RoR

Short learning curve is one of most prominent and strongest appeals of Ruby/RoR. Ruby/RoR approach systematically puts convention over configuration. Ruby web applications usually follow a "Golden Path" – convention, or "by-default" way applications are configured. RoR is built specifically with less experienced programmers mind.

LAMP/Python

Python was designed as an easy to learn, yet powerful language. It is both easy to write and read the code and this, coupled with the good documentation of the frameworks and libraries, makes learning curve quite short and convenient. Also it is worth mentioning that Python based templating language Mako as one of the best examples in its class which makes writing markup for the web pages a very easy task.

LAMP/PHP

As mentioned above, with introduction of 5.x version PHP has hugely improved its characteristics as an OOP language removing many complaints, including issues with its learning curve. With its plentiful on-line resources, PHP remains a very easy language to learn. Same situation is with its most popular and powerful frameworks.

.NET

Same as Java, .NET has really strong documentation and educational sources support. Yet, as the platform it is quite complicated, and its learning curve is quite long. This is amplified to certain extent by the fact that best educational sources for .NET technology, such as books and MSDN subscriptions are not free.

Table 5 below provides benchmarking of "Manageability of learning curve" parameter for technologies under consideration.

Technology	Speed of learning process
J2EE	6
Ruby/RoR	10
LAMP/Python	8
LAMP/PHP	8
.NET	7

Table 5. Speed of learning process. 10 is best, 1 is worst

5. Cost of ownership

J2EE

Java is based on open-source freeware solutions. Even though there are commercial Java web application suites like WebSphere and WebLogic, they have very powerful open-source free-ware alternatives based on Tomcat and JBoss web servers. Vast free documentation base and open development community makes Java a really inexpensive solution, very well fitted to startup conditions, if an organization can deal with the learning curve issues.

Ruby/RoR

Ruby/RoR is an open-source freeware solution. Due to the easy code maintainability and shortest learning curve, Ruby/RoR is probably the strongest competitor along Cost of ownership dimension.

LAMP/Python

Python code is easy to understand and maintain, programming in Python requires 2-3 times less lines of code (LOCs) than Java or .Net. Since it is mostly hosted on a very popular LAMP platform, it is possible to create high-performance, scalable solutions based completely on open source technologies, dramatically decreasing the operational costs of the web applications.

LAMP/PHP

Being one of the variants of LAMP platform, PHP relies heavily on open-source freeware solutions. PHP is more popular on LAMP platform and PHP hosting is the cheapest option. Further, PHP is an easy language from the point of view of maintainability of existing code and it does not require too big learning curve. Verdict: PHP is a very strong contender from the cost of ownership perspective.

.NET

Cost of ownership is the weakest point of .Net. Microsoft licenses everything - from Visual Studio and MSDN subscription to the MS SQL server, IIS and Windows OS itself. Total cost of ownership can be prohibitive for the majority of startups.

Interestingly enough, PlentyOfFish, which is one of the two biggest startups running on .Net just recently reported that scaling is too expensive for it, which is not surprising.

Technology	Cost of ownership
J2EE	9
Ruby/RoR	10
LAMP/Python	10
LAMP/PHP	9
.NET	5

Table 6. Cost of ownership. 10 is best, 1 is worst

Conclusions

Let's now aggregate and analyze the data we have discussed above.

Figure 1 shows graphical representations of the comparisons above. Especially interesting should be table 7 and picture 2, which represent cumulative data across all requirements.

Figure 1. Technology comparison graphs.

Technology	Cumulative technology benchmark
J2EE	40
Ruby/RoR	45
LAMP/Python	45
LAMP/PHP	44
.NET	34

Table 7. Cumulative technology benchmark. 10 is best, 1 is worst

Figure 2. Technology comparison graph – cumulative data.

Conclusion

Cumulative data across all requirements suggests that currently Ruby/RoR and Python are the best choices for building Web 2.0 startup, with PHP and Java being good alternatives. .Net is significantly behind its competitors and can hardly be a recommendation.

That being said, here goes critically important comment: the conclusion above is made without consideration of knowledge and experience of your current team. If there is an existing engineering team at the time of the project start, and the team is experienced with one of technologies above (or maybe even with some other technology such as Perl, Groovy / Grails or other), then the situation may change dramatically. Simple rule of thumb in this case is: the more your team is experienced with a particular technology, the better the chances that this technology is a good fit for your project. For example if you have a Java team with 3-5 years of experience, it will definitely develop more rapidly and efficiently than a team of junior Ruby engineers with 1-2 years of experience and, taking into account that across all other variables Java is as good or better than Ruby, your choice of preference would be Java. And contrariwise – if you have a Ruby team you would probably prefer Ruby over Python. You may think of your own example.

But if you develop your software with an external outsourcing partner, such as Cogniance, and as a result you have equal access to different skills at uniform costs, then cumulative benchmarking data presented above will definitely help you to make the right choice.

Special Cases

"So what if my Web 2.0 project is very specific – it contains some time-critical processing, or some "heavy-Ajax" front-end or requires extra-scalability?." The answer is: analyze in detail which one of criteria above is most important for you.

Let's look at several examples.

If you have time-critical processing in your system, look closely at performance parameter. If you need native-app like performance Java will very probably be your choice. Next question you will face: should you build the whole web solution with Java or should you implement real-time algorithms in Java and web site in Ruby or Python? Actually this is a question about keeping your technology homogeneous or heterogeneous. Our quick suggestion is: the more homogeneous your technology stack is, the better. In the end it is easier and cheaper to maintain and develop.

Here is another example. You have strict time and budget constraints, and need to build up and run your Web 2.0 solution . In this case Speed and quality of development and Learning curve parameters become critical. Analysis above shows that in this case – it does provide most rapid development and does not require extra-expensive engineers.

Again, if you want to make a decision which is balanced across all factors, Ruby and Python will be two options you will have to consider and very probably the decisive factor will be preferences of the team you have at your disposal – our suggestion is to listen to their opinion and accept their choice, assuming of course that the development process you use factors in risk mitigation techniques, including those related to and driven by technology choice.

Good luck with your projects!

About the author:

Sergii Gorpynich is a CTO at Cogniance and leads Cogniance engineering team . Sergii has 12+ years of experience in software development, working with wide range of web technologies. You may follow Sergii's micro-blog on Twitter, connect via LinkedIn or just Skype him through SkypeId serhiygorpinich.