CGI sucks.
So, in order to make a super-duper fast "web application" big on the catchwords run fast enough that people don't moan about it, I find myself at a crossroad wondering which way to go. Any option if convincing enough will be fine (I'm a cowboy coder), so I want to see if anyone is awake enough to tell me what I should use.
mod_perl
Good News: Production grade, proven, lots of documentation, get the webserver control freak options.
Bad News: Morbidly obese worker processes even with "sharing" modules, need to separate dynamic from static greatly, restricted to Apache
Fast CGI
Good News: More than just Apache, Fast CGI servers need not be on the same machine
Bad News: Aparently Fast CGI is a pain in the ass for designing request flow.
SpeedyCGI
Good News: Similarities to CGI make relearning easy,
Bad News: No simple way of separating speedy into a separate package - it's declared via shebang.
PSGI/Plack
Good News: Apparently fast, very easy handling of control flow, can do things like XHR Long poll if webserver supports with ease.
Bad News: Very, very new. Has a wide range of support, but nothing is production stable.
What do you suggest?
> Similarities to CGI make relearning easy
Actually, that's FastCGI's forte too.
The only difference between a sanely written CGI and FastCGI program is the require and a while loop. CGI::Fast can even run as a normal CGI if needed. I ported Wakaba's captcha.pl from CGI to FastCGI with about five minutes of effort.
I don't know about the last two, but I prefer FastCGI over mod_perl. mod_perl is good if you need to dig into the guts of Apache, but most apps don't need that power.
Recently I've been playing with Mojo. I think it's nice.
C/C++
the fastest.
>>3
Keep us updated on your progress coding a web application of any complexity in C++. If you stop posting we will assume you've suffered cerebral hemorrhage.
If you're going to rice out a webapp, use Ocsigen. 90% the performance for 10% the effort. :|
>>4
Eh? Many Webapplications were done in C/C++ in the beginning. Also i did it and from time to time still do.
It's almost not any different to PHP. Also with CGI libs it's even more easier.
Just because you can do something does not make it a good idea. There's a reason why writing sites in C/C++ died out by 2000.
>>7
The reason why writing sites in C/C++ was because of the excess of flexibility -- shared-webhosts would never get a good grip on resource abusers. (C can do anything, it's not easily limited/jailed to a purpose, unlike scripting languages.)
>>8
You have no idea what a UNIX system can do. You can't play with the hard limits unless you've got permissions.
>>9
That, and most hosting providers also provide a Perl option, which isn't much different from C/C++ in terms of limiting and securing. (except for the fact that system administrators can read the source, which isn't quite as easy for compiled languages)
>>1
what >>2 said. I design my webapps for FastCGI, but use plain old CGI when debugging or adding new features (the downside of FastCGI is that code is not automatically reloaded when you make changes to it). Writing code that works in both CGI and FastCGI environments is quite easy.
>>1
Ifn' yer a cowboy yud write your own embedded web server.
Or try this one: http://code.google.com/p/mongoose/ Its actually pretty good.
You could always use flash/actionscript or JAVA (or haskell, clisp/scheme, python, ruby on rails..) :/
>>13
Haskell is great! Flash needs to die though, seriously.
I use server-side javascript for all of my web development needs.
great and thx