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.
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)
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.
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).
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.
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.
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.
So build in whatever you're most comfortable with and don't pick a language because of a superficial reason.
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.
Can we please link to this in every new language discussion/flamewar?
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.
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)
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.
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.
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.
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.
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)
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)
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.
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.
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 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.
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.
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 :)
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..." :-)
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.
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!
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.
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.
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.
MySQL is also fast and easy.
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.
* 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 :)
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.
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?)
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.
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.
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.
Yes. It is quite practical.
Good luck.
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
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.
Postgresql is your next choice.
Any experience or articles you like that talk about transitioning between the two?
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.