Running a Modern Startup on PHP
blog.chartboost.com
blog.chartboost.com
PHP has a bit of a reputation for attracting unskilled programmers, but that's because it is so easy to get started with, which leads to a lot of newbies writing it. All that means is that you may have to filter your candidates more carefully when you hire, and nothing to do with the language itself.
In short, the post seems subjective and opinionated, without showing any concrete problems that they overcame with alternative languages or frameworks. "Codeigniter is bloated" vs "Paraglide is awesome" are both so vague as to be useless. "Ruby's syntax sucks" is even worse.
Much better to have had a list of specific things that dissuaded them from using one framework or language, and some killer features that convinced them to use the other - if all I see is a personal opinion without any reasoning behind it, I cannot make any useful decisions in my own situation.
No one likes it but it gets the job done in a clumsy and amateurish way. It's the BASIC of web programming. Those other so-called sexy languages have actually been designed rather than having features bolted on later, those features are designed to fit into the language from the start.
some of the biggest sites out there are running on PHP just fine.
Popularity != proof of goodness.
I never said it was the greatest language ever. I'll take Ruby or Lisp over PHP any day. I was simply saying that the OP's post is framed as if PHP was generally considered a useless newbie language, and that using it for a startup is somehow noteworthy.
I've worked in Java, PHP and Python. I personally prefer using Yii, phing along with PEAR and pecl libraries to anything else, at least with timeliness in mind.
Unlike Ruby and Python, PHP is a DSL, plain and simple. Yes, it's poorly designed. But it does what it was meant to do-- to build web apps-- quite well. It's up to the end user to write software that scales. And a lot of the scaling issues you'll see will be independent of language choice.
"Unit Testing
While we don’t practice Test-Driven-Development, we do have unit tests in place. PHP does not provide an elegant test library, so we built our own (soon-to-be open-sourced.)"
Really? You've never heard of PHPUnit?
I know of a couple of startups doing well that are built using PHP. One doesn't even advertise the fact that they use PHP because they want strong developers regardless of language. Fact is, PHP is pretty darn simple to pick up, not much harder to do things correctly, and has a lot of third party/opensource support. Is it cool? No, but when it comes to language wars, this pretty much sums up my feelings:
http://programming-motherfucker.com/
Personally, there was a startup about 6 years ago where I wanted to use Python. The IT guy and I got into a discussion about PHP vs. Python. He was more comfortable in securing PHP apps. I was enamored with Python, since I was writing a bunch of stuff with it. After exploring mod-python vs. mod-php, mod-python had bugs and wasn't nearly as mature, so we went with PHP. The language didn't matter, it was about getting things done.
There are lots of "cool" languages out there, a good dev will run circles around a mediocre dev who focuses on things that are "cool".
Challenge accepted!
Thanks to everyone who followed the github project, and whoever had nice comments to say. For anybody that has criticism of the projects, I'm happy to address them in a separate thread when I officially release the project publicly. I'll make a post here when I'm ready and have proper documentation. Please expect more updates in the very near future, and thanks for the interest.
Why not contribute to an existing framework? Your efforts will be better received and more widely appreciated.
The absolute last thing the PHP community needs is another framework.
My framework is minimalist and gets the job done. I'm a big fan of minimalism and I don't like that some modern frameworks are bloated and have something like hundreds of thousands of lines of code, as opposed to just a few thousand, and that includes components outside the core, like helpers.
Paragon has more work in it than Paraglide. Paragon can support multiple different backends with the same code, just different drivers. I know this exists in other PHP ORM frameworks now, but not a few years ago (not saying mine was the first, it just wasn't as widespread). Also, Paragon integrates cleanly with Memcache so the developer doesn't have to deal with cache and uncache logic.
Hope this clears things up!
Sure, you could do the same thing with other frameworks, but most of the other frameworks are full of bloat and not particularly fast. I think it's better to have a few components that do one thing really well rather than a monolithic framework that tries to handle every aspect.
I disagree. A lot of innovation comes from new frameworks and the current breed of php frameworks have problems that needs to be addressed.
Lithium would be a better choice, if you think that you can't do OOP in PHP5 without 5.3, or you think that all other frameworks suck for this/that reason:
Personally I use CakePHP for side-projects, and it suits me just fine. But honestly, PHP development isn't that bad, even with a 3 year old version of certain frameworks...
The CTO of Totsy gave a talk describing their no-nonsense usage of Lithium and MongoDB http://www.10gen.com/video/mongoboston2010/totsy
PHP makes the need for a framework minimal. Cake is neat but overkill in a lot of ways unless you happen to be one of the developers of Cake and know it inside and out. Same goes with Kohana, CodeIgniter, etc.
If you know PHP well, it's almost as efficient--possibly moreso--to program your own minimal MVC framework. PHP has so much of what you need done for you that only an efficient ORM is a bit tricky.
You're not going to have the widespread adoption of your framework that Rails enjoys. This is because Rails increases the utility of Ruby for webapps by a factor of 10x while your PHP framework improves PHP for web apps about 2x.
BUT, if you are using PHP you might as well write your own internal framework because it's a fun programming exercise and will take you only a little longer than mastering someone else's.
I went down the same path(created my own minimal php framework called uno a while back), though if I'm doing MVC apps nowadays it's almost always using Rails. Rails has the advantage of loads of great devs that know it. Also, once I learnt Rails well I grew to depend on certain features that I just didn't want to emulate in Uno.
Regardless, a framework is a way to jump-start someone in developing for a given language. Honestly, I've taught at least 5 developers PHP in about half the time it would normally take using a framework than without. The same applies to any other language.
It's easy to write your own framework, but I can almost guarantee you that it will have more bugs than any of the larger, open source frameworks out there. They may have their chinks, but those get largely fixed and tend to benefit the most people. Using a well-known, and well-tested, framework means you have access to a greater pool of developers, and they don't have to learn the idiosyncracies of something you've written because you could.
And while I am in the process of writing my own framework (see https://github.com/josegonzalez/git-php), I still prefer using someone else's framework. It's nice to be shown other ways of doing things.
"If you know LANGUAGE well, it's almost as efficient--possibly moreso--to program your own minimal ARCHITECTURE framework. LANGUAGE has so much of what you need done for you that only an efficient IMPORTANT_DETAIL is a bit tricky."
I think you can definitely guarantee it :). Before stopping dev work on Uno I ran into plenty of bugs that I didn't anticipate that would have been quickly weeded out by a bigger community. Many times I realized, "oh, this is why all the frameworks do it that way", only after doing things a way I thought was "simpler".
> "If you know LANGUAGE well, it's almost as efficient--possibly moreso--to program your own minimal ARCHITECTURE framework. LANGUAGE has so much of what you need done for you that only an efficient IMPORTANT_DETAIL is a bit tricky."
Good point. I do think PHP is a bit unique though in the respect that many people argue that PHP itself is a framework/architecure for web apps. But I largely agree with everything you've said.
I tend to disagree. As a PHP developer, and in charge of hiring and interviewing other PHP developer, I all too often see what I refer to as "CakePHP developers" or "CodeIgniter developers". It's one thing to know how to use the various frameworks, and even have a personal preference - but when too many people are only aware how to accomplish things using one of those frameworks, it gets downright scary. It's almost as infuriating as getting code samples that are basic extensions of Zend classes...
In the end I want a developer to get their work done - and if a framework helps - great - but they also need to know their way around the language without needing that crutch.
As far as only knowing the framework, you are preaching to the choir. I regularly give support to people in IRC who forget you can actually write regular PHP code - Reflection class, closures, etc. - in CakePHP. Sometimes even OOP.
A framework gives you structure. Good developers go back and fill in the blanks on the language. Bad developers don't need a framework to be bad, they would give you horrible code samples regardless.
I look forward to the developer documenting the project itself. It's not necessarily bad PHP - no terrible practices other than putting everything under the sun in a single class - but to say its a great framework with all of these glaring faults is a little much.
Actually, Python is older than PHP.
Having switched from PHP to Ruby a year ago, I now find Ruby's syntax beautiful and incredibly powerful. If you don't like the implied parentheses, it turns out, you can go ahead and add them!
Edit: because I didn't proofread the first time...
I like Ruby's syntax as well and do most web app work in Rails nowadays.
However, one thing I love about the PHP syntax is that it's so easy to switch between PHP and C or C++ and vice versa. So if you're doing a lot of C work and only a bit of web work, it's nice to know PHP.
Otherwise if you're doing web work full time, Ruby's quite fun.
CodeIgniter is modular, so you can just use the MVC capability it provides and leave the rest alone. Symphony seems to require a substantial amount of prep and up-front learning in order to use it. I couldn't see the set up time between the two frameworks being much further apart.
I'm curious what aspects of CodeIgniter the author found to be bloated and crippling.
Just extract the CodIgniter code into a webserver directory and create the controller code to show some output or load a view and you are done!
Also strange, after reading 51 comments, i have not seen anyone mention Zend Framework. It's got a steep learning curve, but it's just awesome. I've been writing a social web app framework based on ZF, Redis, Gearman and lots of other stack and it's awesome.
More props to them for clearly knowing it has its limitations and downsides... I'd pick a developer who used a language they knew inside and out and were informed and aware of the downsides of the language over a zealot who thinks their language of choice works best in every situation (my most common experience of these types are in the ruby community, by a quirk of coincidence).
PHP was the language I used to teach myself how to develop for the server-side when I'd been purely a front end dev many years ago and I still like it (though granted I like Scala more) because it's always felt like a language you can sit down and get shit done with quickly and without fuss, and sometimes that is as important as any other attribute you can attach to any other language choice.
I'm not too lazy to learn anything else, I always use the tool that is best for the job at the time. Recently I had to design a web application that outputs MS Word .DOC files in binary form. There's SHIT support for this in PHP, so I wrote the whole web-app in Java, because Java was the right choice given the task at hand and the clients existing platform.
PHP is the right choice when I want to get something done quickly ... I can hack a website together in PHP faster than any other language, but it will be exactly that, a hack. PHP's strength is speed of development, and low barrier to entry means lots of developers out there who can help. (High supply of developers also pushes cost down, another bonus for me)
Cite my sources: When I came out of university I had what I thought was a very good grasp of what software should be, and that "elegant" well written software would dominate the market. Totally not true. The best example is the accounting system "Attache" in Australia ... it was the WORST software I have ever used. They only recently (in the last couple of years) got the ability to open more than one window at a time in an mdi windows application !! .. Attache is without a doubt the most successful accounting software in Australia, despite the fact that it's a dog. Why?? Because they were first to market. They were there on Day 1 with a product that met the minimum requirements (e.g. it RAN)
I often see people who underestimate the importance of being first to market ... I truly think it's very important
https://github.com/bgoldman/Paraglide/blob/master/paraglide....
The lack of tests somewhat seals the deal.
I'm curious if you happen to use any monitoring to notice when load on your mongo servers gets too high (eg is about to start swapping to disk instead of using RAM etc)?
Cheers
As a counterpoint, last year I joined a startup as the first technical member. I migrated a PHP application written by an inept contractor (terrible DB layout, SQL queries in the views, most features buggy and incomplete, etc.) to Rails piece-meal. I had very little experience with Rails or PHP prior to this, but was able to rewrite the app in the course of a few months, while adding new features and continuing product development. I simply placed nginx in front of both the PHP and Rails app servers and rewrote the auth system for both apps so that cookies/credentials could be shared. Then it was a matter of migrating sections of the app over one-by-one. There was some hairiness in how the Rails side linked to non-Rails pages, but that code was gradually replaced as the rewrite progressed.
Even despite the abominable DB schema from the original PHP app (which, in fairness, had nothing to do with PHP), Rails was flexible enough to allow me to override its conventions and map tables to models with joins, etc. Overall, it was much simpler than I thought it would be and after the rewrite was complete, it was pretty simple to write migrations to start organizing the DB schema into something coherent.
> My former company (CD Baby) was one of the first to loudly switch to Ruby on Rails, and then even more loudly switch back to PHP (Google me to read about the drama). This book by Michael Hartl came so highly recommended that I had to try it, and Ruby on Rails Tutorial is what I used to switch back to Rails again.
[1] http://ruby.railstutorial.org/ruby-on-rails-tutorial-book#fo...
If you're going to use PHP, I can't really think of a good reason to use anything other than Symfony2.
As far as not using Symfony 2, I wouldn't use anything not marked as stable in production. That goes for CakePHP as well.