Choosing an appropriate web development technology for a project or team can be a tricky decision to get right. Framework based technologies have been around for a while and are generally heralded as the next best thing, but what do they offer over the old style scripting languages?
Opinion: why is the Macbook Air a full 300 pounds (600 dollars) more expensive than in the US?
Musing on old school scripting vs. the frameworks
These days us web developers are fairly lucky in that we have many tools to choose from. It wasn't always the case, back in the mists of time there was basically Perl, CGI, ASP or PHP but nowadays the market is much richer and the choices much broader.
I myself can claim to be a competent developer in ASP (both classic and .Net), PHP, Ruby on Rails and Java (thats JSP and servlets, not script or applets!). I've gained these skills through years of jumping from project to project and job to job. I've also gained considerable experience in programming the client (the browser to you newbies) using javascript and Flash. So foolishly I feel I speak from a position of authority on the matter.
What inspires this article is the fact that the agency where I have my day job is currently a Classic ASP house. I myself prefer PHP or Ruby but the team is just not skilled in these technologies so to stay productive we maintain the status quo. Eventually I would like to move the team to .Net (in particular the new MVC framework) but I can't help wondering what real benefit this will deliver over the short and long term.
I want the goodies associated with the .Net framework including the non-tangibles like better application maintainability and data access/validation tools and techniques. But by the same stroke I don't want to bog down the team for a couple of months learning vastly more complex tools to do basically the same thing as they were already doing. Its not good business.
Classic ASP's sparse and basic nature is its strength for us. With a little more planning and basic setup we can bend ASP to do 99.9% of everything we need it to, and on those few occasions we can't there is always a COM module or a ASP.Net script that can.
I can't help thinking that to get the best out of .Net or Ruby you have to buy wholesale into the .Net or Ruby way of doing things. This might provide you with large productivity gains and/or less code but I feel that you can loose flexibility. You can also find yourself spending more time learning the API's and frameworks than actually getting work done, especially when you can't do something in the framework's preferred way. There always seems to be tradeoffs.
So bigger is not always better. There's still life left in ASP, and PHP is enjoying a bit of a resurgence recently with large scale deployments such as Facebook, so its clear these technologies are not going away. Even Microsoft is improving its support for PHP on IIS which is totally out of character and perhaps an admission that providing everything including the kitchen sink in your API isn't the best way to win over developers.
From this I come to my conclusion. If you need to build a big project where maintainability and functionality are key then you need a sledgehammer like .Net and more importantly you need to the skills in you team to use it correctly. If you're not building a big project and your team are already happily using PHP or ASP then there's no need to change, just get your processes straight and build your applications in a maintainable way.