11–20 of 104 posts
So build in whatever you're most comfortable with and don't pick a language because of a superficial reason.
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 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?)
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…
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.
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.
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.
Earlier quoted context omitted.
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.
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…
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)
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.
Earlier quoted context omitted.
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 importan…