Why so puzzled?
I'm really surprised that many Perl people are still puzzled at why Perl web apps aren't as popular, and there isn't as many of them as PHP's.
Guys, in order for a Perl app to build up userbase it...
* Must run on low cost shared hosting
There are ALOT of non-programmer people who are trying to run their own web projects and are starting up with ready, free solutions, that they want to minor-customize themselfs or are willing to pay a little to get small customizations. They most often not doing it for money, or are hoping to get some in the future, but don't have a clear idea on how to at the beginning. And most of them never will make any money, but more people try - more succeed, And those who don't succeed, pass on their accumulated knowledge. Anyways, so, they just get cheap/affordable hosting -- THESE are WordPress, phpBB, etc. users.
To Perl project to compete for these people, this means no mod_perl, no Catalist, no shell access to install modules that need compiling, etc.
Also, keep in mind that most shared hostings still have Perl 5.8.8 installed.
* Minimal dependencies
Because many hostings don't have interface to let you install modules from CPAN, or have strict restrictions on memory/cpu time usage and some modules won't complete the install even if there's an interface for CAPN installs (as in latest CPannel versions). Some hosting providers won't install additional modules for you in large numbers (1-2-3 ok, but more -- too much support, besides, some providers don't have Perl gurus in support).
* Should be Free
Obviously. Why pay if there are free alternatives? People are willing to live with less features and no support if they don't have to pay. Make money on support (once it gets popular), hosting, ads, etc... maybe on something specific to your app. But as far as I can tell, most popular web apps were not started to make money.
* Must be eazy to install
Absolutely. Upload, maybe set some permissions. Thats it.
* Must be eazy to configure
Stuff like simple looking URIs. PHP can really go without it, but for Perl.... most hosting providers won't let you run Perl scripts outside cgi-bin, and people don't understand the need for having "cgi-bin" in URI. Mod_rewrite is enabled on virtually every shared hosting account these days, so make it so that user installing the app doesn't need to manually edit the config files.
* Code must be maintainable
Because people will want to customize it, whether you like it or not (and you better like it, if you want your app to be popular).
So, can a Perl project become popular among masses? I belive it can. But it may require more effort from developer(s): less dependencies on CPAN (or include needed modules in our destribution), don't assume user is competent in Perl (in fact assume he doesn't know anything about it), add eazy to understand installation/config instructions, help others customize it by providing answers to their questions (oh, and, I think, people don't like mailing lists and irc that much these days. setup a forum, where knowledge will be accumulated and be always available to pass-by-ers).
Popularity among regular users brings interest from developers looking to make extra buck or gain some personal fame via customizations/plugins/themes/etc. Also, successful small tools end up in corporate world too one way or another. And the tools are written in specific languages, and thats how they become popular. I always thought all of theis was obvious....
So, keep these items on mind when you think up a great web app idea.
Or don't.
Continue writing code for enterprises, get your bi-weekly paycheck, and stop worrying about why Perl lost to PHP.
I blog about Perl.
I really don't think stopping to depend on CPAN is the solution. I think better support for CPAN from hosted environments is.
Lightwieght frameworks like Dancer and Mojolicious make things a little easier than they were.
The perl shared hosting site is a nice idea too, but seems to have lost momentum.
Well, there's local::lib
but that assumes users have shell access on their host, or smart enough to use it.
Leon,
- How are you gonna convince companies developing software for hosters to do it?
- How are you gonna convince hosting companies to lift resource usage restrictions? (I'm hosting with one company (not perl stuff) that does use CPannel which allows me to install CPAN modules, but it dies trying to install Mojolicious because it hits memory limit)
- How are you gonna convince hosting companies to provide shell access and C compiler with other low cost competitive features? they often offer it for more expensive accounts, or don't offer it at all citing security conserns (and these usually don't have competent admins -- how are you gonna convince them to hire those?).
nickl, yes, these are great! but I don't know a single interesting, competitive project oriented at mass user using them. :(
I've got something up my sleeve: a Perl oriented shared hosting platform dedicated to driving Perl web hosting technology instead of what makes strict good business sense; starting pricing will be around $10 to $15 a month for a basic set of usable resources.
Heroku, but with more than one way to do it and less EC2, is around the corner too and Really Soon Now (TM).
Popularity is very fickle nowadays and depends on many random and unexpected events.
1) 2) I was thinking of wrapping cpanm, since it has much lighter memory requirements than CPAN.pm or CPAN++. A simple client doing little more than installing packages should be quite easy to make. cpanm + local::lib should make this quite
3) 4) if your hosting provider isn't providing you a C compiler, go look for another one. Same goes if they don't have competent admins.
You can get a VPS for as cheap as $20 per month. You can manage it yourself and install whatever you like.
I've never been convinced that people unwilling to spend the price of a couple of movie tickets each month really deserve any attention. The Perl community doesn't have to contort itself to fit people who won't do much to help themselves.
If you think you want to run a hosting service, well, good luck. If you want to spend your time saving people a couple bucks and providing endless customer service to low-paying and lightly motivated customers, it's your life I guess.
In the end, people need to commit their own resources, money, and commitment to their own projects. The barrier to entry is there for a reason: if you don't want to make it over the barrier, maybe your project isn't really worth it.
@brian - bluntly and well put!
@brian - Couldn't have said it better myself. Sure we won't get 10,000,000,000 million $0-$1 /mo hosters. But who cares about them? The people spending nothing are always the biggest pains in the asses anyway.
Python had a nice boost in popularity and buzz from Google App Engine's $0/month hosting. It's foolish to ignore such possibilities, especially if you've been in the same room with someone who's read about disruptive innovations.
I think it would be very important for Perl - if people want it to get back to the main stream web development field - to provide such low barriers of entry.
The only thing I'd say a bit differently is the
Minimal dependencies. I'd say use as many dependencies in the framework as you want but create a package that is stand alone, that already includes all the dependencies and that only needs core perl. So people can just upload it to the server (even if it consists of 1000 files) and start using it.
The problem isn't really shared hosting, it is deployment by non-perl-experts.
The real solution for doing that is to produce a binary repository of relocatable installable CPAN packages (possibly PAR) for all the really popular versions of current operating systems.
If we could hook into all the work done by CPAN smokers to actually test packages to also produce binary packages when they are done testing something instead of just throwing all that work away would be awesome. How about ending that smoke cycle with "make par && make upload-to-binary-repository"?
And the end-user thoughts of mine are to create a web-based CGI-usable version of a cpan-installer that basically can bootstrap a local::lib install for the user calling it (requires at least suexec support, but any security-conscious hoster will use this). When it has bootstrapped that environment it would either bundle (via Fatpacker) or ask for an URL to a META.json-similar file that would describe what packages to download from the binary repository based on what is available for the current platform/architecture. If core libraries are not available on the hosting platform it would issue simple error messages that explain to the user what commands the sysadmin needs to run to make things work (like apt-get install libxml2). Alternatively we could push for more Alien::* packages built as PARs.
This of course is no easy feat, and it would require massive coordination to pull off for more than one platform/version. But we've been able to create (and manage) CPAN, so why not something binary as well?
I've been brainstorming these deployment issues on #perlcms on irc.perl.org. Some of the thoughts that have come out of this have been collected here: http://github.com/robinsmidsrod/unnamed-perl-cms-project
Mojolicious::Lite apps. No dependencies.
All you need is ./lib for Mojolicious, and the executable which can include both code and images.
Done.
@brian d foy - you know how drug dealers supposedly give out the first few doses to hook you on the drug? Yes - the cheapest solutions are not professional and will not scale and will not work for anything that is of any value - but they are a way to try out your ides. So if you think you have some idea for a web site you can cheaply and quickly try it out - and then abandon it if it does not work - or expand and improve it if it does and buy more expensive hosting packages. chromatic already said it - this is what disruptive innovation is about. Perl used to be in this area when 'cgi scripts' were efficient enough for most things, at some point it stopped and we'll not turn it back. What we can do is move ahead and try the options that work for Python and Ruby - that is fastcgi hosting.
Couple of points from someone working at a hosting company. Most people think $3/month is a total rip off. Why? Because even though they spend more at Starbucks they are told that they can get it for $2.99 and therefore we must be making out like bandits.
Way back when people have changed hosting companies because company Y offers 200 POP3 mailboxes instead of our 100. I have pointed out to customers that if they're only using 3 mailboxes then the hassles involved make it pointless if they are not saving money, but the mind set for many people is still that the lowest price means the best deal.
Never mind such situations as well I pay $3/month why the **** wasn't my database backed up when your server crashed? And why wasn't there a hot-spare server with a real-time live backup? Umm.. cus you pay $3/month? and you want $1000 service?
And that's just for the service. For those that say these people are idiots and should be ignored, I'm sorry but the reality is that you can't ignore them. If you're trying to build a user base for a Perl app then ignoring these users is like thumbing your noses at everyone that eats at McDonald's. Exclude 10 million users, as one commenter counted it, and see how well your app takes off. You might _want_ to ignore these people but you cannot. These people provide the bulk of your numbers.
Worse still is that even now, many years after PHP stopped being "cool" and is now just another solution (possibly the de facto choice) people still tell us that PHP looks prettier. So I humbly submit an addition to the author's list:
The output must look pretty.
Pretty means CSS and it means graphics. It doesn't matter how beautiful or syntactically correct the HTML is or how well it passes the most pedantic of validators. It just needs to look pretty. So bribe your graphicsy friends with beer, beg, plead or even purchase (gasp) design and graphics support. And please, don't design the icons yourself, because you're a Perl programmer and this is mutually exclusive with designer skills. (I think people with both skills are either very rich or must simply implode)
We lovingly refer to it as the PHP pixie dust. It doesn't matter that PHP scripts can suck the life from a server, have horrible security flaws and so on. If the output doesn't have gradients graphics behind the navbar and headers, rounded corners, content in boxes and so on then it is never going main stream. This is what "web 2.0" looks like. If it doesn't look like that it won't "sell". Coders might love it but users won't and they are the majority.
So please for the love of Perl make the interface pretty because eye candy really does sell.
Colin.
Yes, drug dealers may give out free samples, but have you ever looked at the economics of dealing drugs? It's a very high risk business that takes over your life and returns little reward requiring you to constantly find new people to deal with, all the while enriching a very small group of people. Dealers dream of making it big while very few do. Your metaphor illustrates my point quite well. You'll spend most of your time dealing with people you don't really want to deal with, and most likely wasting your time in the end. You'll either get clean, abandoning the project all together, or die trying.
So, good luck with that.