Thanks for the comment. I certainly didn’t mean to compare ApEx with .NET. That said, your suggestion that it is more like PowerBuilder or Delphi then the comparison could be made between the ApEx designer and Visual Studio as an application builder.

Though my real point was that sometimes there is an advantage in choosing legacy compatibility over a completely new platform. .NET was just an example — not intended to be a language comparison.

Apex coupled with Salesforce’s existing UI designer is more like a PowerBuilder or Delphi for the web.

The Salesforce Web Services API allows Java and .NET developers to get their hooks into the system if needed.

I do find the whole product fascinating, though, and keep finding myself comparing it to Amazon’s web services.

Salesforce seems to be at a disadvantage–Amazon’s web services are wide open, and could allow a developer to run virtually any software (this is a big difference between their product and Salesforce’s).

But the developer who chooses the AppEx platform gets two big advantages: the ability to market to an established customer base (Salesforce.com customers), and the ability to charge those customers through the platform/model. Seems to be that it drastically lowers the barriers to entry.

Sure, someday COM may not be supported anymore; however, companies are still beginning the migration to .NET. They still need that COM support.

ESRI’s ArcObjects package is a collect of objects for rapid development of geographic information systems tech in other packages. We’ve used it extensively.

However, when .NET came along, rather than rewriting their COM objects, they got lazy and just put COM wrappers around them and called it good. For most people, I suppose, that may be good. But it’s caused us no small amount of trouble.

Maybe backward compatibility should come with a definite sunset date to help spur developers along. Reward adoption to begin with and then move people along the migration path.