Hacker News new | comments | show | ask | jobs | submit login
Running a Modern Startup on PHP (chartboost.com)
76 points by SeoxyS 2231 days ago | hide | past | web | 72 comments | favorite

Their setup doesn't seem extra-ordinary in any great way, and reads more like a justification against a strawman argument. The author sets up with "PHP is regarded as a clumsy and amateurish technology, best left to development newbies". I am not sure who it is that regards PHP in such a way. Sure, it's not as sexy as Clojure, Scala, Ruby or Erlang these days, but I don't think anyone needs to be convinced that PHP is a worthy technology to build a platform on - some of the biggest sites out there are running on PHP just fine.

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.

"PHP is regarded as a clumsy and amateurish technology, best left to development newbies". I am not sure who it is that regards PHP in such a way.

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 think he was trying to show capability more than quality.

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 absolutely agree, this article was a waste of time. His use of technology wasn't awe-inspiring either. He comes off as someone who is unfamiliar with PHP instead of an experienced user with a bone to pick.

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.

Also, this statement is rubbish:

"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 think he's referring to the lack of a first-party PHP unit testing suite, but I agree with you, PHPUnit is fantastic, and I can't see a reason to write your PHP unit testing library own when PHPUnit exists

Simply put - if you are a good developer and the language isn't completely out of whack for what you are attempting to do -- for instance, web apps and fortran probably aren't optimal -- the language shouldn't matter in terms of getting things done.

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:


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".

Isn't `mod_python` dead?

Yes, replaced by mod_wsgi.

"web apps and fortran probably aren't optimal"

Challenge accepted!

As the author of Paraglide and Paragon, I thought I'd post here. I knew SeoxyS was writing a blog post that may have included Paraglide, but I didn't know when he would publish it. I'm glad that he did, but had I known when, I may have whipped up a simple homepage, did a little bit more polishing, and created some basic documentation. I wasn't quite ready yet to release this to the wild for mass consumption. It's in the cards, but I just didn't expect to push it publicly for a little while longer.

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.

I'd really just like to know why your framework reinvents the wheel for nearly every aspect of the application stack? Looking at the code even thus far, I don't see how Paraglide or Paragon improves on any aspect already offered by the largest frameworks Zend Framework, Symfony and Lithium, which already have documentation, encourage new contributions and follow best practices within their respective paradigms.

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.

If this were a brand new framework, then maybe it would be a waste of my time, unless I had more compelling reasons. However, I started building my framework a few years ago and have just been making incremental updates here and there. Friends and coworkers have started to use it over time, and people like it. I've been told to publicize it over the last 3-6 months, but haven't gotten around to it.

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!

Exactly what I was going for when I released klein.php (https://github.com/chriso/klein.php)

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.

"The absolute last thing the PHP community needs is another framework."

I disagree. A lot of innovation comes from new frameworks and the current breed of php frameworks have problems that needs to be addressed.

Documentation is key! Browsing the code on github gives me an icky feeling - no docblocks :o - but I imagine I'd feel the same about my own preferred frameworks. Looking forward to a good read :)

Good luck, and look forward to more information :)

Paraglide and Paragon looks pretty terrible. Honestly, I don't see it as a great PHP5.3 framework. In fact, it looks pretty terrible.

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...

Paraglide and Paragon look decent to me.

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.

I am actually one of those people that knows CakePHP inside and out (see http://github.com/josegonzalez).

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."

> but I can almost guarantee you that it will have more bugs than any of the larger, open source frameworks out there.

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.

PHP is a complicated templating language ;)

> Regardless, a framework is a way to jump-start someone in developing for a given language.

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.

If you had asked me 3 years ago to write PHP code to do anything, I would have asked you what PHP was. 6 months after the fact - and 6 months into using CakePHP - and I was definitely a useful PHP developer. I can say the same for those I used CakePHP as a model for.

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.

Lithium is a really great option. It forces you into a good set of rules to develop your app rapidly while not sacrificing quality. It integrates really well with both MongoDB and CouchDB out of the box and provides a solid set of testing and analysis tools. As frameworks go, it can do as much or as little as you want it to.

The CTO of Totsy gave a talk describing their no-nonsense usage of Lithium and MongoDB http://www.10gen.com/video/mongoboston2010/totsy

That seems a little harsh without any specifics.

No docblocks. No readme. No tests. No separation of concerns (everything I saw was in a single Paraglide class). Personally, not something I'd like to give to a developer to work with. Might seem harsh, but I'm very opinionated.

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.

Despite the author's denigration of Ruby for its "mess of symbols, implied parenthesis (sic), and lack of statement endings," they sure do depend on a lot of Ruby tools and Ruby-based services: Capistrano, Github, Lighthouse, Tender, and Campfire.

I don't like metalworking, but I depend on my car.

They didn't say ruby sucks for apps. They personally don't like the syntax.

Apart from Capistrano, those are applications. From a user point-of-view it shouldn't matter what those were written in.

Older technologies don’t get much love, and PHP especially has a bad reputation

Actually, Python is older than PHP.

Correct. Python 1991 (20 years ago) & PHP 1995 (16 years ago).

CodeIgniter is bloated? It doesn't even include an ORM! There are some many things missing from it that other frameworks include that I can't even fathom what the author is talking about.

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...

> Having switched from PHP to Ruby a year ago, I now find Ruby's syntax beautify and incredibly powerful. If you don't like the implied parentheses, it turns out, you can go ahead and type them add them!

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.

Lumping CodeIgniter and Symphony together as parallel examples of bloated and get-in-your-way frameworks seems like a stretch.

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.

When I started using CodIgniter the easiness of installing the framework really amazed me. You don't even need the mod_rewrite enabled!

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!

The framework is one thing, how you use it is more important and I believe once you know any framework ( and in any language) inside out, it's kinda pointless to compare. Anything will do, unless you are writing a new super duper cool Google, Twitter of Fb

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.

I also love Zend but you're right about the learning curve. It's a bit steep but is well designed IMO.

Why would one use a language where the best you can say is "it gets the job done". There are so many better options in absolutely every single way that the only reason I can fathom for one to start something new using it out of choice is laziness to learn something better.

If the technical founders are most comfortable with PHP then getting to market with code you know you can trust can be far more important than picking the "right" language (and by right I mean a language that startup communities see as being a proper language to work with).

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.

Bzzt. Wrong. "It gets the job done" is not the best thing I can say about it, you missed the point of what I was saying. The best thing I can say about it is "I can get things done quickly"

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)

As far as PHP frameworks go, I've been using Yii when I do a PHP project and have found it simple and clean and Yii's documentation is pretty superb.

Yeah I agree with most of the comments here. PHP is a clumsy mess, but it gets the job done and I am a firm believer in importance of being first to market.

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

Paraglide looks interesting, although looking at the main class doesn't inspire me with a lot of confidence:


The lack of tests somewhat seals the deal.

If you want something that's nothing like that, you may enjoy this:


We use s similar setup to what they are using. We use in house built MVC framework though. Our Model is a lacking but still works. We do still use Memcached and I don't see how they can skip that. I don't know what their user numbers are like for even 1-2k concurrents that many Mongo queries could be deadly.

We're still at a very early stage and the traffic is definitely not what it's gonna be in the future yet. So far, Mongo has held up beautifully in real-life situations and benchmarking, and we can deploy new boxes infinitely to beef up our replica set with Amazon EC2 when we reach our limits—but Memcached is not out of the picture entirely. So far there's been no need for it (which would not be the case with MySQL) but if future traffic starts to call for it, we'll definitely add that to our setup.

Note that you can only get up to 7 usable members in a RS (then you need to shard), see http://www.mongodb.org/display/DOCS/Replica+Sets+Limits

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)?


One thing to note in my experience with Mongo vs Memcached for certain tasks. Back in the day we used to use MySQL as a shared session storage for load balanced web servers - this is obviously something from the past and since then we moved it to Memcached. Once we started implementing Mongo, it seemed to make perfect sense to just use Mongo instead of Memcached to store that information - but to my surprise (and I love Mongo), Memcache outperformed Mongo as far as overhead and latency goes for managing the sessions. We now keep all session management in Memcached at all times and Mongo for everything else.

Somewhat related... Derek Sivers attempted to port CD Baby to Ruby on Rails, but ended up abandoning the port effort after 2 years and switched back to PHP. See his post on why he came back to PHP and what he learned from Rails (from 2007): http://www.oreillynet.com/ruby/blog/2007/09/7_reasons_i_swit...

Holy lord is that a lot of risk to accumulate doing a full rewrite and deploying it all at once. I think the hardest part about rewriting an app is knowing about all the edge cases, kludges, etc. that accumulate over the years. It makes sense that the person who knows the most about the product and its dirty secrets would be much more capable of rewriting the app quickly than a newly hired employee.

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.

He actually switched back to Rails again. From the foreword to the Rails Tutorial [1]:

> 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...

That article is four years old now, but I'd still advise against porting a large, complex legacy PHP app to Rails. Starting from scratch with PHP in 2011 seems like a much more questionable move though. Rails works well if you start with its conventions in mind.

somewhat related: anyone know if cakephp is still being actively developed (as a framework)?

Yes. The next version (2.0?) is being finalized now.

I believe it is, I haven't met anyone who's used in a long time though. I think CodeIgniter is the current hot framework for PHP.

CodeIgniter is still PHP4-friendly. It's not "hot" by any means. CakePHP is still actively developed, but it's pretty miserable. (It's slow, too - so much so that framework devs usually benchmark against it because it's so reliably slower-than-everyone-else.)

If you're going to use PHP, I can't really think of a good reason to use anything other than Symfony2.

They're removing PHP4 compatibility in 2.0, which is being more than actively developed. And it at least gets as much traffic as Symfony does: http://www.google.com/trends?q=symfony%2Ccakephp

As far as not using Symfony 2, I wouldn't use anything not marked as stable in production. That goes for CakePHP as well.

I just built an app on both codeigniter and cake... and I prefer cake by far. Cake gets in your way a little bit, but it's good for me since I wouldn't describe myself as a "classically trained coder".

CodeIgniter has a big following, but so does Symfony2 and Kohana.

CakePHP is what we swear by at work. Still works for us, and we can't wait for 2.0.

we use it all the time too, but i get questions asking why not codeigniter...

Unfortunately, PHP offers very little in terms of modern and agile MVC frameworks. There are many good MVC frameworks for PHP. Look at Zend Framework (most popular in our region), Kohana, Yii.

I've been using Paraglide as well, and it is indeed very cool.

Any documentation out there for Paraglide? Did some searching and only pulled up the GitHub repo.

Documentation is forthcoming. I didn't expect people to find out about this yet :) If you follow the project on Github, I'll release updates in the near future.

+1 It looks pretty easy to figure out, but documentation is always nice.

Brilliant post. These guys are running in a very similar way to us. Some things in there for us to take hints from though. Will be checking Paraglide out!


I'm curious. How poorly designed and cobbled together would a language have to be for you not to use it?

I realize there's a sliding scale of practicality vs. purity, but let's be frank, PHP is a mess. I'd use good tools in my work.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact