I see this all the time: “I’m building a website, but I don’t know what the best technology to use is? This guy says PHP, that guy says Ruby. What’s better?”. While there are definitely a handful of developers that will quickly jump to share my point, there are far too many that have biases for certain technologies and will quickly defend them with a bullet list. Avoid those guys with biases – their tool belts are smaller.
Some things to Consider
Choosing the best technology really depends on what it has to do. You wouldn’t hit a screw with a hammer? Well, you can… but you shouldn’t. Choose your website technologies based on what it has to do and what it takes to create and support it. Some things to consider:
- Budget and Market Cost
- Continued Support and Development
- Scalability – meaning, when new problems arise, will the solution be able to meet and defeat those problems?
- Demographics – how well does the workforce powering your technology cater to your product’s needs?
Say, perhaps, you want to build a small website to advertise a product or yourself. It needs a few dynamic options, like a contact form, and maybe a shopping cart. I highly recommend exhausting service oriented solutions before going custom.
You could quickly find a web developer, blow a few hundred bucks, spend several weeks customizing and tweaking, and there you have it – no real support, you may or may not have a scalable back-end to manage it, and future expansions become expensive. Or…
You could throw up a wordpress.com site for your landing page, link it to an inexpensive shopping cart service like e-junkie.com, and have significantly more bang for FREE by gaining access to thousands of plug-n-play plug-ins to extend your site with gallery applications, feeds, sharing tools, SEO management tools, as well as all the support of a service like e-junkie on call for your every e-commerce need.
See where I’m going with this?
More Complex Project
Lets envision you need something more complex than a personal page. How about, a niche social network? You want your own version of Myspace, and white label solutions just don’t have what it takes. So you’ve raised thousands of dollars in angel investment, got your business plan, and are perplexed by the question of this post, “What technology?!?!”. In this case, I would suggest considering the labor force and scalability behind each technology in correlation to what that is going to mean for your budget.
While PHP has a huge work force, and many success stories, the language itself is rather controversial, as are philosophical differences in it’s “thousands” of frameworks. A handful of frameworks are well-known, such as Symfony, CakePHP, Zend, CodeIgniter, KohanaPHP; though being an expert level PHP developer, I can tell you that many of the PHP frameworks, well, quite frankly, suck. It’s new and easy to learn, and bloated with newbies making decent money, but not deploying consistent theory or solid code. This is not always their fault, PHP lacks as a new language.
PHP also brings a lack of legacy support with each new version. Consider the lifespan and size of your project. Does this site need to run code for several years? How difficult might it be to migrate old code to new versions of the language as they are released? Just an example: When PHP5 released, it left thousands of web hosts outdated and incapable of updating without major financial and time expense due to the fact that PHP5 had changed syntax to introduce OOP, which broke PHP4. To simply upgrade to PHP5 would break millions of websites without those webmasters first learning the changes in the language and making updates to their scripts. Such scenario meant serious problems for web hosts that wanted to support latest technologies for new clients while maintaining legacy technology for existing clients. PHP6 bodes better, but will still admittedly face similar problems.
As for the workforce, it’s just too easy to get into PHP. The skill level required to create a PHP site is significantly less than that of other languages. It’s the nature of PHP – Hypertext Pre-Processor, which, to many, is code (pun intended) for HTML on steroids. Your average MySpace fanatic knows a bit of HTML these days, PHP is just the next informal step for many. If you can find a skilled Object Oriented Programmer (OOP) – you’re well off, but the work force powering PHP is predominately less read into computer science theory and less likely to deploy best practices. Why should they? – that’s all part of the beauty of the language.
Not to say a quality website can’t be developed in PHP, but I haven’t worked with any particular PHP Framework that really nailed it for me as a perfectionist. You’ll find many like me in the PHP work force: “just another php framework author”. There seems to be an abundant number of us that find it difficult to produce quality code in popular frameworks, causing us to resort to building our own. Mine is coined Typhoon.
Though, don’t get me wrong, I LOVE PHP and have developed numerous websites in the language. I also look forward to the great new benefits in Version 6. When you come down to picking PHP for your choice as a platform tool, just be sure the scope of your project is small to medium sized, speed of development being important, and ongoing support of the project being minimal. Past that, the coding standards recognized by the PHP community are just too flexible and inconsistent for me to feel comfortable spending significant time and expense on a bigger PHP site.
“Developed four years ago by a fast-moving online-news operation, Django was designed to handle two challenges: the intensive deadlines of a newsroom and the stringent requirements of the experienced Web developers who wrote it. It lets you build high-performing, elegant Web applications quickly.” – from the creators of the Django Project
Now Django is a cool framework built in the Python language, and perhaps the premier web framework of Python. Unlike PHP, Python is a general utility language. It’s usage can be found in many aspects of computer science from desktop applications, to video games, to web development – and it has been around awhile.
Lets keep in mind the quote above though. It was developed by-and-for the newsroom. As such, it caters VERY well to companies that have a similar infrastructure. While you can develop many applications regardless, that fundamental purpose gives the framework an overall flavor that may not be quite as flexible in every problem domain.
The built in content management system (CMS) feature of Django is really quite a gem. It’s effective at allowing developers to rapidly generate applications for non-technical people to manage. Would I use it for a social network? Probably not as my first pick. Would I use it for news syndication site? Hell yes.
Python has been around since the early 90’s and has had sufficient time to incorporate advanced computer science theory and stabilize. The workforce powering Django applications is also significantly more well-read than the PHP workforce ( I say this loosely, of course ), as the Pythoon workforce has been around longer in general.
Django can sleep safe at night knowing it was built on a stable language that doesn’t anticipate significant change year after year, making it a great platform for websites requiring long term support and development.
Ruby on Rails ( Soon to merge with MERB in Rails 3 )
Talk about some BUZZ! I’ll admit I did not want to learn Ruby on Rails at first. I love learning technology, but when Rails was just gaining it’s hype, I was getting deep into PHP and tended to stay in the PHP world. Mistake at the time, on my part.
Rails identifies itself as a “web framework”. Unlike Django, Ruby on Rails was developed to tackle many more of the standard problems developers face on a much broader sense of web development. This by itself should not be translated as “Rails is the creme de la creme” for your web project, but it does make it a strong candidate to initially consider.
When to Consider Rails
- You have a project with many developers, possibly several contractors that will come and go as needed.
- You need fast scalability and flexibility due to a multi-faceted problem domain, ie: niche social networks tend to start simple and then tack on lots of complex features.
In terms of computer science, 9.9999 times out of 10, problems we face in development are problems we’ve answered time and time again, either in theory or practice. Thankfully, the Rails community innately conforms to the DRY Principle ( don’t-repeat-yourself ). The community also drastically alleviates extra invention faced by developers, simply by embracing, building upon, and reinforcing community accepted solutions. The now famous Rails motto: “Convention over Configuration” sets a tone where the community expects eachother to follow a standard set of approaches versus relying on the individual’s limited resources to reach the same conclusions others have already reached.
Not only is it a motto, it’s an obstacle for “do-it-my-way” programmers, as it’s rather difficult to make a Rails application without doing it the “Rails way” – things will just not go smoothly if you attempt to break standards. As developers tend to think differently about the same problem domain, Rails lends itself as a great framework to conform the result of their different approaches to the same represented solution. In identifying conventions and standards, developers of the rails community spend significantly less time “re-inventing the wheel”, and more time knocking out features and drinking beer.
It’s memory intensive/innefficient. MERB is merging with Rails 3 – which promises to improve performance, though in the meantime, I have several Rails applications running for small sites where I should have deployed PHP, I’m noticing I’m low on memory due to such, which ultimately costs me more money to keep my servers up to par with my Rails demands.
Windows users tend to have a more difficult time with Rails whereas the PHP community has gone through a few more lengths to make development in windows fairly painless. Rails is significantly is better to develop on unix-based platforms, like Linux and Mac. Windows users will need to go through extra hoops to keep up with dependencies largely created and maintained by the unix-based users – though, if you’re a serious web programmer using windows as your primary platform, you should consider weening off sooner than later anyways.
Rails isn’t THAT light weight. It incorporates a lot of functionality and sub framework patterns that you just may never use on some projects. Again, Rails 3 promises to improve in this area as well.