Choosing technology for small or medium web application: PHP || Java = Ruby, RoR
PHP has never been my choice for many reasons: it's not a general purpose programming language, not OO language, slower then Java, it's hard to maintain and more. I admire PHP community for taking very practical approach and creating a whole new line of applications from PHP-Nuke & SquirrelMail - all way to Drupal, Mambo & Wikimedia. The most incredible sites run on PHP: archive.org & wikipedia.org. To gripe about PHP is almost like biting the hand that serves you(I'm a happy user of many PHP based apps), but it seems to me there should be a better way and it seems like RoR is a much better alternative long term and JVM has a role in it too.
None of the 5 major projects I was working on in the last 5 year could be done with PHP (in a sensible way) because in addition to web application they also had: concurrent high availability server components, integration with other systems over RMI, advanced imaging, third party libraries in Java etc. One application had to handle 100+ database transactions a second, another one had to run 400+ threads doing different things and more.
Having said that, a friend of mine, very talented web designer, an artists and entrepreneur had to put together a site for e-commerce. With basic programming knowledge and couple of weeks of work she was able to put together an awesome site with on-line payments, LDAP admin component and more. She installed Linux, took a bunch of PHP programs from all over the Net, put them all together, mailed a few people and asked a few questions, browsed through newsgroups and FAQs and added what was missing . There are thousands of people on the Net who would never have anything to show if they started with J2EE stack. Not because Java is inferior, but because J2EE learning curb is too high. Entry level into PHP is very low, it is designer and entrepreneur friendly. It will become a "fat pony" one day, probably sooner then most people think, but it will fill the niche and create new market by then.
Some of the factors that make Java today a good choice of technology for medium and large size project, are the same factors that makes it _not_ a good choice for my friend:
1. Very configurable - you need to know how to configure it.
2. Many choices - pressure to make right choice, often it means you have a to learn about a few of them first(Ouch!): frameworks, libraries, IDEs, JDKs, app servers.
3. Variety of methodologies, process - confusion: what should I use: aop, javadoc, junit, agile, xp, mvc; very bureaucratic.
These are the sides of the same coin in each particular case. With an exception of XML configuration overload and EJB overengineering - everything went reasonably well in terms solving design problems with Java. The resulting complexity is normal result of having all these options to choose from.
Is it a never ending quest to have it both ways then? Perhaps, but we have precedent how to deal with it - build a higher lever abstraction to hide details for the segment of the market that doesn't care or even want to know about them. When we moved on from machine code to C, we didn't throw away assembly languge - we've built on it. Likewise, when we moved from C/C++ to Java, we did not throw away them - we've build on it. If fact that was a very successful, evolutionary approach: grow a layer, polish it, leave it alone and move to the next level when the problem is big enough. Perhaps, the easiest way to get the best of two worlds is to invite Ruby to run on JVM as a first class citizen. Perhaps even package it all together with RoR and Tomcat? I can't use Ruby alone because I need Java 2D imaging API and JMF as well. There will be many cases like mine and JRuby may potentially be even more practical then Ruby by reusing everything that Java has to offer. This is why I see running Ruby on JVM being only synergistic. Why rewrite all the magnitutude of the great code written in the last 10 years? Why not use a VM that was polished so well over so many years? Why not use Swing if you need cross platfrom GUI system? Microsoft is courting Ruby community. I think it's clever and they have figured it out.
The idea is called the "Firewall Brand" in business circles. Basically you create a low entry point alternative for your high end solution to preserve its market share from someone else's low cost alternative growing trend.
PHP is a DSL for developing web application. So is RoR which is two orders of magnitude more powerful and better designed. PHP had developed already large loyal community and application base and Ruby and RoR is still fighting its way up, but it's changing and it's going to be interesting to watch.
None of the 5 major projects I was working on in the last 5 year could be done with PHP (in a sensible way) because in addition to web application they also had: concurrent high availability server components, integration with other systems over RMI, advanced imaging, third party libraries in Java etc. One application had to handle 100+ database transactions a second, another one had to run 400+ threads doing different things and more.
Having said that, a friend of mine, very talented web designer, an artists and entrepreneur had to put together a site for e-commerce. With basic programming knowledge and couple of weeks of work she was able to put together an awesome site with on-line payments, LDAP admin component and more. She installed Linux, took a bunch of PHP programs from all over the Net, put them all together, mailed a few people and asked a few questions, browsed through newsgroups and FAQs and added what was missing . There are thousands of people on the Net who would never have anything to show if they started with J2EE stack. Not because Java is inferior, but because J2EE learning curb is too high. Entry level into PHP is very low, it is designer and entrepreneur friendly. It will become a "fat pony" one day, probably sooner then most people think, but it will fill the niche and create new market by then.
Some of the factors that make Java today a good choice of technology for medium and large size project, are the same factors that makes it _not_ a good choice for my friend:
1. Very configurable - you need to know how to configure it.
2. Many choices - pressure to make right choice, often it means you have a to learn about a few of them first(Ouch!): frameworks, libraries, IDEs, JDKs, app servers.
3. Variety of methodologies, process - confusion: what should I use: aop, javadoc, junit, agile, xp, mvc; very bureaucratic.
These are the sides of the same coin in each particular case. With an exception of XML configuration overload and EJB overengineering - everything went reasonably well in terms solving design problems with Java. The resulting complexity is normal result of having all these options to choose from.
Is it a never ending quest to have it both ways then? Perhaps, but we have precedent how to deal with it - build a higher lever abstraction to hide details for the segment of the market that doesn't care or even want to know about them. When we moved on from machine code to C, we didn't throw away assembly languge - we've built on it. Likewise, when we moved from C/C++ to Java, we did not throw away them - we've build on it. If fact that was a very successful, evolutionary approach: grow a layer, polish it, leave it alone and move to the next level when the problem is big enough.
The idea is called the "Firewall Brand" in business circles. Basically you create a low entry point alternative for your high end solution to preserve its market share from someone else's low cost alternative growing trend.
PHP is a DSL for developing web application. So is RoR which is two orders of magnitude more powerful and better designed. PHP had developed already large loyal community and application base and Ruby and RoR is still fighting its way up, but it's changing and it's going to be interesting to watch.
posted by Zaphod at
7:12 PM
0 Comments:
Post a Comment
<< Home