

Ask HN: Is PHP dead for startups? Could PHP revive? - alvivar

New PHP frameworks like Lithium or Symfony 2 are awesome, but it is hard to see new startups on PHP. Could PHP revive for startups? I would like to know the thoughts of HN community about this.
======
iqster
I don't have any startup cred but I do fun personal projects. Here's my take
...

I used to code web apps in Python. Started playing with PHP about a year ago
and enjoyed it. I had a hard time figuring out the right framework to use.
There's just a ton of choices ... each with some good ideas. Perhaps it was
that or my own fault, but I would just hack out projects with straight PHP -
no frameworks! This wasn't the fastest thing in the world but works well
enough.

Two weeks ago, I did a hackathon where my partner did his piece in RubyOnRails
and I did mine in straight PHP. Needless to say, I was shocked at our
productivity difference. Since then, I've been learning RoR and have been
blown away. Why am I okay learning the rails framework as opposed to
frameworks in PHP (or for that matter, Python). I think it is because there is
just one. It means a more focused community, and gives me more confidence in
investing in learning and adapting to the framework.

So ... less choice is good in my opinion (and others - there's even a book
about it ... "Paradox of Choice").

~~~
stephenr
Choosing rails because there is only one well known framework for ruby seems
awesomely flawed for me.

If rails doesn't work the way you want, or makes something unnecessarily
difficult/complex, your options are a) bend to the will of rails or b) switch
language and framework, which means any existing code is basically useless
after switching over.

Choice is not a bad thing. If people are seriously using the lack of choices
with ruby as a positive argument there is something truly wrong with the
world.

~~~
pkkk
You missed the whole point. He explained that productivity was the force that
pushed him into Rails, and more focused community on only one framework
(actually there are more frameworks like Sinatra for example) is advantage in
bigger picture (more mature code, more ppl working on the project, more
knowledge resources on the net, less diversification of job market etc).

Having a choice is not bad thing, but having too many choices can be.

~~~
stephenr
The claimed productivity boost was between vanilla PHP and Rails, so it's
already a poor comparison.

Add to that, the reason he was using vanilla PHP is because he couldn't choose
a framework, and his whole argument seems pretty flimsy to me.

~~~
pkkk
Vanilla PHP by itself is a framework (as template language for the web) with
many API that vanilla Ruby is not providing. If you will compare both in this
way it will be poor comparison too right ? My point is that you can't compare
PHP with anything on the market in this dimensions.

PHP could be productive in the past, currently PHP frameworks are trying to
fix fundamental flaws of language architecture and my subjective opinions is
that they are constantly failing, language can't be fixed by building
frameworks on top of it. This is IMHO the big win for Rails, Django, Node.js,
they don't fix the language, they just don't need to, they extend it and
provide productive framework to complete much different task, build end-user
application right ?

~~~
stephenr
No, PHP is not a framework, it's a language.

~~~
jigs_up
People say PHP is a templating language because it allows inline code. I think
that's what he meant.

------
sim0n
Our startup is built on PHP and it's quite amazing how many people look at it
and then say "I assume it's build on Rails?". I know a lot of people running
new startups and a fair few of them are running on PHP versus something like
Ruby.

I wouldn't stay it's dead by any means.

------
albahk
I have a full time job, young kids and I work on some small web projects in my
spare time. I started on PHP as my first language many years ago and I am at
the point where I can get anything done I need to in PHP and I enjoy solving
problems with code. I use a lightweight framework (Codeigniter) because it
saves me from having to write my own.

For me, exploring different languages, frameworks, platforms etc is a luxury I
don't have time for. PHP works for me and on the list of things that are
adversely affecting my projects it is way down near the bottom after getting
users, revenue, marketing, scaling, one-click deployments, testing, design,
databases, backups, security, sleep, motivation, server costs, monitoring etc.

At the end of the day basically every language/framework/server is just
spitting out HTML/CSS/JS text to a browser so as long as it does that OK then
I am happy to focus on building the business.

------
XLcommerce
My startup is built on PHP. I chose to use CakePHP for MVC goodness.

My choice of PHP was due to easy deploy (no heroku when we started). And I was
scared off from more glitzy languages/frameworks like Ruby/Rails due to talk
about performance issues.

So far no complaints. PHP is one ugly language, but it gets the job done ;)

------
iaskwhy
I guess it wouldn't be good marketing to say "hey, here's my new project done
in PHP!" so even if you actually enjoy working with PHP you probably end up
not talking much about it. I know that's what I do.

I don't see it go away anytime soon but I also don't expect it to grow since
most new developers probably run away from it and to more talked about stuff
like Ruby. Still, I have recently heard some stories about how Rails is losing
its hype.

Finally, when I had to choose a framework to work on I chose to go with
CodeIgniter for its freedom (no conventions) while giving you MVC (and models
being optional) and the dead simple but complete documentation.

PHP is like C#, startups don't talk about it but it's what the rest of the
world use.

------
ncash
We use CakePHP. Our MVP was hacked from Drupal, but we trashed that quickly
due to performance issues with our project management system.

I think there are plenty of startups using PHP. It just isn't quite as trendy,
so you don't hear about it as much. There are many reasons to pick PHP over
Ruby/Python. PHP and its frameworks tend to be quicker to start working with,
and PHP often executes faster (sometimes much faster) than Ruby or Python ever
will. Apps that need to scale would probably do better to use PHP/HipHop than
Django or Rails. Plus, there are definitely more PHP programmers out there
than Python/Ruby, so there is the added benefit of having a larger pool of
talent to hire from.

------
stephenr
I read an article recently saying that many VCs basically have hard ons for
things like Rails etc, regardless of any merits each language may or may not
have for the application being built.

Once again, corporate suits are driving technology decisions with little or no
relevant experience or training.

------
jterce
PHP is a tool. It's neither dead nor alive. Only your startup can be dead or
alive. Stop worrying and start writing with whatever tools you like.

------
masonhensley
We're building off of PHP because we feel most comfortable with it.
(Framework: CodeIgniter)

Anyone who writes us off for using PHP can get lost.

------
noduerme
Frameworks are for dummies. Startups should roll their own. On that front, PHP
is no better or worse than any other language. It just IS. If you're getting
hung up on what framework to use, because you can't roll your own code for a
bunch of custom pages, just use a damn CMS and stop pretending to be a coder
=)

~~~
true_religion
I disagree. Everyone should piggyback on the work done in the past until they
need something different. Then with the beauty of open source, they can.

Years ago, I worked with Symfony 1 under a start up brand. As the lead, I
extensively re-engineered Symfony to the point where very little of it was
left---the router, session software, configuration reader, caching mechanisms
were completely changed, and the database ORM (Propel at the time) was
extensively refactored.

However, we were in the business of making a product, finding users, and
delivering value---not the business of software architecture.

As such, we waited till we hit a pain point in the software before modifying
it. If we knew in advance that we needed something custom, we did so. If we
didn't then we didn't practice NIH egotism just for the sake of calling
ourselves "real coders(tm)".

