Paradigms for CGI application development?

JP Howard jh_lists at fastmail.fm
Wed Nov 6 17:30:24 CST 2002


On Thu, 7 Nov 2002 01:05:56 +1100 , "Daniel Walmsley"
<daniel at landmarksoftware.com.au> said:
> I've been playing with ASP.NET and Visual Studio .NET a little bit (a
> couple of hours in total), and this is exactly the sort of thing
> they're heading for. You create an application interface by dragging
> and dropping components (calendar controls, buttons, images, data
> grids, etc) onto a form, and you attach properties/events to them.

Yes, there's a lot to like about ASP.NET and the VS.NET IDE. There's been
discussions about this on the mod_perl list, and no-one has identified an
equivalent technology for Perl apps. There's template frameworks, of
course, but nothing with such a complete event-driven framework, or with
a such a rich graphical form builder.

ADO.NET is also really interesting, making it pretty easy to create
client-side data snapshots to avoid server round-trips.

Having said that, there's enormous downsides:
 - Tied to IIS, which means (amongst other things) high license fees if
 you need anything more than play functionality
 - Such a complex system *will* have bugs, but you can't fix them because
 you don't have the source
 - The vendor (MS) has a history of building dominance and then
 leveraging it to maximise their profits. So expect your costs to keep
 going up over time
 - Only Windows IE users will get the full experience of your app--as
 usual there are little annoyances in targeting non-Windows and/or non-IE
 browsers
 - Developers are somewhat tied to VS.NET; ASP.NET can be written without
 VS.NET, but it's a pretty code-heavy framework when you don't have the
 GUI builder to help you (but at least you can embed Vim in Visual
 Studio!)

With vendor lock-in for your servers, and your development tool, lack of
source code so you can't fix bugs, and a vendor history of leveraging
their market power to maximise their profits (and your costs!) the
business risks seem far too high to justify the convenience of the app
framework. There's nothing you can do in ASP.NET you can't do in
mod_perl, and of course mod_perl has plenty of advantages over ASP.NET
(like access to the full Apache API). It's just that some things are more
convenient in ASP.NET/VS.NET, and requires less skilled programmers.

IMO there's plenty of interesting ideas to for the Perl/mod_perl
community to learn from in ASP.NET. Most of these ideas are also present
in Delphi BTW, which is not surprising since MS pinched Delphi's lead
engineer...



More information about the Melbourne-pm mailing list