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.
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.
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.)"
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".
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.
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.
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 :)
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...
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."
> 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.
> 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.
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.
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.
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.
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)
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
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.
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.
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.
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.
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".
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.
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.
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!
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.