Ask HN: Is PHP/MySQL Still Practical for Building Web Applications?
I ask because there are so many open source projects based on PHP code, but from what I've read RoR is faster and easier to work with. I'd like to get opinions on the matter to reference for future decisions in startup development
40 comments
You can just as easily say RoR is slower (than, say, Symfony 2.0 on PHP with an opcode cache) and harder to work with (from a system administration perspective).
Take a look down the top 100 website list, and of those sites that are web applications, more of them will be built on PHP than not. I don't think there's even a Ruby application among the top 100 sites except parts of Twitter, but I could be forgetting something.
- Facebook
- Yahoo! (Answers, Bookmarks, Delicious, etc)
- Wikipedia
- WordPress (.com application is #19, another 14 million active installs of the free software)
- Flickr
It may not be cool right now, but it's certainly practical.
Take a look down the top 100 website list, and of those sites that are web applications, more of them will be built on PHP than not. I don't think there's even a Ruby application among the top 100 sites except parts of Twitter, but I could be forgetting something.
- Yahoo! (Answers, Bookmarks, Delicious, etc)
- Wikipedia
- WordPress (.com application is #19, another 14 million active installs of the free software)
- Flickr
It may not be cool right now, but it's certainly practical.
The problem with this argument is that all of the websites that you mentioned were founded before Ror or alternatives were mature enough. Adam D'Angelo (former CTO of Facebook) said that if Facebook was created now, they would not use PHP (source: http://www.facebook.com/note.php?note_id=137376312958147). I can imagine that the situation is similar with the other websites.
The article mentioned he used Python, which is a language I really enjoy working with, but not a framework. Does anyone know what framework D'Angelo is using?
Edit: to note that I used Quora to answer my own question: http://www.quora.com/What-languages-and-frameworks-were-used...
Edit: to note that I used Quora to answer my own question: http://www.quora.com/What-languages-and-frameworks-were-used...
You can just as easily say RoR is slower (than, say,
Symfony 2.0 on PHP with an opcode cache)
I use RoR for all our control panels and human interfaces at work. RoR is many things but fast isn't something I would call it.
codeigniter is VERY fast, and it doesn't get in your way. codeigniter is commonly referred to as the Ruby on Rails for php by some.
kohana 3 is more like RoR for PHP, CI is like RoR for PHP4 :)
Seconded, Kohana really wipes the floor with CI nowadays (this from someone still forced to maintain a couple of CI-based sites...) :P
I like Kohana much more than CI, if only for tossing PHP4 support.
However, but I've found that there is lots of fragmenting in the community/documentation. See the differences between 2.3.4 -> 2.4 (lots of breaking changes) -> 3.0 (almost entirely different framework). Which is kind of a bummer when using it for long-life projects (we have a few projects are stuck on 2.3.4).
That said - Symfony 2.0 looks fantastic, and very much like the next "Rails-like" PHP framework.
However, but I've found that there is lots of fragmenting in the community/documentation. See the differences between 2.3.4 -> 2.4 (lots of breaking changes) -> 3.0 (almost entirely different framework). Which is kind of a bummer when using it for long-life projects (we have a few projects are stuck on 2.3.4).
That said - Symfony 2.0 looks fantastic, and very much like the next "Rails-like" PHP framework.
Exactly the same story here. Our primary product is stuck on Kohana 2.3.4 because of the lack of care that the Kohana team put into backwards compatibility. I wouldn't be surprised if they decide to essentially rewrite things again in the future either. If I could go back in time, I'd pick something else.
Kohana 2 was "just a php5 fork of CI", while Kohana 3 is practically a whole new framework. The "problem" is that Kohana team doesn't like handicaping new versions for sake of complete backward compatibility.
They just make the framework better with every new version, although in case of Ko3 minor versions are backward compatible (for example 3.0.8 with 3.0.1., but 3.1.0 will not be, at least concerning the response object and the ORM logics).
They just make the framework better with every new version, although in case of Ko3 minor versions are backward compatible (for example 3.0.8 with 3.0.1., but 3.1.0 will not be, at least concerning the response object and the ORM logics).
Yep. We are in exactly the same situation. Even moving to 2.4 looks to be a pain. The only brightside is that it's not THAT big of a framework, so patching it is not too bad. But still...
that's exactly why I'll never use Kohana. I will have to look more into Symfony, however, before I can accurately compare.
It's extremely important to draw a distinction between cool and practical. HN is all about the cool new hotness. People here are always on the bleeding edge of technology, so they tend to flock towards those instead.
Also, hiring PHP developers is easier than <insert cool technology here> developers. There are just more people with PHP knowledge. Not saying that is a good reason to use a language, but it is a factor.
Also, hiring PHP developers is easier than <insert cool technology here> developers. There are just more people with PHP knowledge. Not saying that is a good reason to use a language, but it is a factor.
But when it comes to hiring _good_ developers, Python/Ruby/Lisp are definitely a better option.
In my experience, while it seemed at first that hiring PHP developers would be easier, it actually proved wrong, as we had to spend way more time to find _good_ developers among the mass than we would have if we were looking for, says, Python developers.
In my experience, while it seemed at first that hiring PHP developers would be easier, it actually proved wrong, as we had to spend way more time to find _good_ developers among the mass than we would have if we were looking for, says, Python developers.
My personal opinion about this is that the better/more driven/valuable developers are the ones who are quick to try new tech and follow emerging trends. Many people know PHP, but I think you'd likely find better talent in the long run if you offer a position that uses a more exciting back-end.
I'm in webdevelopment many years now and switching from php to ruby was a step I'll never regret. About the sysadmin perspective, I manage all my servers myself, used debian on my workdesk long enough to do this, and in the last year with all the stuff like bundler and the new rubygems.org it got so much easier. If you need it even more easier then Heroku is something you won't get elsewhere.
There are major Ruby Apps out there in the top 100: http://rails100.pbworks.com/Compete+Rankings
hulu.com yellowpages.com
also major sites: like justin.tv. slideshare etc
The argument that "Ruby cant scale" just doesn't hold. Check out Ruby EE by passenger.
hulu.com yellowpages.com
also major sites: like justin.tv. slideshare etc
The argument that "Ruby cant scale" just doesn't hold. Check out Ruby EE by passenger.
My personal opinion is that a project can be language agnostic. You can build in whatever you want. It doesn't matter if you build your app in php, ruby, python, asp or whatever, if you're a good coder you will produce good secure code, if you suck, so will your code.
So build in whatever you're most comfortable with and don't pick a language because of a superficial reason.
So build in whatever you're most comfortable with and don't pick a language because of a superficial reason.
Maybe the best answer. I would just add, that if you need to integrate with a special system like an already existing business application, just be sure to have a supported set of libraries to access it from within your web application. This is the only constraint that would make me discriminate a language against another outside of the very good points of Tam.
"It doesn't matter if you build your app in php, ruby, python, asp or whatever, if you're a good coder you will produce good secure code, if you suck, so will your code."
Can we please link to this in every new language discussion/flamewar?
Can we please link to this in every new language discussion/flamewar?
Isn't this the opposite of "pick the right tool for the job"? Building with whatever you're most comfortable seems to be a superficial reason. Different platforms/languages have real diversity in their strengths and weaknesses.
You raise a valid point if you're putting up a shelf. But if you're programming then you'll be at a disadvantage if you're not familiar with the tools at hand. Even a designer is going to suffer if they're made to use the Gimp when they're used to Photoshop, not because Gimp is or isn't a good tool but because the interaction is different.
Switching from Lightroom to Aperture I've noticed substantial differences in my photography, and I'm not a very good photographer. I'm considering switching back to Lightroom - I'm sure Aperture's great, but the learning curve is harder than switching from Vim to Emacs.
Switching from Lightroom to Aperture I've noticed substantial differences in my photography, and I'm not a very good photographer. I'm considering switching back to Lightroom - I'm sure Aperture's great, but the learning curve is harder than switching from Vim to Emacs.
I agree with this to a point. You should produce code in whatever language you are most proficient/comfortable with, pending that language is suitable for the domain in which you are producing code in. I wouldn't want to try to produce a web application in Assembly.NET, nor would I want to develop a low level component in Ruby. Depending on the domain, language becomes a bigger issue, which may result in you not having the ability to be language agnostic. But, in the overall sense, I do agree with what you're saying.
Build in whatever the people who are going to maintain it after you've moved on are comfortable with .... if you still bear some responsibility at that point.
There still is the question of how much time you're willing to spend to hunt down bugs in the interpreter/standard library/framework or to work around certain idiosyncracies that once upon a time might have looked like a cool idea. Will a "good coder" tolerate more or less such wtf moments?
I am a 15-year veteran of PHP and am still using it to build apps. Why? Because I have 15 years' of experience, and nothing surprises me anymore. I can fix nearly any bug in a very short time. Also, it's fast, mature, proven, and rock-solid, and I don't spend much time worrying about the surrounding infrastructure.
I haven't switched to Ruby personally yet because I am too busy to worry about having to spend hours/days dealing with issues that are new to me. OTOH I am allowing developers on my team to found new projects in Ruby since they already know the stack and I certainly have no aversion to learning new things.
PHP isn't a great language for applying the latest metaprogramming techniques and other modern patterns that make life easier. Although PHP 5.3 makes that much better with the addition of lambda, it's still tough to do certain types of patterns or write easily testable code in some circumstances. Mixins are also still a bit tricky since there's no language built-in for doing them.
However, some of the RFC's on grafts and traits are very promising in this regard, and frankly I think these patterns are better than doing the same in metaprogramming b/c the compiler can help you instead of delaying all errors to runtime.
In any case, if you don't already have lots of PHP experience I would recommend choosing a different language to build your knowledge base on. Ruby, python, clojure, javascript any of the other "hot" languages of today that attract lots of attention and offer a clear path in the future built on a solid foundation.
I haven't switched to Ruby personally yet because I am too busy to worry about having to spend hours/days dealing with issues that are new to me. OTOH I am allowing developers on my team to found new projects in Ruby since they already know the stack and I certainly have no aversion to learning new things.
PHP isn't a great language for applying the latest metaprogramming techniques and other modern patterns that make life easier. Although PHP 5.3 makes that much better with the addition of lambda, it's still tough to do certain types of patterns or write easily testable code in some circumstances. Mixins are also still a bit tricky since there's no language built-in for doing them.
However, some of the RFC's on grafts and traits are very promising in this regard, and frankly I think these patterns are better than doing the same in metaprogramming b/c the compiler can help you instead of delaying all errors to runtime.
In any case, if you don't already have lots of PHP experience I would recommend choosing a different language to build your knowledge base on. Ruby, python, clojure, javascript any of the other "hot" languages of today that attract lots of attention and offer a clear path in the future built on a solid foundation.
I've built a large application in CakePHP (and had plenty of PHP experience before that). For most things, it worked well. Last week, I started doing RoR again (after a couple of years), and it beats the hell out of any other ecosystem for webdevelopment. Ruby is (for me) a much better language than PHP. I've done a lot of Haskell, too, and Haskell is even a better language than Ruby, but doesn't have the same amount of web developers.
What's nice about Ruby is that there is a huge ecosystem. Ruby on Rails is already very complete (especially compared to PHP). There are a lot of plugins for Rails that add the functionality you want. For example: adding image uploads (including thumbnail generation) was about 15 minutes of work, adding comments to my models too, and voting on models/comments was also done by installing a plugin. In PHP, there's a lot of code available, but most of it doesn't integrate automatically with other code.
I think that the amount of smart people that are working on a language/framework is very important. In Haskell, for example, there are not too many people working on web frameworks, and there's still a lot missing or broken. In PHP, there are a lot of people working on the language/frameworks, but a lot of the smart developers have moved to other tools, such as Rails/Django/etc. Therefore, I would just follow them and use a framework like Rails.
(A slight warning: this is all very subjective, this post is not based on any objective facts)
What's nice about Ruby is that there is a huge ecosystem. Ruby on Rails is already very complete (especially compared to PHP). There are a lot of plugins for Rails that add the functionality you want. For example: adding image uploads (including thumbnail generation) was about 15 minutes of work, adding comments to my models too, and voting on models/comments was also done by installing a plugin. In PHP, there's a lot of code available, but most of it doesn't integrate automatically with other code.
I think that the amount of smart people that are working on a language/framework is very important. In Haskell, for example, there are not too many people working on web frameworks, and there's still a lot missing or broken. In PHP, there are a lot of people working on the language/frameworks, but a lot of the smart developers have moved to other tools, such as Rails/Django/etc. Therefore, I would just follow them and use a framework like Rails.
(A slight warning: this is all very subjective, this post is not based on any objective facts)
slightly offtopic: What did you use voting/commenting ? When I last looked none of the plugins in that area were maintained
One of my friends pointed me to this site: http://ruby-toolbox.com/, it's great for finding maintained plugins.
To answer your question: I used thumbs_up for voting, acts_as_commentable for comments, clearance for authentication and paperclip for file uploads.
I found thumbs_up before I knew of ruby-toolbox: I went to the acts_as_voteable github page, clicked on "Network" and scrolled to the right as far as possible. Most rubyists are very active on github, and a lot of the packages are forked.
To answer your question: I used thumbs_up for voting, acts_as_commentable for comments, clearance for authentication and paperclip for file uploads.
I found thumbs_up before I knew of ruby-toolbox: I went to the acts_as_voteable github page, clicked on "Network" and scrolled to the right as far as possible. Most rubyists are very active on github, and a lot of the packages are forked.
Thank you :) I was looking for something that integrates rating (not voting) and commenting in one package. I found this https://github.com/grimen/is_reviewable through the toolbox. But last commit is from 2009. Hopefully someone has forked it or I will have to fix it
Abandoned gems is one of the biggest problems I have with Ruby. Rubygems is starting to look like CPAN, which makes my sysadmin life hell.
I don't know. A lot of the smart PHP developers are still there. Maybe people using PHP moved on, but PHP devs are still strong.
As for PHP code, pear is still widely used for code distribution. Combined with pecl, and you have two resources for code distribution depending on how the code is integrated (PHP or C). And don't confuse pear as a library. It's a distribution method. For example, PHPUnit is installed via pear.
As for PHP code, pear is still widely used for code distribution. Combined with pecl, and you have two resources for code distribution depending on how the code is integrated (PHP or C). And don't confuse pear as a library. It's a distribution method. For example, PHPUnit is installed via pear.
While RoR is getting better in this respect, PHP is vastly better documented (both officially and all throughout the web) and the community is (at least, for now) superior to RoR. This is something that simply requires more time for RoR, as PHP has had quite a few years head start to get to where it is.
In practice, it honestly boils down to what you're doing and what's easier for you (and your team). If you want to test the waters, follow a few tutorials for each that you're unfamiliar with, and see what suits you better.
If you're using a shared server, you also have to make sure that your host supports RoR (most hosts don't). So that could be an extra expense to consider.
Me personally: I'm a php person. I prefer PHP + CodeIgniter, and I'm all happy :) RoR is fine and dandy, imo, but wasn't worth 9 years of PHP experience when PHP works amazingly well for everything I've ever asked of it.
In practice, it honestly boils down to what you're doing and what's easier for you (and your team). If you want to test the waters, follow a few tutorials for each that you're unfamiliar with, and see what suits you better.
If you're using a shared server, you also have to make sure that your host supports RoR (most hosts don't). So that could be an extra expense to consider.
Me personally: I'm a php person. I prefer PHP + CodeIgniter, and I'm all happy :) RoR is fine and dandy, imo, but wasn't worth 9 years of PHP experience when PHP works amazingly well for everything I've ever asked of it.
In practice, it honestly boils down to what you're doing and what's easier for you (and your team)
That's definitely a huge consideration, especially the team part. Plus, you're going to have a much easier time finding PHP developers than Ruby developers.
That's definitely a huge consideration, especially the team part. Plus, you're going to have a much easier time finding PHP developers than Ruby developers.
Whilst you may have an easier time finding PHP developers I actually think it is harder to find good/great PHP developers in comparison with Ruby devs. The reason for this is that Ruby/Rails development seems to focus more on TDD, CI, logic/display separation and other good practices, where as PHP, being older, hasn't traditionally had this approach. Having these practices at the core of what you do (IMO) makes you a better developer (not necessarily programmer).
It's hard to find good/great developers period and when you find them language is rarely a concern. It's easier to find PHP developers though and dispite wanting to you'll never get to staff your team with just great developers once you grow over a couple people.
Say you have a job posting and you get 100 php developers and 5 Ruby ones. Of those 5 ruby ones 3 will people people who watched the screen casts. 2 will be intermediate/senior. Of the 100 php developers 50 of them will be horrible. 40 will be junior level. 10 will be a mix of intermediate to senior.
(In my experience anyhow, my company currently uses primarily php for services and RoR for control panels so we hire for either and cross train)
Say you have a job posting and you get 100 php developers and 5 Ruby ones. Of those 5 ruby ones 3 will people people who watched the screen casts. 2 will be intermediate/senior. Of the 100 php developers 50 of them will be horrible. 40 will be junior level. 10 will be a mix of intermediate to senior.
(In my experience anyhow, my company currently uses primarily php for services and RoR for control panels so we hire for either and cross train)
> It's hard to find good/great developers period and when you find them language is rarely a concern
Totally correct, however, with Ruby I think it's easier to find them primarily as there are less Ruby devs about, and using your example above, more or them are intermediate/senior (40% for Ruby, 10% for PHP). Then again intermediate/senior != good/great.
(Disclaimer: we're a PHP shop, but know a lot of really talented Rubyists)
Totally correct, however, with Ruby I think it's easier to find them primarily as there are less Ruby devs about, and using your example above, more or them are intermediate/senior (40% for Ruby, 10% for PHP). Then again intermediate/senior != good/great.
(Disclaimer: we're a PHP shop, but know a lot of really talented Rubyists)
My point being that it's not easier to find them because there isn't as many of them available. The ratio may be better but the gross numbers aren't.
From my experience, a good way of weeding out the 50 horrible php programmers, is to ask about (even simple) OOP.
Then to differentiate Junior from Senior just ask them what testing tools they use (testing is not [as] ingrained in the PHP community [yet]). If they can talk intelligently about PHPUnit, mocking, etc. they are more than likely senior level, or at least passionate enough to learn more than most PHP developers.
Then to differentiate Junior from Senior just ask them what testing tools they use (testing is not [as] ingrained in the PHP community [yet]). If they can talk intelligently about PHPUnit, mocking, etc. they are more than likely senior level, or at least passionate enough to learn more than most PHP developers.
I disagree with the documentation point. Type in any Ruby class whether it's a standard class, something from Rails, or a gem and you'll find a community run rdoc page with a ton of information on it.
An rdoc is only as useful as it's included use-cases. About the best thing about PHP is the fact that there are zillions of included comments on the php documentation pages. While most are not at all what should run in production, a single good comment can give you a lot of insight as to how to use some code.
Tests != actual usage.
This is actually why a readme for a gem, plugin, extension, module etc. is so important, and why I think Github has been good for the developer community at large.
Tests != actual usage.
This is actually why a readme for a gem, plugin, extension, module etc. is so important, and why I think Github has been good for the developer community at large.
This has been my experience developing with PHP for many years. Especially in the early years, I found more code in the comments on PHP documentation than anywhere else (in documentation, on blogs, on Q&A sites). That the PHP community has always had this ability for its millions of users to aggregate code for common issues in one place makes its documentation much more extensive than it may appear at first glance.
I've run server ops (and do development) for significantly loaded RoR and PHP applications (and still do), and I can say that there is more quality information available for RoR than there is PHP for setting up high scale and stable setups.
When setting up a RoR stack, all the information I needed was available, the infrastructure was pretty stable and was easy to debug problems. PHP on the other hand, had close to no information on dealing with high load. The optcache libraries are poorly documented, nobody is really talking about it, and running anything but Apache (for performance, of course) under fcgi was horrifically problematic.
In the end we had to write our own monitoring tools to deal with all the oddities we discovered with the standard fcgi spawner (there were many), and when trying to mitigate memory leaks we discover that there are 'many known leaks in the PHP stdlib, but that's OK because everyone runs short-lived processes and restarts them regularly so we don't need to fix them'. My idea of a robust (fcgi) server would be that it doesn't require constant restarts, but that's just me.
RoR is only one framework in the vast number of Ruby libraries. I have worked in both technologies and there are more well designed, useful and current libraries and tools surrounding Ruby than there are PHP.
Quite honestly I'm sick of people apologising for it and pointing to the 'big players in web' as proof that PHP is OK. In my opinion it really needs to go away. In the years I worked with it, it taught me nothing but bad habits. I'm not the only one.
EDIT: Two Ruby libraries I used recently that were very high quality were Nokogiri (HTML/XML parsing) and Typhoeus (HTTP library wrapping libcurl). I don't recall ever seeing anything like those in PHP that had such intuitive APIs. Can anyone provide any counterpoints of better libraries in PHP that don't exist in Ruby? P.S. Wordpress is not an answer.
When setting up a RoR stack, all the information I needed was available, the infrastructure was pretty stable and was easy to debug problems. PHP on the other hand, had close to no information on dealing with high load. The optcache libraries are poorly documented, nobody is really talking about it, and running anything but Apache (for performance, of course) under fcgi was horrifically problematic.
In the end we had to write our own monitoring tools to deal with all the oddities we discovered with the standard fcgi spawner (there were many), and when trying to mitigate memory leaks we discover that there are 'many known leaks in the PHP stdlib, but that's OK because everyone runs short-lived processes and restarts them regularly so we don't need to fix them'. My idea of a robust (fcgi) server would be that it doesn't require constant restarts, but that's just me.
RoR is only one framework in the vast number of Ruby libraries. I have worked in both technologies and there are more well designed, useful and current libraries and tools surrounding Ruby than there are PHP.
Quite honestly I'm sick of people apologising for it and pointing to the 'big players in web' as proof that PHP is OK. In my opinion it really needs to go away. In the years I worked with it, it taught me nothing but bad habits. I'm not the only one.
EDIT: Two Ruby libraries I used recently that were very high quality were Nokogiri (HTML/XML parsing) and Typhoeus (HTTP library wrapping libcurl). I don't recall ever seeing anything like those in PHP that had such intuitive APIs. Can anyone provide any counterpoints of better libraries in PHP that don't exist in Ruby? P.S. Wordpress is not an answer.
I highly disagree that PHP has more quality information available than Ruby on Rails. Any time I've ever looked for anything on PHP all I get is ExpertsExchange quality (with the occasional gem on Stack Overflow), but a search for nearly any problem in Rails turns up a multitude of amazing blog posts, Google Groups posts, or gems that solve my exact problem. Failing that, IRC (or just digging through Ruby code which is easier to read than almost any language I have worked with) has been very helpful.
A big part of the reason that many of the biggest sites websites on the net now are made in Php, is because it was the most viable and popular option 5 years ago. In that time both Ruby and Python have made leaps of advances in using their technology for web development. Now both languages are faster than Php, and in general the popular frameworks in this languages also preach better practices.
I worked with Php for a couple of years and I can tell you that I absolutely thought the language was a melting pot of some great ideas with a huge bunch of WTF form the very beginning. In my opinion Php as a language is archaic and the only reason to use it now is because it makes sense for your team (because that's what your team has experience with). That being said, a good developer gets great stuff out the door regardless of what language they use to do so. Hell one of best developers I know is a Php junkie - with whom I always ended up having a slight language war with. The funny thing is that even tough he was the strongest Php advocate I know, he is now using Python for everything and agrees that it's a much better language.
Now I work almost exclusively with Ruby for webdevelopment (and also for a big part of my server scripts now that I mention it) because it just makes sense. The code is a lot more maintainable and scalable, though this is because it's generally the case that out of a batch of Ruby developers you will probably get more 'good' developers than out of a batch of Php developers with the same amount of people. It's my experience that its easy to get 50 Php developers, out of which only a couple are actually good ones, while if you get 10 Ruby devs, at least half are competent.
This rant is getting long so I'll just leave you with a thought. If the only developers you can get right now are Php devs, it makes sense to do your project in Php; however, if it's possible for you to get your hands on some Ruby or Python developers, you really can't go wrong by choosing either over Php, specially since doing so will generally have the benefits of a faster, better, and more maintainable codebase.
I worked with Php for a couple of years and I can tell you that I absolutely thought the language was a melting pot of some great ideas with a huge bunch of WTF form the very beginning. In my opinion Php as a language is archaic and the only reason to use it now is because it makes sense for your team (because that's what your team has experience with). That being said, a good developer gets great stuff out the door regardless of what language they use to do so. Hell one of best developers I know is a Php junkie - with whom I always ended up having a slight language war with. The funny thing is that even tough he was the strongest Php advocate I know, he is now using Python for everything and agrees that it's a much better language.
Now I work almost exclusively with Ruby for webdevelopment (and also for a big part of my server scripts now that I mention it) because it just makes sense. The code is a lot more maintainable and scalable, though this is because it's generally the case that out of a batch of Ruby developers you will probably get more 'good' developers than out of a batch of Php developers with the same amount of people. It's my experience that its easy to get 50 Php developers, out of which only a couple are actually good ones, while if you get 10 Ruby devs, at least half are competent.
This rant is getting long so I'll just leave you with a thought. If the only developers you can get right now are Php devs, it makes sense to do your project in Php; however, if it's possible for you to get your hands on some Ruby or Python developers, you really can't go wrong by choosing either over Php, specially since doing so will generally have the benefits of a faster, better, and more maintainable codebase.
I find the hardest problem to overcome with PHP is finding developers, as it isn't a particularly nice language to work with.
If you're not doing a computationally expensive startup, speed won't matter much. If you ever get to the size where it does (i.e. Facebook) - there are always solutions.
I've been seriously considering trying to start up an alternative language that takes the best parts out of PHP, but drops all the backwards compatible nonsense. It really has some great features but the annoyances will scare off most top developers - and you're left with a crowd of 85% script kiddies and only 15% developers that actually learnt to use the language properly... and trying to find one of those 15% isnt easy.
If you're not doing a computationally expensive startup, speed won't matter much. If you ever get to the size where it does (i.e. Facebook) - there are always solutions.
I've been seriously considering trying to start up an alternative language that takes the best parts out of PHP, but drops all the backwards compatible nonsense. It really has some great features but the annoyances will scare off most top developers - and you're left with a crowd of 85% script kiddies and only 15% developers that actually learnt to use the language properly... and trying to find one of those 15% isnt easy.
That would be Python!
It all comes down to the code. Good code in a bad language is better than bad code in a great language. The nice thing about RoR is it kinda forces you to do a few 'best practices things' so even newbie developers tend to end up with 'ok' code. Of course, there are many PHP frameworks that also apply this sort of way of coding.
Also, note that there will be a learning curve (probably small, but you will notice it) when you first start learning rails. Like all new languages, you'll overcome this eventually.
There is really no reason to choose one or the other. You basically already know the answer. Whenever people ask me this question I say 'What do you think the pros/cons are for each language?' and then right after they list them I say 'ok, pick one'. This is really not a subject worth dwelling on with established languages/frameworks.
PS: If it were me, I'd choose RoR :)
Also, note that there will be a learning curve (probably small, but you will notice it) when you first start learning rails. Like all new languages, you'll overcome this eventually.
There is really no reason to choose one or the other. You basically already know the answer. Whenever people ask me this question I say 'What do you think the pros/cons are for each language?' and then right after they list them I say 'ok, pick one'. This is really not a subject worth dwelling on with established languages/frameworks.
PS: If it were me, I'd choose RoR :)
What's the worst is bad code in a bad language. Having a web framework would make things much more systematic, while raw speed is going to be a hit on (compare raw PHP with CakePHP 1.1, for example).
Absolutely. The point has been made here already, but PHP + (Framework of your choice) + MySQL can still be used to produce great web applications quickly and easily. My framework of choice happens to be Symfony, but there are many good options. I also really like Compass for CSS and Capistrano for deployment (both borrowed from the Ruby folks) and that's fine too; they don't require any server-side Ruby support to be useful.
I would argue that a lot of the frameworks seem to be converging in ideas and functionality and borrowing heavily from each other, so whether you use PHP/Symfony, Ruby/Rails, Python/Django or whatever you probably will have more shared core concepts across them than differences. I think that a more interesting question would be "Is PHP/MySQL still practical for building web applications if I don't use a framework?" And the answer there is "that depends..." :-)
I would argue that a lot of the frameworks seem to be converging in ideas and functionality and borrowing heavily from each other, so whether you use PHP/Symfony, Ruby/Rails, Python/Django or whatever you probably will have more shared core concepts across them than differences. I think that a more interesting question would be "Is PHP/MySQL still practical for building web applications if I don't use a framework?" And the answer there is "that depends..." :-)
It's about the developer, not the language. Just write good code and the language at the beginning won't really make a difference. If you like rails but you are more comfortable with PHP, maybe you could try CakePHP or Codeigniter. Even Python/Django could be an option you should consider.
Also for RoR you could use Heroku that makes deployment a breeze, but definitely when it comes to resources Ruby is way more expensive than PHP.
Also for RoR you could use Heroku that makes deployment a breeze, but definitely when it comes to resources Ruby is way more expensive than PHP.
PHP is not equivalent to Rails. It would be more accurate to compare PHP to Ruby and compare Rails to a PHP framework like Kohana.
I've worked with both Kohana and Rails. Rails is more popular so it is easier to find solutions and add-ons. However, it does a lot of things by 'magic' and a beginner will have a hard time modifying rails source or creating a gem (if they want to do something non-default). Kohana on the other hand is easier to understand, extend, and modify, because the entire source is in your project folder as PHP code.
Good luck!
I've worked with both Kohana and Rails. Rails is more popular so it is easier to find solutions and add-ons. However, it does a lot of things by 'magic' and a beginner will have a hard time modifying rails source or creating a gem (if they want to do something non-default). Kohana on the other hand is easier to understand, extend, and modify, because the entire source is in your project folder as PHP code.
Good luck!
One nice thing about PHP is that despite its archaism it keeps growing as a language. The 5.3 release alone added anonymous functions, namespaces, consts and many internal improvements. I recently rewrote one of my projects from the 4.x era for version 5.3 and found myself thinking that I don't hate PHP so much anymore. I still don't like it either, but at least I know the language is in good hands anyway.
The problem is that they add them without breaking any backwards compatability, so you end up with unpleasantries like the \ namespace separator.
On the other hand breaking compatibility the way they did with Python 3 is reckless. Ask someone who has a huge code base with, say, test scripts that do 'print' a lot if they are eager to switch to Python 3.
That's an easy enough fix, and one that's handled quite well by 2to3. In fact, 2to3 handles most things, although there is of course some stuff that needs to be done by humans. But that stuff is certainly not 'print'.
Lately these questions and discussions are everywhere and most times I think people are missing the point: it's all about code you want to write.
We created all those high level languages to make code easy to read, to make them people understand. I mean you could probably write your website in Assembla but the language won't help you to write down what you really want.
As a developer you are trying to develop something you do not want to mess around with a language. The language you use should help you focus on what you want to develop not distracting you with "ugly" code.
If you understand what the code is doing (even if you coded it on your own you sometimes have to think about what is going on there) it lets you help to focus on your goals.
If you brain works better with PHP code you should probably use PHP as your coding language but if not you should try something else like Python, Ruby or maybe Haskel until you find a language which is boosting you while developing. Don't get me wrong I don't say a programming language should do everything for you while you are drinking coffee. No, it should help you to think better what to implement next and how to implement it. It should support you while reading and understanding.
Again, we only created all those high level languages to make it easier to understand.
And now my standpoint to PHP: I don't like PHP cause it is a noisy language IMO. PHP is not OOP. You can use OOP in PHP 5 but the PHP core is not OOP so this seems weird. Even in PHP 5 you can't get a string length like: $str->length No you have to use strlen($str) and this is ugly.
Also I don't like those "symbols" PHP is using (maybe symbols are not the correct word here but I can't find a better fitting word at the moment). In PHP you have variable names with a $ symbol. Why? I don't know but this doesn't work for human beings cause human brains are assuming the dollar symbol has something to do with money or numbers but in PHP it's not. So you have to getting used to it.
It's really the same with the "dot" symbol in PHP. You wouldn't expect that it's concatenating strings.
Ruby as language is for me like reading a book. For example you can write code like this: if user.has_comments? ... end
That's why I love Ruby and I would prefer working with RoR for my project cause it helps you on rapid development.
One last thing: Ruby lets your focus on what you want to build without noise that's why (IMO) there are so much gems and a really huge community!
(Sorry for my bad english, it's not my primary language. I'm working on it :)
EDIT: corrected some typos.
We created all those high level languages to make code easy to read, to make them people understand. I mean you could probably write your website in Assembla but the language won't help you to write down what you really want.
As a developer you are trying to develop something you do not want to mess around with a language. The language you use should help you focus on what you want to develop not distracting you with "ugly" code.
If you understand what the code is doing (even if you coded it on your own you sometimes have to think about what is going on there) it lets you help to focus on your goals.
If you brain works better with PHP code you should probably use PHP as your coding language but if not you should try something else like Python, Ruby or maybe Haskel until you find a language which is boosting you while developing. Don't get me wrong I don't say a programming language should do everything for you while you are drinking coffee. No, it should help you to think better what to implement next and how to implement it. It should support you while reading and understanding.
Again, we only created all those high level languages to make it easier to understand.
And now my standpoint to PHP: I don't like PHP cause it is a noisy language IMO. PHP is not OOP. You can use OOP in PHP 5 but the PHP core is not OOP so this seems weird. Even in PHP 5 you can't get a string length like: $str->length No you have to use strlen($str) and this is ugly.
Also I don't like those "symbols" PHP is using (maybe symbols are not the correct word here but I can't find a better fitting word at the moment). In PHP you have variable names with a $ symbol. Why? I don't know but this doesn't work for human beings cause human brains are assuming the dollar symbol has something to do with money or numbers but in PHP it's not. So you have to getting used to it.
It's really the same with the "dot" symbol in PHP. You wouldn't expect that it's concatenating strings.
Ruby as language is for me like reading a book. For example you can write code like this: if user.has_comments? ... end
That's why I love Ruby and I would prefer working with RoR for my project cause it helps you on rapid development.
One last thing: Ruby lets your focus on what you want to build without noise that's why (IMO) there are so much gems and a really huge community!
(Sorry for my bad english, it's not my primary language. I'm working on it :)
EDIT: corrected some typos.
Informative: I believe the term you are referring to is Sigil
http://en.wikipedia.org/wiki/Sigil_(computer_programming)
I actually never found having the dollar sign as a sigil was any problem. There are a lot of punctuation symbols used in programming that are not used the same way as they are used in English grammar. In English, you don't create a new paragraph for every line indented in, the ^ sign is not often used for exclusive or, % is not used for modulus, and * is not used for multiplication.
You could also probably make a length function which returns strlen($str) if you really wanted to have $str->length.
I actually never found having the dollar sign as a sigil was any problem. There are a lot of punctuation symbols used in programming that are not used the same way as they are used in English grammar. In English, you don't create a new paragraph for every line indented in, the ^ sign is not often used for exclusive or, % is not used for modulus, and * is not used for multiplication.
You could also probably make a length function which returns strlen($str) if you really wanted to have $str->length.
I like the dollar prefix for variables. But each to their own.
I agree that PHP is a noisy language and I feel that it has a few sad inconsistencies with some of it's more common functions. Remembering parameter order in functions like in_array($needle, $haystack) is sometimes difficult as the choice they've made is arbitrary.
I code in PHP everyday and have to look up functions every few days to remind myself of silly stuff like that.
not to be judgemental but it seems like you are new to programming and have a bias towards the new languages because its mainly all you have used.
PHP is based mainly off C-syntax and although the $ sign for variables is something new (and not an issue to me), the "dot" symbol is extremely familiar for those that have programmed in C/C++. It makes sense that a string would use "dot" (think of ...) for concatenation and an integer or numeric value would use "plus"+.
Your points are valid but I think the syntax behind PHP is great, maybe it could be better at OOP when calling to functions (as one person mentioned) but I am very happy with it.
PHP is based mainly off C-syntax and although the $ sign for variables is something new (and not an issue to me), the "dot" symbol is extremely familiar for those that have programmed in C/C++. It makes sense that a string would use "dot" (think of ...) for concatenation and an integer or numeric value would use "plus"+.
Your points are valid but I think the syntax behind PHP is great, maybe it could be better at OOP when calling to functions (as one person mentioned) but I am very happy with it.
FYI, your English looks rather good for someone who's learning it. The only real issue I saw is how you make almost every sentence into it's own paragraph.
Thank you for your tip. You are right my comment has to many paragraphs in it and they are often misplaced.
I will try to improve that.
These answers are all pretty long. The answer is yes, definitely, without a doubt. Practical means "for use in practice" and PHP powers a lot of your daily web applications, especially the simpler ones. Judging from your question text, at your skill level, PHP is sufficient if not ideal for development, deployment, and performance.
MySQL is also fast and easy.
MySQL is also fast and easy.
Launching a new site on the PHP/MySQL combo (with CakePHP as the framework) on monday so there better not be.
I do have to say, being a single coder/sysadmin/tech-cofounder, it has been an uphill battle and really it's a full-time job, but I make do with a couple of hours on the side as a student.
I do have to say, being a single coder/sysadmin/tech-cofounder, it has been an uphill battle and really it's a full-time job, but I make do with a couple of hours on the side as a student.
I have been doing RoR for over three years now and absolutely love it. A few things make it great
* The best practices are well documented and if you follow them, you are gonna end up with good code. Good code helps you iterate faster (and with more confidence) and thats crucial when building a startup.
* There is pretty good documentation available and tons of great books that you can read. Also with every release, it gets easier to do things in Rails. Ofcourse you should have test coverage to make sure that you can upgrade rails easily. This basically boils down to the first advice about following best practices.
Basically to get most out of rails, you have to buy their philosophy and follow the best practices. If you do, you can be assured of great productivity and programmer joy :)
* The best practices are well documented and if you follow them, you are gonna end up with good code. Good code helps you iterate faster (and with more confidence) and thats crucial when building a startup.
* There is pretty good documentation available and tons of great books that you can read. Also with every release, it gets easier to do things in Rails. Ofcourse you should have test coverage to make sure that you can upgrade rails easily. This basically boils down to the first advice about following best practices.
Basically to get most out of rails, you have to buy their philosophy and follow the best practices. If you do, you can be assured of great productivity and programmer joy :)
If you are a software entrepreneur as opposed to an individual coder, one of the things you have to consider is how easy it is to hire someone who knows the platform or language you've selected. It's a fact that in the US and around the world, PHP developers outnumber Ruby developers by a significant margin, probably at least an order of magnitude.
In some ways, this may seem like an unfair comparison (by way of analogy, pedestrians outnumber drivers around the world as well). This doesn't address whether Ruby is "better" or not than PHP (or Smalltalk, etc.), it only has to do with what a startup engineering manager will have to contend with if an when your startup gets traction and you need to start hiring people at a particular moment in time.
In some ways, this may seem like an unfair comparison (by way of analogy, pedestrians outnumber drivers around the world as well). This doesn't address whether Ruby is "better" or not than PHP (or Smalltalk, etc.), it only has to do with what a startup engineering manager will have to contend with if an when your startup gets traction and you need to start hiring people at a particular moment in time.
But you have to ask yourself what your new hires are going to be bringing to your company? Are you going to be hiring dinosaurs or mammals?
I'm not sure what this means, but I think it reflects an incorrect bias that everyone you ever hire must necessarily be "plug and play". This assumes that humans are not educable which is not the case with the possible exception of certain conservative legislators.
PHP is totally fine. The question is more: Do you like, do you want to work with PHP, or do you want to work with Python, Ruby, Smalltalk, Lisp, etc.
By the sounds of it Python or Ruby seem to be the best options. I've done light PHP work for a year or two before but wouldn't say I'm an expert of any sort. Thus why I'm so open to switching into learning a more "modern" language
I do have some future-direction worries about php (the 6 dev process has had some ... quirks; like "let's just bin this and start over") and mysql (re: acquisition by oracle and ensuing staff departures, forked projects, etc.). But they're still fine for a proof of concept implementation. Not many architectures survive contact with real use unchanged, so having to buttress (e.g. op code or data caching) or swap out components entirely is not unheard of. Sometimes the best way to understand a system is to build it, so even if you do end up rebuilding it in whole or in part, at least you've learned the hard lessons about how everything hangs together to make it work right.
PHP and mysql are dead stupid easy to get started with. An mvc framework like symfony/kohana/zend/etc. can help speed dev time for your PoC, but most of them are performance hogs so you'll probably have to buttress that (APC, memcache, etc.) if you do end up having to scale. All this stuff's widely supported and retarded easy to deploy usually.
RoR is a bit more of a moving target at the moment. Which means docs can/do lag the bleeding edge quite a bit, standard OS distribution packages are frequently out of date (or just out right retarded e.g. debian's disabling of rubygem self update), and the best practices for deploying and scaling are in a state of flux. (I think currently the recommended way is phusion's passenger/mod_rails or whatever it is, for apache/nginx anyway. Or has the state of the art moved on again?)
PHP and mysql are dead stupid easy to get started with. An mvc framework like symfony/kohana/zend/etc. can help speed dev time for your PoC, but most of them are performance hogs so you'll probably have to buttress that (APC, memcache, etc.) if you do end up having to scale. All this stuff's widely supported and retarded easy to deploy usually.
RoR is a bit more of a moving target at the moment. Which means docs can/do lag the bleeding edge quite a bit, standard OS distribution packages are frequently out of date (or just out right retarded e.g. debian's disabling of rubygem self update), and the best practices for deploying and scaling are in a state of flux. (I think currently the recommended way is phusion's passenger/mod_rails or whatever it is, for apache/nginx anyway. Or has the state of the art moved on again?)
As for the title of your question, sure, PHP/MySQL are stil practical. If the answer to your question were no, then that would mean companies like Facebook and Yahoo aren't practical.
With regard to your future decisions, you might strongly consider another language and framework, not because one is more practical than another, but because the developers behind that framework may have more of a propensity towards the context of your startup. So, for example, Ruby has a large web application community, Python has a large scientific community, and Java enterprise.
The primary contention behind PHP has largely been it's limited OO and speed, as compared to it's brethren interpreted languages. You can, creatively, do advanced things in PHP which are done in other languages, but it's not as straight forward and often clumsy or not supported. That said, PHP is simple enough that large implementations can easily modify PHP for their own use; considering how slow PHP's codebase moves, forward compatibility is far less of an issue.
All together I wouldn't base your decision on speed. Computing power is cheap now and all of them are feasible as far as speed is concerned. If you need to build something NOW, strongly considering going with what you know. If you have more time, consider writing something cliche like a multi-user blog or twitter platform with each framework -- you'll be exposed to patterns you haven't seen before and can also figure out what you like and don't like.
With regard to your future decisions, you might strongly consider another language and framework, not because one is more practical than another, but because the developers behind that framework may have more of a propensity towards the context of your startup. So, for example, Ruby has a large web application community, Python has a large scientific community, and Java enterprise.
The primary contention behind PHP has largely been it's limited OO and speed, as compared to it's brethren interpreted languages. You can, creatively, do advanced things in PHP which are done in other languages, but it's not as straight forward and often clumsy or not supported. That said, PHP is simple enough that large implementations can easily modify PHP for their own use; considering how slow PHP's codebase moves, forward compatibility is far less of an issue.
All together I wouldn't base your decision on speed. Computing power is cheap now and all of them are feasible as far as speed is concerned. If you need to build something NOW, strongly considering going with what you know. If you have more time, consider writing something cliche like a multi-user blog or twitter platform with each framework -- you'll be exposed to patterns you haven't seen before and can also figure out what you like and don't like.
Servers are cheap, programmers are expensive and bugs can kill you.
I suggest going with whatever gives you clean and correct code faster. I wouldn't suggest PHP for a new project. If you already have a big codebase written in PHP, you should keep it, but by "keep" I mean maintaining and cleaning up, not only adding to.
As for MySQL, it's good enough unless you get too successful - then it becomes painful to keep it going. Mostly any RDBMS has this problem. Again, for a new project, I'd go with PostgreSQL, but that's more a matter of taste.
I suggest going with whatever gives you clean and correct code faster. I wouldn't suggest PHP for a new project. If you already have a big codebase written in PHP, you should keep it, but by "keep" I mean maintaining and cleaning up, not only adding to.
As for MySQL, it's good enough unless you get too successful - then it becomes painful to keep it going. Mostly any RDBMS has this problem. Again, for a new project, I'd go with PostgreSQL, but that's more a matter of taste.
Yes it's very practical.
Finding a hosting solution for PHP is not going to be to difficult.
It's not going to 'go away' anytime soon, certainly not before it becomes time to re-write your codebase.
The docs are good.
Whether or not there is something which does any of those points better does not change the answer to the actual question. Yes, PHP/MySQL is still practical for building web apps.
Finding a hosting solution for PHP is not going to be to difficult.
It's not going to 'go away' anytime soon, certainly not before it becomes time to re-write your codebase.
The docs are good.
Whether or not there is something which does any of those points better does not change the answer to the actual question. Yes, PHP/MySQL is still practical for building web apps.
I hate php, and don't really like mysql.
Yes. It is quite practical.
Yes. It is quite practical.
Use what makes you happy, building a startup will be have many more pressing questions than the choice of language. Trying to make sure you use a 'cool' technology is probably not going to worth the time.
Good luck.
Good luck.
Build your webapp in a way where migrating parts of it to better suited technologies isn't impossible, and if/when you feel the need to migrate from PHP/MySQL, you'll be able to do so.
Any advise you can get by asking such a broad question, is anecdotal. From a technical point of view, it usually doesn't matter - You can build applications on both platforms. If your application is atypical, there might be a point in picking one over the other, but what really matters is the people that should work with it. If you have php programmers at hand, using php is probably a better idea.
there is another comment that speaks to this ("it comes down to code"), but i'd just like to say - use what ever you can to get the job done, then think about porting/optimizing/frameworks...
TO the question at hand - Yes - php and sql can get the job done... i mean are you building it for 1,000 users? or 100,000? php and sql can handle both...
Code tight and code well, tell everyone else to go to hell
TO the question at hand - Yes - php and sql can get the job done... i mean are you building it for 1,000 users? or 100,000? php and sql can handle both...
Code tight and code well, tell everyone else to go to hell
yes. languages are tools. use what you need to get the job done.
if you know PHP and C, it'll be much easier and faster for you to build your startup with PHP and C, instead of toughing it out learning RoR enough to get things done. perhaps RoR is "faster" and "easier", but it won't be faster and easier for you until you're competent with it, and that takes time.
if you know PHP and C, it'll be much easier and faster for you to build your startup with PHP and C, instead of toughing it out learning RoR enough to get things done. perhaps RoR is "faster" and "easier", but it won't be faster and easier for you until you're competent with it, and that takes time.
Visual Website Optimizer is built on PHP/MySQL stack (but we do use Redis for queue). And the application is serving 15+ million requests _daily_. So, it is certainly possible to build a good enough application on PHP/MySQL.
Oracle just put a price on InnoDB. So unless you got $2000 a year - NO.
http://www.mysql.com/products/
Postgresql is your next choice.
Postgresql is your next choice.
Not true. Nothing has changed, MySQL is still under a GPL/commercial dual license. If you're not embedding, then of course InnoDB is free.
FYI: InnoDB is transaction safe. MyISAM being ok for basic things.
I would say if you're using MyISAM for basic things, you might as well go with SQLite.
agreed
That's actually what I'm looking at right now. I'm half way into my project and it's all freaking mysql :( On the plus side, the SQL is abstracted decently enough that I don't have to change my body of code to any major degree.
Any experience or articles you like that talk about transitioning between the two?
Any experience or articles you like that talk about transitioning between the two?
Practical? Yes. Ideal? Maybe.
There are a lot of really good PHP developers around. But for ease of development and community support on a brand new project I'd probably go with Ruby or Python.
There are a lot of really good PHP developers around. But for ease of development and community support on a brand new project I'd probably go with Ruby or Python.
Your biggest risk is not shipping, use the tools that make you happy and productive to help get past that as quickly as possible. Solve the rest when you get there.
Having seen first hand the problems of transitioning a busy site built on pure PHP to ROR and the (ongoing) performance and scaling issues I would be very careful,
Yes, just use a good framework like Yii (http://www.yiiframework.com) to smooth out the warts.
Does anyone use WebObjects for developing web applications? Can someone compare it Python/Ruby for development?
Yes, it's practical. I'd use Postgres rather than MySQL if possible.
Practical? Yes. Desirable? Depends on who is going to maintain it.
Yes
[deleted]