I think it's cool to have great PHP support on Heroku. PHP doesn't always get much love from a lot of the developer community, but it has its place and if nothing else, Heroku support means you can migrate your app there from a shared Dreamhost account if it ever blows up.
No developer I know likes WordPress. In fact, there's almost universal hate and dread about having to work with it. From a user perspective it's decent, but its codebase (and community) is terrible.
Meh. I don't mind it, and it drives some of my eCommerce sites through WooCommerce. Nothing huge of course, but annual sales in the six figures. It's not that bad, really.
the irony is that WP source and plugin architecture is written in textbook shit PHP from the 90s. (last i worked with it a couple years ago). i would not wish WP development onto my worst enemies. i really hope it gets displaced by something managable written in proper PSR-0 and >=PHP 5.5
in many ways, WP exemplifies PHP core devs' philosophy of "dont ever break existing ecosystem compat". PHP has some major WTF that lingers on because of this. i'm very surprised that it has been progressing at all considering how stubborn they are on even fixing completely obvious shit like "unexpected comma" errors written in Hebrew. wordpress takes this attitude to a whole new level :(
there is great, maintainable software written in clean* PHP; the only thing i've learned from WP is how not to write software.
can we tone down the elitist attitude? i personally enjoy how simple WP is to use and extend - that's one of its core strengths. As with any complex piece of software, there are a few wtf's to be had.
Upvoting you because you said nothing which deserved a downvote. You have asked a civil question and contributed to the discussion.
I feel the tension you have - it's great to have something simple to use (time to learn WP and produce app X < time to learn Symfony2 and produce app X) and sometimes that's what's needed; it's also nice to have a sane core architecture.
I've worked with PHP 10+ years and WP on and off (had an argument with Matt back in 2003 about WP's code architecture which led to me not getting involved in the project) and WP might be 'easy' but it's not 'simple'. I have to go to the wiki or Google frequently, the functions do not have obvious names, 'The Loop' is crazy behaviour once in an app... a solid modern codebase in the centre would make life easier. Keep the easy extendable nature of it sure - it's great to have a slightly messy outer layer. But please give me a solid core (and a saner template rendering pipeline)
let's not start jumping on each other's asses every time someone doesnt use s/he; there are about 1e6 ways to determine that i'm a dude, not least of which is my russian username. i, for one, do try to check this when referring to others before resorting to being ambiguous.
while i have not profiled it myself, i've certainly experienced how slow it can be with deep dependency graphs stemming from a few, common top level "require"s. i dont want its slowness to be equated to poor PHP perf in general or something equally unwarranted.
That article is just more of the usual bullshit used to bash PHP, maybe to make authors like himself feel better about not using it, and have a good laugh with other bitter peers. Haters gonna hate.
The author is comparing Composer to Bundler, which makes no sense because Composer does a lot more than Bundler. With Composer you can do things exactly the way you want. He says "I don't know what it does under the hood, if it clones every single repository of every required package independently of it being necessary", proving that he didn't even bother learning how to use the tool.
There is no way you can live with Bundler after having used Composer. Trust me, I was a Rails guy.
Well I only cared about Composer and all his points were wrong.
I'm not here to get into another PHP debate. Non-phpers can waste all their time hating if they want, and then go fight with all the problems they have with outdated components like Bundler, create hacks to simulate features that are native in PHP and other OOP languages (eg: interfaces in ruby, abstract classes in python), etc. I'll just get things done in a professional manner using what seems to be the best web platform of our time and then enjoy life.
I've also created a PHP Project Template (https://github.com/tedivm/PhpProjectTemplate) that includes things like composer, unit test configuration, travis-ci and coveralls integration, and various other things that people can use to bootstrap their modern php project.
Laravel is pretty awesome, but in my opinion, I think it borrows too much from Rails, and it does too much. Just knowing how to use Composer, PSR and a url router will take care of, like, 80% of PHP's headaches (even though, yes, none of this is even necessary, it's still better.)
The bare metal lack of abstraction in PHP that other languages have to have but PHP doesn't can be one of its strengths.
I've got nothing against Laravel (other than Blade, and my own personal prejudice against ORMs and html generators), I use it and I like it a lot. I'm just saying a lot of what people seem to hate about PHP can be avoided without dependencies on much besides Symfony by way of Composer or even a framework at all - although this depends on how you define "framework."
Which is an interesting question in and of itself - what's the minimum viable feature set for a modern PHP framework? I would say a PSR autoloader, Composer and a url router, and everything else is superfluous. Most people wouldn't even count that as a microframework, and I understand that. And it probably wouldn't scale for crap either.
Although one thing I really like about laravel, which technically has nothing to do with laravel, is Artisan. Using .phar files as command line applications doesn't get as much attention as it should, maybe.
Do you know of any good standalone router libraries that aren't microframeworks? Specifically, support for placeholder values in URLs but dispatched through a controller setup, not a Callable for each route.
This would make the ultimate pico framework for PHP.
Offhand, no - I have one I wrote myself for prototyping but it basically just does callables (though it does support placeholders.) Support for controllers wouldn't be hard to add though.
PHP will be a tough market to enter for Heroku. It will be especially hard to attract owners of small PHP based sites. Almost every traditional, shared hosting provider supports PHP, prices are really low and setup is trivial (just dump PHP files in your public_html folder, set DB connection string and you're done). For larger sites, when scalability and availability become a significant issue, Heroku platform may be appealing.
Well, I dont know. It will all come down to cost,and the ability to manage CMSs on Heroku, I think.
Something like Wordpress is in my opinion not built for readonly paas,more for classic/upload with FTP workflow. And Heroku IS expensive while being very easy to use when one think his app as readonly backed up by cdns and databases.
I deployed a few Symfony projects on Heroku,it works well. But why choose PHP when I can choose my entire stack since not limited by host restrictions?
Is this a strategy to increase the market potential of Heroku? It was mainly meant for "super fast rails" development and deployment, so I'm wondering why Heroku is targeting PHP.
Some would say its part of their "all platforms" deal, but then I'd argue its not much different than AWS. I'm wondering if they can bring some of the large portion of PHP websites that still run today onto their platform as a way to increase active and paying users.
Heroku employee here. I'm curious about this statement:
> I'd argue its not much different than AWS.
Could you expand here? What about the platform do you find similar and different? Which of that is good and bad? What were you using each to accomplish?
I'm happy to answer questions about Heroku. But I do like hearing unfiltered impressions and experiences before I taint them with my own world views.
I'm not the parent commentator but here is my 2 cents and questions.
Note: I'm currently experimenting with Heroku for a side project app and I've used AWS before. I'm a "cloud computing" newbie when it comes to running a web setup in the cloud.
I'm a developer currently using a lot of languages like python, c++, php, coffee script, & java. I've never understood "cloud computing" and why everyone wants to be on it. It's always been a disaster to setup a php application (for me personally). AWS was a pain in the ass to get phpMyAdmin setup and then they over billed us while on the free tier and we quit and went back to standard web server.
I've briefly looked into Heroku and getting it running with php and I understand the basic git push to Heroku "workflow". However, I quickly became lost once I started looking into getting phpMyAdmin on Heroku. I couldn't find documentation or videos on youtube. Am I just to comfortable with phpMyAdmin in my little webserver? Does Heroku and cloud computing offer better tools / different tools for phpMyAdmin? I haven't seen a good explanation for AWS or Heroku on how to setup a webserver from start to finish to mimic a traditional simple web server.
TLDR; I get frustrated trying to setup cloud computing for simple projects when non technical people want to "be in the cloud".
The value proposition on the front page is "Build, run, and scale apps." Arguably, AWS does this and much more. AWS doesn't really make decisions on what technology you use, so if you wanted to run PHP on AWS it wouldn't take additional effort on Amazon's part.
Heroku probably does some nice workflow things, which is a feature, not a product. Whatever "timesavings" the tooling provides is an AWS feature release away from having parity.
Personally, I've only tested Heroku a couple of years ago out of curiosity.
So here is Heroku, working closely with facebook to bring the PHP platform to Heroku, while all along other hosting and infrastructure companies don't even have to worry about supporting PHP because they sell you scaled box-space, not application stacks.
I guess my whole point is "if you're building your apps with PHP these days, you are probably the type of shop that would benefit from the value-add of Heroku." That is, small to medium businesses with 1-2 web guys running a PHP app who don't know shit about hosting, deployment, or scaling.
We've had huge buy-in from Ruby as it's pretty difficult to set up and deploy a Ruby stack. Where as with PHP it's basically supported out of the box by pretty much everyone.
It's hard to sell Heroku which is why we have the free trial dynos. I find most people either love us see us as a huge value add, or don't understand why anyone would use us.
We're not simply a small abstraction layer, instead we support deployment at the application layer. Which again basically sounds like meaningless fluff unless you've already bought into the product. If I had to sum it up, i would say we're a company that provides a collection of small, sharp, extremely well integrated tools that seek to make your production development experience more pleasant.
For Ruby you get the app setup which is huge, but then you also get process monitoring out of the box so if your app goes down due to hardware failure we get paged at 3am instead of you. It's extremely easy to do things like have multiple staging servers, and I really like our CLI.
Instead of trying Heroku, I would recommend starting off trying out Heroku Postgres and using it through whatever server you deploy to right now. Get the credentials from the CLI.
On a production DB you get forks, and followers. We also have point in time recovery which is pretty fancy. Hacker destroy your DB? Forgot to schedule a backup? Rollback to 1 second before the deletions, and done. If you like Heroku Postgres, then I would recommend trying the dynos, and if not: agree to disagree.
For PHP the sell is management, stability, and consistency. If you're on a shared host your performance is very inconsistent
as well as your uptime. If you're on a VPS you have pretty decent performance but now you have to manage everything manually, and even then there's that uptime thing we're not 5 nine's but hopefully above most: https://status.heroku.com/uptime.
I honestly don't think we're right for every application, every developer, and every scenario. When we are though I hope to provide the best experience possible.
Right. OK so I had it placed correctly. Heroku is for guys that are not experienced in hosting, deployment, operations, or scaling. And that's a lot of small guys.
Where your customers get bitten is when their needs outgrow you, and it happens in weird ways (routing performance, multiple database types, scaling profile, management tools), and its different for each customer.
And you've nailed it as far as your target audience. So really, supporting extra bells and whistles for PHP is a way to capture more of that market - the small to medium shop run by a couple of dudes who have some shared host PHP app knowledge.
So, Heroku's value is really in its add-on services, not its hosting, or its scaling. PHP shops feed your every day hosting provider, so if Heroku can consolidate that market its a big win for Heroku. The taste in my mouth is this was spun as innovation when its not.
Speaking about where PHP is heading, I think it's pretty important to mention the funding Fabien Potencier managed to get for SensioLabs (company behind Symfony):
Symfony components are used in Laravel and upcoming Drupal 8.
The funding above means that SensioLabs will continue to work on solid platform(s) that will bring higher quality development and standards to PHP.
Symfony is the best thing to happen to PHP in a long time and the guys at SensioLabs are doing a lot of great things. It wasn't on HN because HN still thinks PHP equals Wordpress/Drupal and those codebases are horrible.
It is unfortunate indeed, because it's not just the software that is great, but the surrounding community as well who create a lot of great tools like phpSpec, Behat etc.
Symfony and the related components are awesome. I've used Silex at work a few times and it's honestly fun. When done right, PHP can be almost as good as any other Object Oriented language. Unfortunately, when done wrong, it can be much worse.
plug: i'm co-founder of PHP-only-PaaS fortrabbit — seeing Heroku move in our direction shows me that we are doing something right. We see a lot of momentum in the PHP community — some call it a PHP renaissance. Laravel, Composer and lately Facebooks input with HHVM (& Hack) are the cornerstones. Of course PHP is not everyones cup of tea, but something to be taken seriously.
This isn't "the new PHP", and I hope it is amended. Facebook making their own runtime by no means makes it newer than the official version produced by the PHP contributors/zend team until (if ever) it makes it into the core.
I used Heroku for hosting my php site (http://sea-hag.net) for a while on the free tier. It was OK, but the DB add-ons were all pretty terrible (even on the lower pay tiers). In the end, I ended up getting a VPS and hosting it on that. Now it's lightning fast and I can't complain.
Heroku held its own for a while. I'd recommend it if you need to do some quick testing and get people on it to start, but I wouldn't pay for it.
You mean the "free forever" AppFog tier that still had that "forever" promise a year ago? They sure have gone downhill since being bought by CenturyLink.
What is the difference between a PHP developer and any other developer? If they tried to stick this in the middle, I could swallow it but opening sentence is just ridiculous.
Hello, I helped edit the blog post and actually proposed this sentence. I love this reaction:
> What is the difference between a PHP developer and any other developer?
It's exactly the type of response I was hoping for. In early drafts we got a common "big whup" response from some readers. Most posts on PHP these days only do well when they bash the language, very few focus on __why__ they use PHP: which is to create things. Yes, all developers create things, and PHP developers do as well. This sentence serves to validate PHP and their developers. So to answer your question:
> What is the difference between a PHP developer and any other developer?
I still don't buy it. I find that type of sugarcoating generally unnecessary and distracting in negative sense, especially when you start the announcement with it.
Either way - thanks for taking the time to explain.
No worries. I start a lot of writing with a "hook" first sentence and try to end with a memorable sentence. I then diagram the work into bullet points and try to make sure all key takeaways are obvious, note I didn't actually work on the _final_ draft of this doc. I was pleasantly surprised to find they left my first sentence in there.
Some hooks are better than others. I'm an engineer before a writer. It sucks that we have to market tech things, but the sad truth is most announcements that have no "hype" get no hype. I do a bunch of open source work, and some projects I promote and they do well, others I don't promote and they don't do as well.
Generally at Heroku I try to only put one or two flashy sentences in. The rest should be direct substance delivery, though that's not always the case. Thanks for taking the time to click the link, read, and comment!
My cynical reaction: Heroku is a pillar of the frequently extremely PHP hostile Ruby community trying to extend an olive branch now that they want to do business with the community. Obviously Heroku isn't responsible for all the PHP hate in the Ruby world (or any of it for all I know) but I understand why they feel the need to open with a compliment & appeal to friendship.
Why are you getting your jimmies rustled for no reason? Stop getting offended over nothing. They didn't say "PHP developers are makers at heart. No one else is."
I'm not getting offended; actually I'm mainly a PHP dev.
The sentence just sounds as if you paid $5 someone to write you an intro to a technical matter because you didn't know what to to use.
The sentence is general and without point. Because it is coming from a technical company and is aimed towards technical people, yes, I find it ridiculous.
Ha! Actually that would go on my nerves even more. I don't like that type of sugarcoating in general. There is a big difference between passionate language and fake passionate language. IMHO this is the latter case.
It is a positive sentiment that even PHP haters can agree to. Seems like a very carefully crafted sentiment to endear themselves to PHP devs without alienating tribalistic Python/Ruby/etc devs.
My bias: 80% hate, 18% apathy, and 2% curiosity into what facebook is doing with the language.
Why do you feel the need to "hate" a programming language? Hate racism or hunger or war; but a programming language? I find such vitriol unnecessarily divisive and I don't think it in anyway benefits our industry.
I feel no need to hate a language, but I recognize that I have a feeling of hatred towards it. I also recognize that such feelings bias my words and feel that it is helpful to others when known biases are disclosed.
In this context, I think disclosing my emotions towards the language tells others that while I dislike PHP the way Heroku phrased their "makers at heart" was a positive sentiment that I could agree with. It seemed relevant.
Why do I hate it at 80%?
Because it burned me in the past. Because it makes doing things right hard. Because other people make the same mistakes over and over and yet I still have to use it on occasion.
It's an emotion built up after years of negative experiences. My emotional experience with PHP went from Interested to Excited to Cautious to Wary to Hateful.
For me, PHP was the friend that promised the moon and when he did show up he came with week-old dried out cheese instead of the moon that he promised.
Cumulative bad experiences, especially when larger factors (legacy decisions, inertia, switching costs, etc) force you to continue having those bad experiences, leads to negative emotions.
Call it extreme dislike if you want, but for me it is a lesser form of hate.
Note that this is all personal description. Perhaps it was the timing (04-08) perhaps it was my level of experience, perhaps it was bad luck. I realize that some people have unanimously or mostly positive experiences with PHP and I'm not trying to diminish their experiences.
I have never understood this hatred towards a language. Some languages and the ecosystems around it may allow you to burn yourself easily more than the others and in some cases where you were in your career when you first started hacking in that language might have burnt you. But in both scenarios I don't see the source for hatred. It adds to who you are as a developer I think. I frequently hear this from people who like to identify themselves with one of these camps. Why not enjoy all the languages and use them for what they are good at or more accurately use them for what you are good at using them for. Can't we all just get along...
Ruby is flawless,Java is rigid,C well nothing against C,C++ is a mess yes.
PHP is a mix of C (apis like mysql_fetch_assoc ), C++ (:: ->) and java (class and interface ) with javascript weak typing.
It is a mess. I'm a PHP dev, the problem is when i have to maintain other's people mess too. Ruby and Java messes are far more easier to maintain than any PHP one.
There is also the PHP culture and community ,which quite toxic.
For all these reasons,while PHP is my bread winner I have no love for it.
Setting aside my own biases on the subject and giving the OP the benefit of the doubt, perhaps the OP feels that PHP is some kind of local maximum of some characteristic that makes languages good for the lives of programmers, but s/he feels there are much greater nearby local maxima. Perhaps the OP doesn't hate PHP as much as s/he hates that some programmers haven't found greater productivity/peace/enlightenment/whatever because they're locally maximizing and have settled into the local maximum of PHP, which s/he feels is much below nearby local maxima. In this view, the lives of programmers would be better if the PHP local maximum did not exist. I'm intentionally not commenting on the validity of this view.
Playing devil's advocate, perhaps it's even noble to hate a non-sentient thing which one believes impedes the progress of sentient things.
It's good to have options.