Web Developer Death Match: Zack Rosen vs Jon Stahl!
on
March 2, 2006
Web Developer Death Match: Zack Rosen vs Jon Stahl!
(read in booming announcer voice)
"Good evening ladies and gentlement. Tonight, for your blood thirsty viewing pleasure, we have a death match of epic proportions! in one corner, hailing from the Pacific North West, ONE/Northwest's Jon Stahl! In the other corner from Saaaaaaan Fraaaaaanciiiiisssscoooooo.... CivicSpaceLab's ZAAAAAACKKKKKK ROSEN!!!!"
I am totally kidding here (well, kidding on the square perhaps).
There is a blog debate simmering between Jon and Zack about web services, application stacks, API integration vs native integration.
It's pretty interesting. On the one hand Zack thinks more folks should be building applications using the Drupal as their framework and foundation. On the other, Jon thinks that folks should "loosely join" their applications through APIs.
Both of them make really good points. As part of a firm that has worked to integrate various applications, from a deployer's perspective, I would side with Zack. It would be much easier if all good web applications were tightly integrated with Drupal. From the larger "ecology" view, it would be great if a diverse group of applications could be built and supported in a truly "CMS" agnostic fashion and grafted into various CMS tools through APIs.
I am not sure that there is one right answer here. (Except maybe that open standards and APIs will rule the day!)
Anyone out there developing a web tool of some sort should really look very closely at the existing tools, and application frameworks before they go off building their own application, or framework. I know that we looked at one tool that was built to be versatile, and we evaluated the time it would take to shoe-horn it into drupal, vs. the time it would take to engineer the same funcionality within drupal, and we have opted for the latter.
As much as I would like to think that folks shouldn't have to choose Drupal, or Plone, or DIA, or Joomla! and have their featureset dictated by that choice... you do have to make choices. You can't have a corvett with a hummer suspension. Or a hummer that gets 46 MPG. Organizations have to choose their web platform based on complex factors that include features sets. While we like to say that Drupal is sort of a chinese menu of features, that menu doesn't include spagetti with meatballs from the Italian restaurant down the street.
| Attachment | Size |
|---|---|
| webdevdeathmatch1.mp3 | 49.23 KB |
Fora November 25, 2008
s much as I would like to think that folks shouldn't have to choose Drupal, or Plone, or DIA, or Joomla! and have their featureset dictated by that choice...
__________________
chat-sohbet-sohbet odaları-sohbet
mirc December 1, 2008
Microsoft developers and ASP.NET servers, there's very little incentive to throw out all that training and experience and start over again with PHP (or any other platform).mırç mırç Chat chat türkçe mirc türkçe mirc
Jason Lefkowitz March 22, 2006
You put your finger on why Jon is right in your response:
It would be much easier if all good web applications were tightly integrated with Drupal.
The problem is, they simply aren't going to be. There is never going to be one universal application platform; too many people have too large an investment in competing platforms. Drupal is nice, but if all you've got are Microsoft developers and ASP.NET servers, there's very little incentive to throw out all that training and experience and start over again with PHP (or any other platform).
Not to mention that even if they could do such a migration, some will just not want to - not everybody in the world thinks Drupal is the bee's knees (as the existence of 48 million other open source CMSes proves), and while Drupal may be perfect for some uses it's wildly inappropriate for others. (Note that I'm not trying to knock Drupal here - it's very good software. These are just truths about any application, no matter how well designed.)
That's why loosely-coupled services are what works. I can build an Amazon storefront in any language I want using their APIs. I can host a Salesforce.com-integrated app on any server OS I want, using their APIs. In other words, the barrier to entering their ecosystem is much lower, which translates into more developers and more interesting and innovative applications.
