Feb 3

Written by: Andy Hock
2/3/2007 11:00 PM

If a company plans to build a web application, there are a ridiculous number of choices these days: Java, ASP.NET 1.1-3.0, at least a dozen solid AJAX libraries, PHP, Ruby on Rails, The Castle Project (a .NET Ruby port), Python...I wonder how the powers that be make the choice of which platform and language to use.

Is the decision based on what they know?  Is it framed by legacy applications?  I'd hate to think that companies are still building major, new applications in PERL, when PHP and Python are inherently much more maintainable languages for the UNIX platform.  But it's human nature, ain't it?  You do what you know: there are times when this is a good decision and times when it is disastrous.

We're not going to talk about PERL here.  Our focus is on .NET.  I've spend a decade on and off building LINUX-based web applications, and living in the Java world, beginning in February, 1996 in the Advanced Technology Group at Fidelity Investments. 

By the time ASP.NET arriced in 2001, I, like many others, had grown frustrated with Sun's refusal to embrace marketing and ownership of Java.  Hence, IBM's Websphere, BEA's Weblogic, and many others that fell by the wayside.  The release of Tomcat and JBoss was a welcome respite from having to spend hundreds of thousands of dollars on a platform even before one built an application, but for me and many others, we were busy embracing ASP.NET.

And we're not alone either.  Here are the search result numbers from Google on Java, ASP.NET, PHP, Ruby and Python:

Language	Pages Returned
Java	8.13 Million
ASP.NET	24.4 Million
PHP	84 Million
Ruby (including Castle)	5.15 Million
Python	22.7 Million

What's surprising about the above search results shouldn't be at all.  LINUX is essentially free.  There are a number of open-source PHP IDEs and if you reside or resided in academia, PHP is king.

Ruby has gone from zero (except for jewels) a few years ago to over five million pages.  That's impressive.  My issue with Ruby is it's too easy to not separate the business objects from the data objects.  Of course, one can say that about any language I guess, so counting the number of pages for each language really only tells part of the story.

Because it's the platform one chooses after you choose the programming language that most often identifies failure (aside from management issues of course).  So one of the major reasons we often (but not always) choose to use DotNetNuke as a development platform is because it almost forces programmers to separate data from business rules. 

Yes, there are other platforms that are amenable to using the Provider Pattern for data and the MVC (and other) pattern to create elegant--and just as important--maintainable applications.

Here are some more surprising numbers:

PLatform	Pages Returned
DotNetNuke	1.18 Million
JBoss	1.68 Million
IBM Websphere	2.74 Million
BEA Weblogic	1.79 Million

Consider that DotNetNuke is by far the newest of the above development platforms, DNN has become a platform which should be included when a project team decides which platform to use to deliver their web applications.

But we can't discuss DotNetNuke without taking Sharepoint Server into account.  There are other portal and community servers in the .NET world, and I want to discuss those, but for various reasons, mostly having to do with the size of the support communities, it's DNN and Sharepoint in the .NET world if you are considering portals.

Are there issues with DotNetNuke?  Of course.  Just the issues with the complexity of the install alone has scared away more than a few of those download numbers at DotNetNuke.com. Here's an excellent and mostly objective article which talks about some of the good and bad points of DNN  (I say 'mostly' because, in my experience, programming modules in DNN is much easier than in Sharepoint--amazing how two different people can arrive at two opposite opinions on some things.  And remember, it's just my opinion...doesn't make me correct!). It's written by Bill Simser who obviously knows Sharepoint very well and offers an eloquent comparison.

The other reason is that one can build a multiple server DotNetNuke site--but of course it would have to be done with web services wrappers and SOA design built into the modules. The lack of 'Enterprise Search, Single Sign-on, or separate indexing' shouldn't prevent a DNN site from spanning servers. That opinion aside, it's an excellent comparison of Sharepoint and DotNetNuke.  But to introduce Fingerfuel, we wanted to offer a rational decision on why we focus mainly on .NET and DotNetNuke, though combined, Justing and I have almost twenty years of Java experience.

Tags: