The biggest objective problem this style has is that it affords everything-injection; cross-site scripting attacks, SQL injection, command injection if you're using shell commands, etc. Every time you bash one string together with another one, you run the serious risk of introducing a security attack, and with this style of programming, you basically have to be thinking about every single string concatenation.

Using a framework that will take some of the cognitive load off can be a net gain. It need not be a Glorious Framework, it just needs to be something that makes doing the right thing easier than doing the wrong thing.

Otherwise, most of the rest of the pain will be felt by you, not your customers, so hey, whatever, go nuts. But this is a legitimate objection to this approach. (And a legitimate objection to every framework that fails to make the right thing easier than the wrong thing, which is still a great deal of them.)

I agree with the sentiments around here, though. If the goal is to write software that works and hopefully makes money, do what you know and ignore this year's hot new framework/language. Write readable code in case you need to refactor it later.

I cannot see what is wrong with your using plain PHP if you can get the job done faster (as long as you avoid things that make exploits easy, such as raw mysql db functions). When the time for a framework comes, you'll know.

Stop worrying about what others think and good luck!

(I had a background in PHP, JS, C++) 1. Off hours on 2-3 days with dive into python 3. 2. A month later - 'oh let's do this in python!' on google code jam 3. 'python challenge? that's cool' - one night hackathon a month later 4. 'I hate php, I'll do this new web app in django' 5. Two days messing with django 6. Five days and the app was done.

I don't know if I write 'best practice' python or django but it's about x6 less code than in PHP. I can rewrite my app completely in 2 days.

For me, the biggest problem in learning a new technology is finding the balance between cowboy hacking & analysis paralysis.

Just curious... Surely you mean django vs php (not zend or some other framework - which _would_ have been the fair comparison.

- Kohana: ~200 lines of code. - Django: 15. Seriously.

That's one, and it's a big one.

The other, even bigger benefit is that other people will do things for you. They'll write plugins for you. They'll develop new versions of the framework for you. They'll do crazy experiments in corners of the framework design space ("Hey, can we make Drupal work with a CouchDB back end through a series of proxies?") and report the results in obscure Stack Overflow posts that will get indexed by Google. They'll find and fix bugs and security holes for you. When you ask one of them about some problem in your system, they'll have a fighting chance to give you useful advice -- even if they've never actually seen your system -- because, hey, all Rails apps are kind of alike, and all Drupal sites are kind of alike, and all node.js installations are kind of alike.

The fact that this is the major benefit of using a common framework is also the reason why the poor OP feels so lonely. The whole point of a common framework is to have lots of meetings and rallies and beer bashes and hackathons and IRC channels so that everyone can swap ideas and recruit each other and basically work in a big team. They generate their own buzz, because the buzz is part of the value. But hand-rolled personal systems don't get that kind of buzz, because -- to paraphrase the ever-paraphrasable Tolstoy -- all standard web frameworks are alike, but all nonstandard web frameworks are nonstandard in their own way.

So many times in startups and new endeavors, getting things out is far more important than doing it "right". It's stinky, but it's a reality. If your checkbook, bills and time say one thing but your code says another, your checkbook/bills/time win - always. And the person who can pump out more working (working, not necessarily pretty/proper code-wise or stack-wise) apps wins (even if they lose, they win, based on odds - more attempts means more possible chances at winning).

As a note, I would recommend Kohana (http://kohanaframework.org/) over CodeIgniter, but if you're pushed for time, you don't want to deal with a sparsely-documented framework ;)

I'd consider Symfony2 for most applications, or Silex (which is the Symfony2 app kernel, stripped of the majority of the Symfony2 framework) if you like writing the plumbing yourself. Yii is pretty nice, too.

Kohana also has the worst documentation in the world. Seriously. It has very clear comments in its source code, though.

(I still wouldn't use it because frankly, I don't think the Kohana developers take security seriously enough, but it'd be a start.)

look at wordpress, joomla, drupal

You have to stick the layers together at some point, but you'll still probably be better off keeping the glue out of your "business logic".

If you're only worrying about injection attacks "...after you gain some traction" or "...when it becomes an issue" you're already too late, and I don't ever want to trust any of my private data with you, ever. This is the 21st century. Scrubbing and validating user input is _trivial_ now, framework or no.

Please, please, please, everyone who reads this, spend a day reading the OWASP guidelines, and _use_ their sample code. This isn't difficult, and it makes your applications a million times more secure _on_ _day_ _one_.

This sort of behavior is why the rest of us get a bad rap.

http://blog.moertel.com/articles/2006/12/15/never-store-pass...

Needless to say, almost 5 years have passed and they're still around :) their traffic probably a couple of orders of magnitude higher. I was there when it happened, and yes, probably some Russian hacker or whatnot has my password from there, but that's not such a big deal because reddit doesn't know my name, doesn't have my CC number or any details related to my life.

Now, were this to happen to a company that has a lot more information available about each and every one of us stored in one central place (think Google or FB), then things could get really nasty. And I'm not talking about stupid mistakes like the one from above, I'm talking about MITM attacks orchestrated by (vicious) Governments, or cyber-warfare, or just plain old NSA not having to bother to collect information from a myriad of places anymore, when they can just go directly to the source.

I did not say you couldn't build web applications if you were a jerkass who was cavalier with the security of his users' data. I said you shouldn't.

That would have left us without reddit, I don't know about you, but without it the Internet would have been a lot less interesting.

First -- "the chances of that happening is very low." Let this be an education; there are automated toolsets that seek out and exploit known vulnerabilities in software across the entire Internet. If you have a public-facing website, you will get attacked. Period. The chances aren't "very low", they are a certainty. There are also toolsets that are used to do much more low-level scans for things like XSS, SQL injection, etc. These are commonly used by security auditors, but are also used by 13 year old kids who want to compromise your site. Again-- the chances aren't "very low", they are a certainty.

Next -- "...but the priority in any business to make profit first." State attorneys general are very quickly drafting personal privacy laws. I believe Massachusetts and Nevada are leading the way here, whereby any personally-identifiable information is _required_ _by_ _law_ to be held to the same rigorous data protection standards as PCI. If your site is breached, you will get sued, and you will lose.

Following OWASP takes maybe an extra day's worth of time out of a developer-- saying that you're just going to ignore it because hey, what's the worst that could happen -- again, I would ask you to list what you're building, so I can avoid it forever.

That said, one of the things that (hopefully) comes with experience is knowing when and where to cut corners. Basic security practices are one place where you need to bake your understanding into everything you do from a low level, because security is one of the hardest "features" to retrofit. Also because basic security does not have to be hard. Hell, you can make an informed decision not to use SSL on your login page, but it must be just that, informed.

Unlike the language du jour, security principles are something that will apply to all programming you do for the rest of your life. So, though you may decide not to use trendy framework x, y or z today, failing to learn basic security and apply it consistently will slowly turn you from a young developer with bright ideas and a lot of potential, to a middle-aged hack developer with a defensive chip on his shoulder.

1) upload scripts to send unsolicited email, getting your IP address banned.

2) upload scripts to scan the internet for other targets (most common---an SSH scanner)

3) modify the HTML output to leak Google Page Rank to questionable sites, which risks your Google Page Rank.

4) passwords of users, who typically use the same password on other sites.

5) setup an illegal file trading section, hidden from most users (anything from music and films to kiddie porn (saw this first hand, and what once was seen can never be unseen---shudder))

6) IRC clients to control botnets.

I've seen all of these first hand working at several web hosting companies. It's more than just "credit cards."

Stop doing it right now.

There are automated tools that detect injection vulnerabilities and people who will hack you for a dozen e-mail addresses and passwords (and, possibly, control of your server). Sanitizing user input is easy.

While I agree the odds of gaining lots of traction are small, when you do, it hits you very fast. You should at least know the hot spots of your application so you can optimize them easily when possible. I am not telling you to save user registration data on a Cassandra cluster just in case, but employing good algorithms when possible. My apps usually are able to generate JMeter config files that make load testing with real data very painless.