common criticisms of web app frameworks?

[Aaron Sumner]

Hey everybody--I figured I'd start this conversation online rather
than wait until tonight. As you may recall, I'm giving a presentation
about why web application frameworks (Rails et al.) are good for
developing custom applications for academic/administrative purposes.
It's primarily targeted toward school administrators and maybe school/
district IT managers, thus not in-depth. Anyway, I want to spend a
couple of seconds touching on common criticisms of these frameworks--
you know, how "they don't scale" and such. (My common response to that
problem is that the scalability problem is a good one to have, and
I'll probably include a photo of my current--ahem--server farm.)

So, aside from the scalability thing, can you think of other reasons
people have given to NOT use frameworks, and any rebuttals?

Thanks, and see you all tonight--
Aaron

[Eric Gruber]

Here would be my three objections.

1. From a Mac/Linux viewpoint, you have to be comfortable with the
shell (I'll avoid using Windows/command line references because I
don't have any experience with Windows frameworks.) Beginners to
intermediates who aren't familiar with a shell might find the learning
curve steep to install and use a web application framework. For
example, it's possible a decent PHP developer who doesn't use a
framework could develop on a machine, deploy to a server and never
have to write a shell command. But, just as someone who only knows how
to use Dreamweaver to fix a design, only knowing how to interact with
a computer/server through a GUI separates the children from the
grownups.

2. Speaking of deployment, hosting can be an issue, as we've
discussed. The market is adapting quickly, but hosting that provides
easy deployment of applications built with frameworks isn't as
prolific as it should be. However, it's not as simple as (at least in
perception) as putting all your files on a server, connecting to the
database, then making it all work. Like with PHP ... a small app could
be easily and quickly deployed and up and running. Again, shell
experience comes into play here, along with hosting that has great
documentation and/or makes deployment a snap using things like
mod_rails.

3. By listening to podcasts, you could get the impression that
frameworks are memory-hungry monsters that you'll never fully keep
contained. How much RAM do you need for your app(s)? Is 256 OK? How
about 512? How about going with 2 gigs of RAM to be safe? There should
be a snopes.com for frameworks. I could see why misconceptions occur,
however, because documentation is rather user unfriendly, and often
written in that wonderful dialect, _geekese_.

Eric

[Aaron Sumner]

Thanks for the feedback, guys. To give you a better take on the audience--most universities/community colleges (at the administrative level) have a mix of off-the-shelf apps and custom-built stuff. They gripe *a lot* about off-the-shelf stuff, primarily because it's missing something they really want it to do, or it turns out to be too expensive for what they get, or support actually sucks even though the sales person told them it would be awesome. Or worse, the company goes under (or at least bought out). I've attended this conference for a few years now and it's a fairly open-minded group, so I think they'll at least listen. (I would *not* present this at a conference for enterprise-y types or K-12 types.)

What I'd like to offer is a case for a happy medium between a perfect (albeit hypothetical) off-the-shelf app and a written-from-scratch app that takes a long time and isn't maintainable when a developer leaves for another job. My "selling points" are the time saving, better/more manageable/more maintainable/code, and that my app fits my exact specs—I don't have to settle on what the off-the-shelf app does.

There are going to be people on either end of the spectrum who disagree, but in the end that's not my problem.

I think the learning curve issue is valid--it saddens me how many developers can go through life never touching an app from within a command line. I will think about how to address that. I actually think there's pretty good support, from plugins to podcasts to books, and my thinking is it's easier to help some stranger out in internetland when you have a sense of the framework he or she is working in (as opposed to a bunch of PHP scripts in a folder with no rhyme or reason).

As far as hosting goes--most of these people will have at least one server with Apache and at least one person on-staff who knows how to manage it--they won't be searching around for off-site hosting. I will address this, though, and use the ease of setup of Passenger (given you've got someone who knows how to manage a web server) as a response. I'm pretty sure most of the PHP-base frameworks let you do an old-fashioned FTP upload/point to index.php--type of deployment, too, for what that's worth (again, this is not Rails-specific).

[Nathaniel Haas]

Gonna make 'reply to all' my default after this.

Nathaniel

---------- Forwarded message ----------
From: Nathaniel Haas <nate...@gmail.com>
Date: Tuesday, May 26, 2009
Subject: [Lawrence On Rails Discussions] common criticisms of web app
frameworks?
To: Aaron Sumner <asu...@mac.com>


Off the top of my head: Poor documentation, trouble finding a proper
hosting solution, obfuscation (viz. cryptic error codes), dependence
on databases rather than file systems, steep learning curve (esp. if
one is new to the command line as Eric mentioned), lack of technical
support, and investing in software that will quickly be obsolete.

Giving a better product/service that easier to maintain, embracing
their inevitable professional responsibilities, and the wonderful
benefits of elbow grease are the closest things I can think of to a
rebuttal.

I'm curious what you want folks to take away from your talk. I do not
know this audience very well, but I imagine they are more inclined to
buy something off-the-shelf and pay out the nose for support than pore
through tutorials and roll their own solutions. Seems like a hard sell
if that's the case.

Nathaniel