As I’ve explained in the first posting of this small blog series, we have been looking for an ideal web development stack for a new installable product. We looked at the most popular development stacks, platforms and frameworks before eventually deciding which one to use. I will try to summarize the pros and cons of the stacks we evaluated and explain how we’ve come to the final decision.

Photo of books about web development

We aren’t experts in all the different frameworks and platforms we evaluated and there are probably some details we got wrong. Feel free to correct us by leaving a comment. So without further ado, here are the pros and cons of the different development stacks in regards to installable web applications:

  • Java (including Grails and Spring)

    Java and the various frameworks such as Spring and the dynamic counterpart Groovy combined with the Grails framework qualify in many ways to be the perfect web development stacks for installable applications. The Java platform is very mature and has very good support for cross-platform and cross-database development. If you use frameworks such as Spring, you also benefit from the MVC pattern and from enterprise features and libraries. Java also isn’t going anywhere and it’s safe to say that Java will be available for the next 10+ years and probably a lot longer. Unicode support is also excellent, which is rare for cross-platform development stacks.

    However, one of the biggest drawbacks of this platform also made us decide against using Java: deploying Java web applications is complicated and scares the hell out of us. We wouldn’t feel comfortable having to support deployment scenarios with all the different available Java application servers out there, which you need to run a Java web application. The need for an application server such as Tomcat or JBoss is a serious disadvantage, especially if your customers aren’t experienced with installing and configuring such a solution.

  • Ruby on Rails

    Ruby on Rails is a modern and productive web development stack and framework. Using Ruby as the programming language of choice, it’s best known for the MVC architecture and the well-integrated ActiveRecord object-relational mapping system for database access. Ruby on Rails also emphasizes the convention over configuration concept, making it very easy to get started developing web applications. Rails also comes with reasonable support for multiple database servers, but is usually used with MySQL and PostgreSQL.

    Recent versions of Rails also improved the support for Unicode and UTF-8 encoding, making it more suitable for applications that are used by users from non-western countries. Rails is usually deployed by configuring a Mongrel cluster (which is easier than it sounds) and using a front-end web server such as Apache, nginx or lighthttp for static content serving and load balancing the different Mongrel processes. Although setting up a run-time environment for Rails applications is still a lot easier than for Java web applications, it can still be problematic for customers who have no experience with Rails and/or Unix environments.

    This leads us to the big problem with Rails: the support for Windows servers is miserable. Because most Rails applications are developed, tested and deployed in Unix environments, either for hosted web applications or in-house intranet applications, supporting Windows servers isn’t an important issue for the Rails team or developer community. However, if you are trying to sell an installable web application to typical companies, Windows servers are still extremely popular for internal application and workgroup servers. And if your potential customers are used to running Windows servers, you better make sure that your solution works flawlessly in this environment.

  • ASP.NET

    ASP.NET is a good choice for many installable web applications. It’s reasonable easy to deploy an ASP.NET web application on a Windows Server with IIS and most companies (and potential customers) already have such a server running as an internal application server. The Unicode and localization support is also top-notch and if this is one of your most important requirements, you should definitely consider going with this development stack.

    Another big plus for ASP.NET is the strong developer community with countless of blogs, books, websites and forums. The rich offering of user interface controls, libraries and development tools for the .NET platform in general and ASP.NET in particular by third-party vendors is also unmatched. However, ASP.NET also has its problems. ASP.NET Web Forms really encourages mixing application logic with the user interface code, which can result in badly designed applications and hard-to-maintain code. The abstraction in ASP.NET Web Forms that’s supposed to make web development easier for Windows desktop developers makes the development stack hard to debug and overcomplicates things.

    Experienced ASP.NET developers try to workaround these limitations by using patterns such as MVP or MVC. Especially Microsoft’s new ASP.NET MVC framework is an interesting alternative to Web Forms, as it encourages the separation of business logic, data access/validation and user interface code and makes it easier to build a maintainable application. This leaves us with the biggest drawback of ASP.NET: the lack of cross-platform support. Sure, there’s Mono, an open source .NET implementation that also supports ASP.NET. But while it’s definitely a nice option to have, it’s not widely used and I personally would not consider it to develop cross-platform web applications at this point.

  • PHP

    PHP is arguably the most used web development programming language, despite it’s many technical limitations and problems. The main reason PHP has become so popular is that it’s extremely easy to use and that it’s supported by virtually all web hosting companies. Developing an PHP application without using a decent application framework will most likely lead to an unmaintainable code base, however. The language itself, although explicitly designed for web development, doesn’t come with a (MVC) framework and doesn’t help with separation of concern in any way.

    One of the technical limitations is the lack of Unicode support. While most development stacks have quite good Unicode support by now, PHP’s support for non-western characters is still very limited and if you plan to support most server configurations and multiple databases, it’s basically non-existent.

    Luckily, there are quite a few available PHP frameworks to remove some of the mentioned limitations such as the Zend framework, CakePHP or CodeIgniter. Using one of these frameworks makes it a lot easier to write maintainable applications and also provides you with often needed functionality not found in PHP itself, such as a database abstraction layer.

    Of course, PHP also has its good sides. Applications written in PHP are very easy to deploy and work on most operating systems and server configurations. Even Microsoft is working hard to improve the PHP deployment experience on Windows and IIS, as many popular web applications such as WordPress are written in PHP. The great cross-platform, cross-database support combined with the ease of deployment and available frameworks make PHP a good web development stack, even though it’s not the best technical choice.

Having evaluated the above mentioned frameworks and having looked at the pros and cons of each development stack, we have come to the conclusion that PHP together with a lightweight framework such as CodeIgniter is the best choice for an installable web development stack, at least today. Yes, from a technical standpoint, PHP is less than great. The ability to easily deploy and run a PHP application on most server configurations, however, easily outweighs its limitations. One drawback that really made us think twice before deciding to go with PHP was the lack of proper Unicode support. Unicode support was originally a really important requirement to us, but we decided that we can do without Unicode support for a few more years until this problem will hopefully solve itself (with better Unicode support in PHP).

You might also be interested in our reasons to choose CodeIginiter as the PHP framework for our application. The great thing about CodeIgniter is that it’s a really simple framework. Although CodeIgniter only offers the most basic features and you have to implement advanced capabilities such as locale or authentication support yourself, this simplicity makes it really easy to understand the entire code base in a very short amount of time. So even in the unlikely case that we needed to fork this framework because the authors stopped supporting it, we could easily improve and add features to the existing code ourselves, something that is not really feasible with most other frameworks and stacks out there as they are often too complex.

Some months into development we are still happy with our choice. The application is coming along nicely and PHP and CodeIngiter have proven to be a solid development stack for an installable web application so far (of course, the real challenges come when customers deploy our application in many different hosting environments). Our choice of a development stack would most likely be different if we were building a hosted solution where we could control every little aspect of the server environment. But because our customers will have to deploy and host our application themselves, PHP and CodeIgniter are a great choice for us.

Now before you start your next big thing, make sure to consider all your options, as you cannot easily change platforms once you’ve invested a lot of time and resources.

Related posts:

  1. Choosing a Development Stack for Installable Web Applications: Part I

Found this article useful? Make sure to subscribe to the No bug left behind feed or via email and don't miss our future articles about software quality, performance, usability and related topics. This blog also features the regular Software Quality Digest with links to relevant articles, discussions and other resources.

7 Responses

  1. fas Says:

    I am pleased your are happy with your choice, but you have ignored the strongest part of java deployment — the ability to ship the container with your application, and give your customer a simple double-clicky application. Yes, if your customer is familiar with java infrastructure, you can give them a war file, allowing them to integrate your app with their systems in the way they see fit. If they do not, however, you can always embed something like jetty in your application, giving them what appears to be a single application to launch — simpler for a customer even than even php. It even gives you a nice value-add you can charge for, if that is your model.

  2. Dennis Gurock Says:

    I agree that this is a nice way to deploy Java applications, especially because a large part of our customers will most likely not have any experience with Java application servers. I still see two problems with this though:

    1. If there are any kind of problems with such an installation, it’s not very easy to debug in my experience (e.g., it’s not very transparent what’s causing the problems). Customers would rightly demand that we support them with this and I’m not sure if we are prepared to provide support for this.

    2. I’m sure this approach is working very well with Windows, but does it work well with all the different Unix/Linux environments? In my experience, all the dependencies are hard to satisfy (specific library versions etc) in an Linux environment if the software/packages don’t come with the distribution itself.

  3. Jamie Says:

    Interesting article, thank-you for sharing. I would have made the same choice, most people with a shred of interest in web applications have deployed a PHP Web Application at some point and will be confident in doing it again.

    Java is probably most comparable in terms of heterogeneous environment deployment capabilities but for me personally, having to set-up and support a Tomcat/JBoss server would put me off.

    Frameworks tend to be entirely a matter of preference but what did you think of the Zend Framework? Too heavy/complicated for your purposes?

  4. Tim Anderson Says:

    Nothing wrong with PHP; but I think you dismissed mono too readily. I’ve been using it for ASP.NET and been impressed.

    Tim

  5. Yogi Yang Says:

    I would recommend PRADO instead of CodeIngiter. It really helps in separating UI from actual code in PHP and it performs really very well.

    I am yet learning PRADO but from what little I know about it I really like it and would use it for all my future development as it gives me Event base programming feature to which I am used to being basically a VB & Delphi developer.

  6. Dennis Gurock Says:

    @Jamie: we have been using CodeIgniter for other projects in the past (DelphiFeeds.com actually) and already know it well, so we decided to go with it when we selected the PHP platform. The main advantage of CI is that it’s very lightweight, something that isn’t necessarily true for most other frameworks.

    @Tim: I’m sure mono works well in many situations. But because we were looking for ease of deployment and especially compatibility with many environments, I’m not sure mono would have been a good choice for us (e.g., mono isn’t supported by many hosting companies, which would put us at a serious disadvantage with customers who already use standard hosting offerings). Another thing that would scare me a bit are subtle differences in the Microsoft and mono implementations of the BCL and CLR. I’m not sure how justified this concern is though.

    @Yogi: The PRADO PHP framework looks interesting. From a quick look, it looks like a mix of ASP.NET web forms and ideas from the Delphi VCL. However, I don’t think event-driven development is the right way to go for web applications. The MVC approach makes much more sense IMHO, so I would really recommend taking a look at an MVC framework, even if it might be bit harder to learn at first.

  7. fas Says:

    This must be a difference in experiences, then, because, in my experience, it is far easier to debut issues in java than php.

    Yes, it works fine in *nix environments.