Slashdot Mirror
PHP5 Vs. CakePHP Vs. RubyOnRails?
OldJavaHack writes "If you could start a website (with MySQL for persistence) from scratch and you had a choice of PHP5, CakePHP, or RubyOnRails — which would you choose and why? Things to consider in your decision: 1. Maturity of solution; 2. Features; 3. Size of community of skilled users (to build a team); 4. Complexity/ease of use (for neophytes to master); 5. Greatest strength of your choice, and the greatest weaknesses of the other two. Here is a comparison of capabilities."
Next?
Web2.0: I love when people Flickr my cuil and digg my boingboing until my google is reddit and I start to yahoo
Great, a link to a wikipedia article. Wonderful.
After all, I am strangely colored.
This seems to be yet another kdawson story which exists to solely promote the "my X is better than yours" bashing, trolling and flames that always seem to follow these stories. Come on, can we get a new editor already?
I can't comment on Ruby on Rails, but PHP (yes, even PHP5) is such an horrible language. Yes, it's widely available and is pretty much the only option out there for free/cheap hosts, but I just don't understand why someone would choose to use it in any serious project.
JSP and ASP.Net (Yes, I know, this is Slashdot) are, IMHO, much more much more powerful and pleasant to work with. If I had to pick amongst the proposed solutions, I'd pick RoR if only for the fact that Ruby is a nice language. I don't know about Rails' features but I could at least trust the language it's built on.
I've worked in all three, repeatedly, and there's really no contest. Rails is so much easier to get concepts out, and has so many fewer bugs (in my experience), that it's silly to use PHP at this point, unless you have overriding reasons for choosing it aside from inherent qualities.
Django.
... real journalists and good standards!
Of course, that's just me.
This is more an ask slashdot post. And even so, CakePHP and RoR are frameworks while PHP is a language.
That being said, CakePHP is fantastic and for anything past simple scripts, I am finding CakePHP speeds up development greatly.
There are different things that you can do with a website, so first of all it really depends on what you are intending. PHP5 will be great for building creating more traditional websites that are driven by HTML forms, and is probably the best thing to use for such purposes. Ruby on Rails seems to be meant for if you are planning to build AJAX apps. It's fairly easy, with a lower learning curve, but does have scalability issues. Another option that you might consider if you are looking for AJAX stuff would be GWT, the Google Web Toolkit. Larger learning curve, but very fast web apps. Really though, comparing PHP5 and RoR seems kind of like comparing apples and oranges. Just remember, figure out what you are trying to do first, then pick the language.
Any halfway skilled programmer will be able to do useful work with any of those frameworks fairly early on, but all of them are also very rich environments, so there's always more to learn.
I've written web apps in an ungodly tangle of PHP4 and PHP 5 and Perl and using Ruby on Rails. Currently Ruby on Rails is in favor, but is far from perfect.
Probably most of my frustration with Rails and PHP 5 has to do with Active Record. My big gripes are: (1) Schemas, entity-relationship diagrams, and queries tell me how an application works -- with Active Record this information is strewn across a whole bunch of files (especially in Rails); (2) Database-independence is a nice idea, but in reality, how often over the lifetime of your website will you migrate to a different database? Usually your database is chosen for you. Usually a switching databases involves coordinating with a lot of people who you'd usually rather not have to deal with -- those issues will take far more time and energy than differences between MySQL and Oracle; (3) a pretty common design pattern for web pages is to have a form that let's you fill in a few parameters (date, maybe geographical information) into a huge multi-table select statement -- you can do that in Active Record, but basically all you gain is a marginally fancier wrapper than you would have with DBI.
http://framework.zend.com/ end of story.
-mb
May I remind you all of this:
http://www.flickr.com/photos/planetargon/1279842 54/
Yes, that's the creator of RoR talking about what he feels about other people not liking his framework. RoR is all about pretty code, if you don't like RoR, use something else.
So, that sorted that out. Now, troll!
I use HTML(TM).
Django anyone ?
Son of a submariner ! They'll pay for this...
Everything I needed to know about life, I learnt from Blake's Seven
http://grails.codehaus.org/
http://www.opensymphony.com/webwork/
Given complete freedom, my choice is Django: http://www.djangoproject.com/
a l01/
Check out the tutorial, and you'll know why: http://www.djangoproject.com/documentation/tutori
.: Max Romantschuk
What about the requirements of the, you know, actual website application?
You've provided no information on the actual website that you intend to develop. That's the important part -- the features and functionality to the customers and end users.
Instead of considering the features of the language and framework first, how about the features of the application? How many users? Who will be supporting it? What kind of server resources are available? Do you need internationalization? What's the roadmap for the site over the next 3 to 5 years? Maybee then you can map the features of the website to the features of the framework or language, such as the maturity of the libraries directly related to your webapp.
But picking the implementation language independent of the functionality of the website is a classic sign of solving the wrong problem. I don't care what you program it in, if you're asking these questions first, you are programming it in the wrong language.
Who said Freedom was Fair?
Or another Java framework, due to the maturity, scalability, availability of libraries, and number of people who know it.
Rails just does not have a stable server. Webrick + fastCGI, or Mongrel, they both crash regularly for us. Also I've had to maintain several Rails apps written by others, and it sucks. All those neat tricks that makes it "productive" for the first programmer makes it difficult to understand and maintain for everyone else.
How about using Python and Django? Python is a much cleaner language than both PHP and Ruby, and Django makes it a joy to build web-sites.
I've been lead developer of a large enterprise system written in PHP for the last few years, and grown increasingly frustrated with just how ugly PHP is. Object-orientation has been tacked on as an after-thought (almost all of the API is procedural, without using exceptions for error-handling), the API is messy and inconsistent, it's somewhat inefficient (has to parse all the code for each request, unless you use an opcode cache), and the syntax is just plain ugly when compared to Python.
Never tried Ruby on Rails, but you should at least give Django a spin before deciding.
... because I know it and I know it does the job. Also saves me the work of figuring out what CakePHP and RoR is.
Visit http://ringbreak.dnd.utwente.nl/~mrjb/growingbettersoftware to download your free copy of the book
I've never used Ruby or RoR... my experience with PHP is limited as well...
In other words, you were trolling. :-)
Having done websites in PHP, Rails, Python and Java, I can say that they all suck one way or another. Ruby and Rails are both very different from PHP and my personal unconfirmed suspicion is that a lot of the Rails problems people have are from programmers who jump over into Rails without first learning what they're getting themselves into. Deploying Rails can be very difficult and you can face a lot of issues that you would never face for PHP.
Personally, I prefer Python or Ruby over PHP any day.
Who said Freedom was Fair?
What we have here is another usual question that all really depends on your project type. That being said, I'll try to break from the typical, slashdot format and attempt to address your question:
P.S. A similar question of Rails vs PHP vs Java question was somewhat subjectively discussed late last year http://www.cmswire.com/cms/industry-news/php-vs-ja va-vs-ruby-000887.php
Travature.com: Hello...World
Amen. Postgres's row-level locking and schema transactions alone make it far superior, I think.
There was a good video, although outdated (2005), that had two of the main developers of Django and RoR. The video is quite long (3hrs), so I'll link to the Google Video Search. The second and third are each person's presentation, and the fourth, which I recommend, is a Q/A session.
-metric
"but in reality, how often over the lifetime of your website will you migrate to a different database?"
If you told me I could pick either the database to use or the scripting language to code in, I'd pick Postgresql and let you pick the language. Most of the things people try to do in scripting languages can be handled in the database much more elegantly and scalably. Of course, most people don't realize this because they've only used MySQL and don't realize how much it's missing.
If you told me I could pick both, I'd go with Perl, unless I were doing something very simple that's been done a thousand times before.
PHP is decent enough for what it is. Historically there have been security problems with it, and the design is crappy. But it's quick and easy.
I've never used Rails, but it sounds like it does a lot for you. In my experience, that can be a blessing if you're doing something textbook. If not, have fun fighting with the assumptions other people made.
If moderation could change anything, it would be illegal.
have you considered symfony? I've done a few sites for customers using it and it's great!!
php does no have a good ide, ruby on rails has netbeans.
Thirdeded or second second.
CakePHP vs PHP5? Do they think that PHP5 is a framework? Has the name not tipped them off that CakePHP is written in PHP? How can you have PHP vs. "thing written in PHP"?
+1 Fucking Spot On
As for myself it's not my homework it's my hobby and I care to read about why people think one is better than the other or what else could be thrown into the game. I think about learning Rails and Ruby so I found it quite interesting to be recommended Python and Django as well. So shut up and let people post here. The intention of Ask Slashdot is obviously not only to answer some persons question but to post a question that might be relevant to many.
I recently finished a long comparison of PostgreSQL and MySQL in the context of mission-critical data that gives a lot more detail on the issues you bring up here.
imho django is really the easiest web framework to develop in.. It's ORM is flexible and powerful but compared to hibernate & co so much simpler that it is just shocking ..
i have developed in perl, php, java (webwork with hibernate and IoC containers and what-not) but with django you can get things done much faster and get cleaner results..
(and some self-advertising - look at my project http://sct.sphene.net/ - forum & wiki applications based on django)
Find me at http://herbert.poul.at
Whether it's Ruby on Rails, or Django, most developers will have to learn a new language. Python has a book available online: Dive into Python. I found it very easy to switch from C/C++/PHP to python. Django does have a slight learning curve though. Oh, and be aware, the Django documentation online is for their SVN version! Most likely NOT your distro's version. They are still under heavy development.
-metric
You should use plain old C if you want performance.
And you can easily read the HTTP headers with the gets() function - very fast and reliable.
Besides, if the comments on this article are good enough, it will become a great reference for people who ask this question in the future.
... when the complaint is similar to "PHP is a really cruddy language to write a graphics driver in". This is true -- using PHP to write a graphics driver is like attempting to change a car tire with a banana, but thats hardly a knock on PHP, its just a mostly banal comment on choosing the right tool for the job. What Rails excels in is choosing the right job for the tool -- given that you have Rails, you now know with pretty good certainty that you can bang out a CRUD site in your target vertical of choice on a very nice timescale while still being feature-rich. That is a really, really nice feature for a platform to have for small software houses.
Granted, I wouldn't write Digg in it, but *I'll never write Digg in anything*. Neither will 99% of the world's programmers, and for the 1% that are making social networking sitse with desired user numbers the size of nation states, they have the LAMP stack and God bless them for it.
As for me, I've got one quite profitable desktop application written in Java (folks laughed at me for that -- what can I say, it got the job done) and am having a bloody ball working on a small business vertical app which, at $15 / account / month and low predicted need for users to interact with the app, would replace my day job income at about three dynamic page hits per hour. I have this funny feeling that Rails will scale that far.
Help poke pirates in the eyepatch, arr.
Sorry, can't say much more than that. If you've never used Ruby on Rails, I'm sure CakePHP would be a joy to work in. However, if you've used Ruby on Rails, then CakePHP will hurt. The Ruby language is beautifully suited to this kind of framework, and PHP is not.
This is not to knock CakePHP. In its own right, CakePHP is an excellent framework and a lot of quality work has gone into making it what it is. It's a powerful framework.
The move to this kind of framework can be quite a mind job, whether you're moving to Rails or CakePHP. It requires breaking down very solid foundations of ideas that you've built up over the years on how to build a web application. If PHP is your thing, then weathering that mind job will be all the more easier if you're doing it in a language already familiar to you. But if you're willing to try something new, then it's worth making the jump to Ruby on Rails.
I would choose to not start such a website with or for you.
Your constraints on what to think about have you already treading down the path to failure.
You should just hire a bunch of cheap webmonkeys to code up some php, get decent designer to make it look pretty and spend the rest of your time/cash on marketing and hype. Because your preconceptions make it unlikely you will be part of anything innovative and interesting.
Sorry to be so harsh.
PHP5 is assembler compared to the other two. and not even like assembler compared to c - php5 is actually a everyday usable 'assembler'.
go pro. go php5.
Read radical news here
They all suck anyway, django IME sucks the least.
Well I guess it depends what you are building. Ruby on Rails is certainly a fun framework to work with. The trouble is Ruby itself is painfully slow (see http://shootout.alioth.debian.org/ for data on this) and doesn't get Unicode. So if you're site is going to do anything large or international it would be a poor choice. If not then RoR is a lot of fun - go for it.
PHP. People do build large apps in PHP. Having used it quite a bit it remains a mystery to me a)how and b)why. Its ugly and handles state poorly - a disaster for a web language in my view.
Alternatives. Both Java and ASP.NET make sense for large scale applications. Beyond that it depends a lot what you're doing. I would tend to plump for Java since I like being able to pick the right framework for the job I'm doing - so for instance if I'm building a high traffic web app I'd probably go for Struts, if I was building something that needed to be more desktop like I'd probably go for JSF with Seam, and if I was after lots of Ajax bells and whistles I'd probably add GWT into the mix. I also like the richness of the Java toolbox (being able to use JMS to talk to MQ for instance, applets on the client side for certain specific duties), and the Java tools (notably IDEA) are world beating.
PHP5 is a language, the other two are frameworks. So it can't really be compared. The Zend Framework is a very non-limiting non-rigid framework (it's much more like a bunch of really good libraries atm) which might make the comparison viable.
For me it has to be PHP5 and Postgresql.
And of course my editor of choice is VI.
But then I can code blindfolded....
Depends what your coders can use though and unless you were to publish the full and detailed specs of your project so we can understand it's scope this entire exercise is a complete and utter waste of time....
If you're mostly comparing frameworks anyway (CakePHP and RoR are frameworks, PHP5 is a language) just substitute symfony for PHP5, and the answer becomes clear: use symfony... The best of PHP5 with the best practices of RoR - just make sure to use an opcode cache because symfony is not the most light-weight.
Scalable, and loads of fun to program with.
I find it strange that nobody yet has given a reference to Catalyst, the best MVC framework for Perl. From people that have tried both (not me), it is said to be the equivalent of RoR for Perl. I can't back that because I'm a perl monk and I don't have time for yet another language (what for, when you have already tried the best language ? ;-)
Application skeleton and database CRUD in 30 seconds (measured!!!). Try it.
Reality is a mass hallucination due to lack of alcohol in blood. - DeadLiver
Funny thing is, PHP was originally written in Perl as a framework...
Actio personalis moritur cum persona. (Dead men don't sue)
Nothing wrong with asking for the opinions of others
There is when the reason you are asking is so you don't actually have to learn what your teacher wants you to learn.
Look, it's early September. Kids are just going back to school. This is obviously the first assignment for a class project. The submission is clearly just rewording the assignment, right down to the list of things he should include in his answer, no doubt copied straight from the blackboard. You can spot homework questions a mile off.
This guy should be learning how to evaluate platforms on their merits, but instead he's trolling Slashdot for things to copy down. Don't you think he should be able to figure out how to pick a platform without resorting to doing whatever anonymous Internet denizens tell him to? This is the kid who will grow up to be the luser that hassles you with FAQs and demands code to copy & paste so he doesn't get fired, and you are enabling him.
The paradigm of having web pages that you serve, and that are actually files on the server only works for a short time. Mixing any of these inline scripting languages into the HTML document stinks IMO.
As soon as your website is a bit dynamic you are better off generating everything on the fly.
You can describe content with databases and xml and CSS and then have your server generate actual pages from that.
I personally use c++ cgi scripts to generate all pages, as I need to do some computationally expensive crunching as well. Why learn a dodgy scripting language when you know how to do it properly anyway ? As soon as you need to do something different or slightly complex all these scripting languages start to become painfull and you need to start augmenting them anyway.
I realise that I am not a cool web developer, and there are potential security problems with using compiled languages, but this works well for me.
Alex
I'm no big web developer, but I know enough to know that PHP 5 isn't a rapid web development API like Ruby on Rails, but rather a programming language. :-S
Wouldn't comparing RoR to e.g. the Zend Framework make more sense / be more useful?
Beware: In C++, your friends can see your privates!
As many have pointed out allready, PHP (incl. PHP 5) is a subset of CakePHP, as it is - Tadaa! - a PHP Framework. So if you run Cake on PHP 5 (it runs on both PHP 4 and PHP 5) then you've got both.
There are a lot of Frameworks recommended here, such as Django, Turbogears and others. They are all very neat. I'd like to add Zope (or it's superset Plone) to that list as it is the oldest and most mature of all these neat OSS Webkits.
Rails is the first project that emphatically applied marketing tactics to make itself popular, thus the extreme hype surrounding it and the potential critical mass it has gained. It's simular to the hype Zend is putting behind it's Zend Framework right now. Which is also way overhyped with bold claims despite being less than a year old. However Rails is *not* the Framework that invented or first implemented MVC, Scaffolding or all the other concepts associated with it.
A Webdevelopers 2 cents.
Feature, concept and technology wise Zope (built with Python) is still unmatched by any other Framework or Appserver available, be it in Python, Ruby, Java or whatever.
CakePHP is a good Framework - I'm using on PHP 5 it just now to build a larger custom CRM System - and the community is fun (no Forum - we all hang out on IRC) but I recommend Symfony, as it is built entirely on PHP 5 no extra work added for PHP 4 compliance, covers aspects of it job by integrating existing Projects such as Creole and Propel for the DB stuff and it has very good documentation. Including a very well written Book (free PDF version available). Symfony is mature and has been successfully used in very large scale Projects (Yahoo Bookmarks is built on it).
Bottom Line: I'd be carefull not to blindly follow the rabid hypers of Rails or their fresh PHP equivalent, the Zend Framework bandwagon crew. Check out the Frameworks people have mentioned here and if you want to stick to PHP 5 Cake or Symfony are both fine choices.
We suffer more in our imagination than in reality. - Seneca
I've begun leaning towards PostgreSQL recently, but I never trust benchmarks given to me by one of the two sides instead of being done by a neutral party.
GLaDOS for President 2016! "Well here we are again. It's always such a pleasure." -- GLaDOS, 2011
> PHP5 Vs. CakePHP Vs. RubyOnRails?
One of the most visited sites with dynamically generated content, Wikipedia, is written in PHP. So, I'd say that shows it's scalable and heavy-duty.
In terms of the Rails community see: http://www.workingwithrails.com/ There is a large number of developers from all around the world now building Rails Apps. Many for large well know organisations: http://www.workingwithrails.com/high-profile-organ isations
everything looks like a nail.
Ignoring the confusion between PHP5 and the web frameworks named, in your situation I wouldn't go with any of them. If all you want is simply an easily-maintainable website then MODx is a much better choice. It's flexible enough to wrap around most websites without writing a single line of code, most of the work goes into the actual HTML-templates. It's more of a CMS/CMF-combination, with a large amount of plugins and an active community. The tree-based folder/document structures, publication-features, multiple users for different website sections, meta-tag editing... my users love the built-in functionalities and I don't see the point in implementing them all myself (anymore).
Don't get me wrong, I'm a Django-fan and have used it and other web frameworks for quite a few commercial projects (specialized web applications, mostly intranet stuff). Django/RoR/Cake are great for such projects, however for maintainers of websites a fully-featured CMS (like MODx has) knocks the socks off of even the auto-generated backends. If your website falls into the multiple-level/multiple-document structure then it is pointless IMHO to build your own CMS from scratch.
And yes, MODx is buzzword-compliant (AJAX/XHTML/Web2.0/SEO), so it's an easy sell to management.
This sig is intentionally left blank
A key issue, in contrasting PHP with RoR, is deployment.
Deploying PHP is easy in most environments, perhaps as much because of its age as because of its inherent character. I work in an academic environment, in which all professors and students have the ability to make PHP sites. Each of my personal computers also lets me make PHP sites with no difficulty. Deployment amounts to no more than a file copy, perhaps with a change of file permissions. (I won't mention the database work, because of course it is the same for all schemes, PHP, RoR, etc.)
But, unless you're using a host that has been set up to server RoR, deployment may involve changing Apache configuration files, compiling new Apache modules, etc. Such changes require root access (not available to folks sharing machines), and have the potential to break the other sites on the machine.
I think there is a reason why the RoR tutorials, books, and promoters so seldom mention deployment: it is difficult for many people in non-commercial environments that are not set up for RoR.
Oh, and one more thing. All of this fiddling with apache is boring to those who have set out to create websites. Learning Ruby to do RoR is quite fun, actually, and it has the advantage that it lets you use Ruby for other tasks as well. But learning apache doesn't help you with anything but apache; it's a bit of a single-lane road.
RoR has a sort of elegance about it, and you gain a great deal of functionality from the system (e.g. for logins, etc.), and so it is a terrific tool for rapid development, particularly of an evolving idea for a site. It sounds crazy, but the optimal path may be to write the site in RoR and then rewrite it in PHP, so that deployment will be easy and so that the site will scale well[*].
* -- I've not mentioned scaling and speed because these issues are covered in other posts here. Basically, RoR is not impressive on either.
The useful thing about Greg's article is that it's all discussion, not benchmarks, with references from both projects' own documentation as support. It makes checking the conclusions yourself fairly easy.
I've used PHP, Perl, Ruby and Python (in that order) and I can confirm that Python is in fact cleaner. One of the reasons being it's spartan syntax. It's one of the goals of the language. :)
PHP is just ugly, (see grandparent) Perl and Ruby are quite fun and share the same philosophy (see TIMTOWTDI) where Python is just the opposite (although fun too).
Python and Ruby also share their deep roots in clean object orientation, where Perl's OO syntax is - though bolted on - very flexible and even more TIMTOWTDI than Ruby's.
Just to set things straight, I really like Perl, Ruby and Python, though I can confirm that developing web applications with Django is bliss.
Meme of the day: I browse "Disable Sigs: Checked". So should you.
www.workingwithrails.com = 500: Internal Server Error
Hmmmm...
Got to vote for RON here. You missed mod_perl. Yeah, we know, perl is ugly and quirky and old-fashioned. So is a Class 47, but there's no denying it gets the job done.
If you already know PHP, you won't have a lot to learn with Perl and you'll probably think it's a bit cleaner: Perl doesn't insist for you to put round brackets around everything, and its regex syntax is built about the regular expressions first and foremost, with looking like "proper" programming language constructs a distant second. (cf. the horrible, kludgy regex syntax of Java or Python.) Once you get used to how $_ works, you probably won't even need as many variables as you thought.
Je fume. Tu fumes. Nous fûmes!
If you had really complete freedom and were willing to try out something radically different from existing frameworks, I would suggest you would take a look at Ocsigen. It is based on the OCaml language, which alone implies a different mindset from traditional frameworks based on imperative languages. Some of Ocsigen's cool features:
Sorry if this sounds like a sales pitch, but I would just like to point out that there are wonderful technologies out there, if people were just willing to take a step outside the trodden path.
Yahoo finance, google and youtube use mysql. People who know a thing or two about large scale deployment.
Why not use a CMS for these purposes? Scalability, caching, forms, user sessions etc are all already taken care of. All you need is to customize a given CMS for your particular needs. Just start with say, Drupal CMS, and build/modify modules for your own convenience.
Being a programming language enthusiast, I would choose Ruby over PHP any day. There simply isn't any contest.
While I think PHP has the edge in being an easy transition from straight HTML (no MVC or OO baggage required), it suffers from a seriously crappy design (if you can even call it that) and the implementation isn't too great, either. Ruby has its flaws, but the language is one of the most elegant I have ever worked with. I have worked extensively with both, and I can tell you from experience that PHPs shortcoming seriously start to hamper you once your project moves from "static HTML with some generated content" towards "full-blown application which emits HTML in some places".
You can argue about frameworks until you are blue in the face, but, eventually, you will end up writing a lot of code in the language itself, and Ruby is the clear winner there. Having said that, I should add that Rails is a pretty good framework which gets a lot of things right, and the other parts are being worked on. When I worked with Rails full-time, I could almost feel the progress being made, and I trust that Rails is a lot better now than it was then. It improves quickly, because it is built using a good language. Unfortunately, I can't say anything about competing frameworks, as I have never worked with any.
Now, you might find that Ruby programmers are scarce. You can find Java or PHP programmers on every corner of the street, or near enough, but Ruby is a language that is still mostly ignored by the mainstream, including both programmers and those who teach them. This is both a disadvantage and an advantage. It makes it more difficult, and likely more expensive, to find and hire programmers who already know Ruby, but those who do are likely to be good programmers, whereas the same isn't true of many Java and PHP programmers. Also, people who have some experience learning programming languages (i.e. everybody who knows more than one or two) should have no difficulty learning Ruby...thankfully, Ruby isn't one of those languages that is full of gotchas.
Now, to address your points more specifically:
1. Maturity of solution:
Neither Ruby nor PHP are exactly stable, but both have a pretty good track record with regard to backward compatibility. Rails and its imitations are relatively new and unstable, but I would guess that Rails would be the better pick. Note, though, that this is just a guess.
2. Features:
PHP comes with a lot of things baked into the implementation. Ruby comes with a number of modules, and more can easily be installed. I don't know which comes out the winner, but, in my experience, there is usually a Ruby module somewhere that does what you need...and you can easily install it; no recompiling required (unlike PHP, at least back when I still used it for new projects).
3. Size of community of skilled users:
PHP is the clear winner here. However, I am not 100% sure that it's actually easier to find _good_ PHP programmers than _good_ Ruby programmers.
4. Complexity, ease for neophytes to master:
PHP is a more limited language than Ruby, and thus easier to learn completely. Learning the same things that PHP can do in Ruby should be about equally difficult, but if you are going to be working with code that others have written (and you are), you will have to learn more Ruby than that. So PHP wins this one, but I must argue that your programmers will end up writing more code (and thus costing more) in exchange for less time spent on learning.
5. Greatest strengths and weaknesses:
Strength of Ruby: It's actually a great programming language. If you have people who can handle it, this will be a great advantage for you.
Weaknesses of Ruby: Few people know it. It is dog slow. It is dynamically typed, so you will spend a lot of time debugging and getting errors at run-time that could have been caught at compile time.
Strength of PHP: Many people know it. It's pretty easy to learn. It's tailored for web pages and some a
Please correct me if I got my facts wrong.
patio11, this is off topic but I have an idea for an application I was planning to write/sell and it looks like its something that you already have done. Having been through it I was wondering if you would share your insight on how difficult it is to do. What I mean, you wrote an app in Java and are you seeling it on the web? If so then did you design the website that sells it yourself? Did you get legal disclaimer that goes with your app, etc. Your insight is appreciated.
The difference that I can see between those two examples is that the first one declares the types for its variables and parameters, and the second doesn't. So in the Java code (as in C or C++) you'll get compiler errors for many more programming errors. In my experience, this is a huge advantage.
And there's a good follow-up by one of his coworkers:
We've been extremely happy with Rails, and make use of the multitude of helpers that it offers us - like any application on any stack, though, providing fast response times to a (rapidly) growing number of users is a challenge. The solutions are often tightly coupled to the application and its characteristics, and while scaling the most trafficked Rails site in the world, we've run into situations where existing solutions weren't enough.
Rails is best at database baby-sitting, which is not what Twitter is about and it's understandable they would have issues. Ruby is slow and we need a good virtual machine. Nevertheless, Twitter does run on Ruby which shows that it can be made to scale. Not that Twitter is a good measure of anything other than, well, Twitter. And I'm sure someone could have done it with PHP, Python, Erlang or C.
Which is always why blanket statements about languages and platforms is always a bad idea. Just look at the comments on this article. It's just a chance for everyone to trumpet their favorite web framework or language. Sure we have our favorite tools, but most of them suck at one thing or another.
Who said Freedom was Fair?
Whatever you choose in a framework, bear in mind that the first version is not an important one, and anything done to optimize its construction is overwhelmingly likely to bite you at every opportunity to do maintenance. I haven't yet found a framework which saves time in the long run, "the long run" being anything over a month.
What part of "A well regulated militia" do you not understand?
I've developed a large complex project on an earlier version of TurboGears, with CherryPy/SQLObject/Kid, and I love it.
TurboGears is quite modular, and the newer modules are even better: SQLAlchemy instead of SQLObject (database interface), and Genshi instead of Kid (templating system).
-Don
Take a look and feel free: http://www.PieMenu.com
Why bother with any of those techs?
;)
Go with C# & ASP.NET
We have 3 major hosted financial applications written in RoR. Twitter (see below) gets more hits, but we have larger apps that deal with real currency. My report is:
1. Your database will be the scalability bottleneck in Rails. To minimize this, you have a few options.
* First, try running your RoR app from within a J2EE app server using ActiveRecord-JDBC and JRuby (we're using Glassfish). A J2EE app server can scale nicely and seems to reduce the number of database hits by using more intelligent connection pooling, etc. It's not as efficient as using JPA and EJB3 container-managed persistence with a J2EE app, but it works and has the other benefits of giving you better integration (no JVM startup wait) with JasperReports and the security of running your code within the JVM.
* Second, consider using MySql for its "clustering" ability. I'm a PostgreSql user, but my understanding is that Twitter is using the MySql clustering.
* As Twitter has done, use caching and read-only slaves when you hit the bottlenecks.
2. Ruby is slow. Development in RoR is quick, though. It's a time-to-market issue. In our case we made more money by choosing a rapid development framework and delivering to customers quickly. When we run into refactoring issues, we'll have the cash to hire a team of J2EE guys, if we need it. In the future RoR may have all of its performance issues fixed.
3. It is an excellent framework for small-medium webapp development. Building larger, integrated, "enterprise" apps introduces some frustrations, but is doable.
I've had great success using PEAR DB Objects and Smarty templates for my new web app (blatant plug): http://everythingfreight.com./
The abstraction that DB objects have provided has been a goodsend working on ISP with older versions of MySQL.
The caching features of Smarty have helped out a lot, but caution should be used when learning the security implications of the actual cache files.
Sig it.
Use Groovy on Rails, if you want a MySQL based Website with a lot
of database functionality. It's easier than PHP, more stable,
clean, you can use all java libraries out there, it runs where
java runs, etc.
See grails.codehaus.org
Everyone talked a lot about PHP.
I started learning it. By about a chapter into the PHP book, I was thinking "holy crap, this language is uglier than perl". It has everything you would expect from a language thrown together by people who were either ignorant of software engineering or aware of it, but aggressively hostile to it. Everything global by default? WTF?
I have never seen a language with so many carefully crafted security holes that the developer needs to learn to avoid. Default behavior for inclusion is to allow URLs, so you can, you know, run code from any site in the world. There's a feature everyone always wanted, which is never going to be subverted!
I made it through about two and a half PHP books. In that time I learned that the MySQL and PostgreSQL interfaces were substantively different, and of course, used differently-named functions with slightly different calling conventions. Why? Because there's no abstraction or generalization going on; just whatever features sound cool getting thrown in with some name that wasn't previously in use. I learned that this is just BASIC all over again.
I spent several days thinking hard about bleach, and went back to programming languages that were designed with some kind of consideration given to the development of larger projects.
Ruby's undoubtedly "slow". That's what everyone said about perl and awk, too. Come to think of it, I've had people tell me that C was too slow. But Ruby has the amazing, shining, virtue that it is not a stupidly-designed or ugly language. I spent a while working with Ruby, and some helpful people pointed out that, in fact, the language does have a gotcha to watch out for. One. Not so many that you have to buy whole books full of things that you'd obviously try that don't work, open your site up to XSS, or behave erratically. No, just the one.
Can PHP work? Sure. But the tacked-on afterthoughts provided to allow you to, in theory, if you remember to and want to put in the work, use basic software engineering principles, are not enough. The language provides a huge array of runtime functionality, with a function for everything. It doesn't provide the basic tools you want for engineering large projects, meaning that the workload of maintaining big stuff in PHP is exponential, not just quadratic.
It can be made to work, but it really is that badly considered, and I wish people would stop doing things in it. Life is easy enough for the botnet people already, we don't need a language in which you have to be warned not to set the flag that lets remote sites set every global variable in your program.
My blog: http://www.seebs.net/log/ --- My iPhone/iPad app: http://www.seebs.net/seebsfrac/
All the posts I've seen so far complain about RoR's scalability. These people have obviously not worked with RoR because, while scalability might be an issue, if they'd really worked with RoR, they would know that DEPLOYMENT is what kills rails.
I jumped on the RoR bandwagon full bore and have been developing my app for over 1 year. The Ruby language is awesome and the framework takes the messiness out of web development. When I look at PHP code now I was to puke. With that said, I can deploy a PHP application is seconds...literally. Rails on the other hand, has had me working almost full time for 3 weeks trying to get a fucking test (not production...test) server up and running. It is completely fucking ridiculous to get a server set up that you could seriously test with or, God forbid, move into production.
I've been a Systems Admin for over 7 years and a programmer for 6 years and using Linux for at least 8 years so I'm no newbie or idiot. I've tried setting up everything manually as well as using Capistrano and Capistrano/Deprec and still haven't had success getting a server setup.
It is unbelievable how many crazy little nuances and bizarre configuration parameters you will encounter. In a short period of time you are just copying and pasting any random crap someone posted on the net that claims to have a working server. I've followed countless tutorials TO THE LETTER and this shit still doesn't work.
I even purchased the "Deploying Rails Applications" book from Pragmatic Programmers and STILL CAN'T FUCKING GET SOMETHING DEPLOYED!!! Possibly the worst written book ever and claims to give you everything you need to get the Rails stack set up on Ubuntu Dapper Drake and has almost zero setup commands. What a load of crap. Anyone could have written this book since he just lifted it all from internet posts. Good job asshole, thanks for nothing.
You know what happens to people who can successfully set up a Rails application? They start a fucking hosting company and make a shitload of money because hardly anyone else can do it. EngineYard, SliceHost, and RailsMachine are all examples of Rails programmers who started hosting companies because they actually made something work. It really just shouldn't be that hard.
Maybe someday Rails will be easy to deploy, but right now it is a fucking nightmare. It totally ruins all of the great things about Ruby and Rails. I'm starting to think it's all a conspiracy and Rails was just some kind of carrot to lure us all into purchasing expensive hosting.
The hype about Rails' faster development time is true right up until implementation and then it's a load of shit. Implementing a PHP app is like 2nd grade math, whereas implementing a Rails app is like quantum physics.
I've never been so fucking frustrated about anything computer related in all my life. If you don't have a high tolerance for wading through tons of bullshit, then I don't recommend trying to implement a Rails app at this time.
I'd use none of the above and opt for Grails http://grails.org/ which gives me the java app servers (jboss, glassfish, tomcat, etc), the huge Java class libraryand the Groovy dynamic language. Seriously, if you are looking at these technologies do yourself a favor and be sure to check out Grails.
> Yahoo finance, google and youtube use mysql. People who know a thing or two about large scale deployment.
Sure, so does my department at ibm. Of course, we prefer postgresql, db2, oracle and sql server. But...if a vendor product requires mysql we will reluctantly install this - the least ansi-compliant database management system on the market.
So, go ahead and add ibm as well as a mysql user.
(1) Schemas, entity-relationship diagrams, and queries tell me how an application works -- with Active Record this information is strewn across a whole bunch of files (especially in Rails);
Um...somehow, I seriously doubt your claim to have actually used RoR for anything substantial. If you had, you'd know that, while migrations allow you to define your schema it separate files (usefully so), these files are used to generate the file db/schema.rb, which contain the entire database definition in ruby syntax. If you wish to have the DDL, again, it's very very easy. Simple issue "rake db:structure:dump" from your project root. How difficult is that?
(2) Database-independence is a nice idea, but in reality, how often over the lifetime of your website will you migrate to a different database? Usually your database is chosen for you. Usually a switching databases involves coordinating with a lot of people who you'd usually rather not have to deal with -- those issues will take far more time and energy than differences between MySQL and Oracle;
Again, bullshit. I've heard this argument again and again, but we have many customers, each of which have their own preferred database. We typically develop and use PostgreSQL ourselves, but being able to offer MySQL, Oracle or MSSQL support to our customers, so that they can leverage existing resources, is invaluable. If you live in your own closed-wall little world, then perhaps you'll only ever use one database. Or, if you're developing a web app which will remain under your complete control. BUT, if you have paying customers and distribute your app to them, database independence becomes extremely important.
(3) a pretty common design pattern for web pages is to have a form that let's you fill in a few parameters (date, maybe geographical information) into a huge multi-table select statement -- you can do that in Active Record, but basically all you gain is a marginally fancier wrapper than you would have with DBI.
huge multi-table select statement versus sending objects messages? I know which I'd choose.
This entire discussion is pretty entertaining. As a developer of PHP since the later versions of 2, I can safely say from experience that it just is an AWFUL, hacked together language. Anything you develop ends up being hacked together as well (hacks are contagious). It works, sure, but as with all dirty hacks, you suffer pretty quickly. The hacks spread, the ugliness grows, and pretty soon you feel guilty even opening up the source and looking at the crap you've been encouraged to write.
Ruby on Rails has warts here and there, sure, but it does encourage you to write clean code. And, Ruby, more than Rails, gives you such immense flexibility that you find yourself having to unlearn bad habits you were forced to follow by PHP.
Trust me, PHP's days are numbered. Sure, it'll hang around like a bad rash for some years (even COBOL is still widely used), but only because the cost of migrating far outweighs the value in the legacy. Folks using PHP for greenfield applications today, when options like RoR, Grails, or even Django exist, should really check if their heads are on straight.
...hear my answer. ;-)
http://www.youtube.com/watch?v=JMDcOViViNY
Single-threaded (Ruby) = hard to scale unless you are building one massive app.
Have seen single-threaded rails apps in the same environment not scale well. I guess if you have Microsoft's/Google's datacenter budgets to throw hardware at the problem this is slightly less of an issue, but I wouldn't recommend going there if you intend to deploy many ruby apps to the same environment.
I'm sure this is just adding fuel to the fire, nevertheless, I am legitimately curious and while TFA is a lame link to a Wikipedia entry, it seems to be bringing out people knowledgeable in this area.
Zope looks to have similar features/capabilities, anyone using it in real life?
Does it scale well?
Any particular annoying quirks?
There appears to be an additional "grok" wrapper, does it really help?
There is no right to feel safe thru security vaudeville at the expense of everyone's freedom, privacy and tax money.
I don't know if I'll see one before I die but I'd love a script language that:
Has strict type define like lets say a byte (all scripts)
has all forms of types like unsigned (php) no I don't want a float for a large number.
has a switch statement (python)
does not have nulls or is something other then a extension to regex
and embeds into server applications without the use of a push pop stack
http://www.catalystframework.org
Not ever envisioning writing the next social app mega hit I find comparisons to Twitter a bit amusing. I just finished my first Rails site, an intranet calendar that may see a couple of thousand visits a day if the entire company uses the thing to its full potential, which isn't likely. Even taking into account the time learning RoR it took me about as long as it would have had I done it in PHP. That's amazing. I bid the job on my old time scale and got paid for on the job training. From now on out I should be able to do more work in less time. That's the scalability I'm interested in, the kind that makes me more productive and brings home more income.
Like many self taught web designer/developers I started with CGI/Perl then moved to PHP, now Rails. Each move has been in the direction of increased productivity. I'm a just good enough programmer and am blown away by the MVC framework, DRY and Active Record. Real programmers may say, "Yeah, no big deal," but for the humble masses that just want the ability to deliver a custom site that will never see high traffic volume, the processing effeciency of a framework just isn't an issue. If you want to create the next coming of Face Book hire real programmers. If you want your website to do what you want and not force-fit your expectations to the constraints of an out of the box CRM or CMS, all at a reasonable price, then RoR looks really fine.
I know about db/schema.rb. But your entity relationships are strewn in the model definitions. Yes, you could use "rake db:structure:dump" (or "rake db:annotate" that I swiped from one book on Rails), but you still have to remember to do that. This is essentially a minor problem, but every neophyte rails programmer I've encountered gets confused by this, especially when they are coming into an existing project.
As for database-independence, it really depends on the applications you write and the customer. For nearly all of my clients I've been writing one-off applications that have to talk to pre-existing databases -- in that case the database wrapping in Active Record can't buy me very much. As for your comment about a huge multi-table select versus sending an object messages, yes, it is much much simpler to implement that with Active Record's object syntax, but it is guaranteed to be quite a bit slower than a hand-constructed select statement. And that is one case where performance would quite often matter.
If there was clean support for views in Active Record (none of the plugins I've seen make me very happy) I'd be a happier coder.
I like ruby and I like rails and agree that it is very hard not to write ugly code in PHP.
First off, let me disclaim this with yes, I know ROR is a framework and PHP is a language. Yes its not quite the same comparing PHP to ROR. They are still both tools used to achieve the same result on the web. I haven't used CakePHP so this is only PHP vs ROR. Trols begone :)
I know there are a lot of PHP haters on the ROR side, and a lot of ROR haters on the PHP side. I've used PHP for nearly 8 years now and I love it. About a year ago I got a job offer at a startup and they wanted me to do rails instead of PHP. So, I've been pushing rails to its limits for the last year trying to get things done with the same strength and speed of my former PHP apps. Both are good and bad in their own ways. Here is yet another random coder's 2 cents:
PHP:
Pros:
GREAT community.
Easy to read and accurate documentation
Fairly easy language to pick up
Fast! The performance of PHP is the best of the web languages I've used.
Awesome for creating small scripts in a hurry (ie, displaying an MOTD on your site or something of the like)
CLI php works just as web php does
Easy to get working with most major webservers
Cons:
A royal pain in the ass to maintain if your program starts getting large.
Very easy to make insecure (reg. globals anyone?)
No built in testing
No built in MVC (this is easy to fix this, but still, i *hated* using smarty or the like for my templates)
Lots of crappy applications give it a bad name :) (phpnuke comes to mind)
No namespaces!
Hard to scale
Ruby on Rails:
Pros:
Tons of stuff built right in like ActiveRecord, MVC, etc.
ActiveRecord is awesome for simple queries
Its ruby guts makes for some pretty easy to read code (saying "puts 'hello world' unless social" is much easier to read than "if (!$social) { print 'hello world'; }
Built in testing framework is a awesome and is an incentive for people to test more (I NEVER tested in PHP, i do all the time in rails)
You can create impressive sites fairly quickly
Namespaces, glorious namespaces!
Easy to scale. Add more mongrel clusters and you're done.
Cons:
Tons of stuff built right in (it is bloated all to hell)
ActiveRecord is SLOW SLOW SLOW for complex queries (Pear DB DataObject kicks its ass)
The community is very young and immature -- its a mash up of a few guy's blogs, a few wikis, and $9.99 podcasts
The API documentation is lacking, and in a lot of cases, completely wrong. You have to read the source code to figure out what the API should be.
Extremely verbose if you want a quick and simple piece of code on your static site (as in the aforementioned MOTD example)
No easy integration with major webservers. You have to proxy and mod rewrite all over the place to get it to live in harmony with static files or other code (like PHP)
Those are the major points that I can think of at this time. There are tons of other, smaller things that I encounter on a day to day basis. In the end, I think both are strong in their own ways. I feel its important to not marry either one and look at them as TOOLS that are to be used in the proper situations. If there is one thing I can't stand, its a purist. Purists box themselves in and turn in to stubborn old foagies that no one wants to deal with. Be open to using any tool that gets the job done in the most professional way possible.
Comment removed based on user account deletion
Lots of posters have been talking about "scaling." I've done a lot of work in Java, PHP, and RoR, including scaling each of them up to millions of hits per day.
The thing is, scaling hardware isn't trivial, and requires very different expertise than building web applications. That's just the nature of it. Rails can scale great; so can PHP, Java, or whatever. Find an expert and they can make it work.
What is much more difficult is to make the code itself scalable. Without a fairly rigid adherence to good design principles, projects that grow larger and larger soon become an unmanageable spaghetti nightmare.
This code scaling is where Rails shines like the sun. It religiously follows good design principles, to the point that you have to try to end up with a mess. For those who have worked in large projects, having that kind of structure is a great joy.
I have never once, nor has anyone I have spoken with, seen a large PHP project that did not turn into spaghetti. The language itself presents huge problems that way: all functions are in the global namespace, as are all variables by default. On the other hand, PHP is very fast, efficient, and effective for little one-page sites.
In short, if your application is going to be very small, and will never, ever grow, use PHP. Otherwise use something else. Rails isn't the only good framework in a good language out there: Django would be a good candidate; even Perl can work for you. Using a decent framework with a language that is well designed will save you all sorts of headache as your project grows.
Like, say, the paragraph break?
If it's becoming a royal pain in the ass to maintain large applications in PHP, I hate to say this, but chances are there are other problems going on that really have nothing to do with PHP (or whatever language you are choosing to use).
Very true, but make sure you take the time to learn the tool in order to implement and use it properly.
I'm making the assumption that you're talking about creating a database-driven website that's going to need a lot of the CRUD functionality that web dev frameworks facilitate; if this isn't true, the answer is probably "none of the above".
Given that: hand-coding PHP to do this kind of site is almost certainly going to be a painful mistake. You're either going to end up reimplementing your own web development framework, or repeating yourself a huge amount and generating error-ridden and unmaintainable code. Especially if you're going to go with a PHP-based solution, you want to use some kind of framework to minimize the amount of code you have to write. (PHP is, after all, training wheels without the bike :) ).
I'm leery of CakePHP; it's written in PHP 4, which pretty much guarantees bad coding practices. (Oh, you wanted /objects/? Ha!) I've had very positive results with symfony, as several others have mentioned. One thing in particular that it has that's been super-handy is, in addition to scaffolding à la Ruby on Rails, the ability to generate highly customizable "admin" interfaces on the fly, based on a configuration file. This makes interface creation more declarative than programmatic, which IME does wonders for maintainability.
You are going to build "something". Should you use:
1. Wood
2. Steel
3. Plastic
* If you tried to answer this question without a use case, you're WRONG!
"Seven years of college down the drain. Might as well join the f-ing Peace Corps." - John 'Bluto' Blutarsky
I prefer to work with PostgreSQL for the data and Django for the website.
Database-independence is a nice idea, but in reality, how often over the lifetime of your website will you migrate to a different database? Usually your database is chosen for you. Usually a switching databases involves coordinating with a lot of people who you'd usually rather not have to deal with
Agreed. The development community is often obsessed with DB vendor neutrality and pay an up-front complexity tax to (try to) achieve it. Most of the time for custom apps it is just not worth it. Authors that over-emphasize this should be slapped. (And if you know its coming, there are ways to write SQL and schemas to reduce vendor issues.)
Table-ized A.I.
This article attempts to compare a language with 2 frameworks. Apples and oranges.
.NET were designed as a language + ubiquitous framework from the start.
PHP lacks a concise easy to use framework that's ubiquitous.
Rubyis a language and has an ubiquitous framework with plugable extensions called Ruby on Rails.
I don't know about the third option, but glancing says it's an attempt at a framework.
The best PHP framework i've seen so far is Symphony, which is a near-clone of Ruby on Rails (odd that the best PHP framework is swiped primarilly from RoR. Gotta be a reason there somewhere).
Java is a language which has a sort-of framework on top of it with many non-plugable libraries.
ASP and
So, to all you php lovers/RoR lovers/Java lovers, how about we compare apples to apples instead of stoking the "mine is better than your's" wars?
As someone who regularly designs applications in both .NET and PHP, I've learned that the language (Ruby, PHP5) and the platform/framework (Rails, CakePHP, .NET) should usually be chosen based on the needs of a particular project. For instance, I would never use PHP or RoR to design a large enterprise level system; I've found .NET and MSSQL to work far more reliably. On the other hand, PHP5 has come a LONG way for small to medium level projects, and I would use it in a heartbeat on one of those.
When you talk about the different choices for each platform, ALWAYS ask what would suit the needs of the project.
From a subjective standpoint, I really cannot stand CakePHP. It's bloated and has a pretty bad Active record implementation. What usually works best, in ANY platform, is to either invest some time in designing a framework yourself, or use an extremely light-weight framework to get off the ground.
My question would be concerning the sensitivity of the data that is to be presented. Are we talking about sensitive customer information (i.e. ssn's) or a private area (i.e. members only section) or is security not a concern at all (i.e. personal blog)?
PHP has some serious security flaws http://www.php-security.org/ That would make it inappropriate to use for the first case, but fine for anything else. It appears that Ruby security flaws are not as well documented, probably since it's a newer language. However, I also doubt that it would be appropriate for the first case. Simply based on the fact I don't see any financial sites running on either platform.
~ Normality is merely the achievement of the mediocre...
I've heard this argument again and again, but we have many customers, each of which have their own preferred database. We typically develop and use PostgreSQL ourselves, but being able to offer MySQL, Oracle or MSSQL support to our customers, so that they can leverage existing resources, is invaluable. If you live in your own closed-wall little world, then perhaps you'll only ever use one database. Or, if you're developing a web app which will remain under your complete control. BUT, if you have paying customers and distribute your app to them, database independence becomes extremely important.
I generally see custom applications written for a particular shop for a particular need. If you sell the same package to different customers with different DB's, then indeed a heavy DB wrapper may pay off.
In my opinion, the most useful such tools are often those that simplify the repetitious portions of SQL (such as INSERT statements), but don't necessarily try to hide all SQL. Writing certain kinds of SQL thru API's can be a royal PITA. The OOP community has falsely convinced many developers that all SQL is evil. They are just being paradigm biggots. (Note that I don't think SQL is the ideal query language, it could be improved, but hiding it all thru bloated API calls and writing manual loops is often worse.)
Table-ized A.I.
The grandparent post is nearly as clueless as the "script kiddies" he attempts to call out.
Firstly: I admire ruby as a language. I like to explore new languages, new ways of doing things, etc. At one time I thought Lisp was really cool too. And many others.
PHP for all its faults is:
Very well documented. This is huge, whether you are a beginner or an expert. Yes, there are ugly inconsistent naming conventions, seemingly unneeded duplication (all the DB interfaces. But check out PDO..), etc.
Easy to set up and deploy (never mind being so ubiquitous as to rarely need to be setup)
Relatively fast.
"Simple things should be simple. Complex things should be possible". PHP is. Some people would argue that being simple to use for newbees or for quick-and-dirty apps is bad. The only reason this is bad is because people misuse it. This is a problem with people, not the language. I don't need my language to restrict me. Many of the security issues and bad code with PHP are due to people simply not knowing what they are doing with a powerful tool.
Procedural and object oriented. You purists out there pushing for 100% object orientation are missing the fact that sometimes its not the right solution. There is a time and place for each.
I am not thrilled with the attempt to contort relational databases into an object oriented methodology (ORM/active record). I love the idea of code generation to save on the drudgery of lower level coding but I don't think this is the way to go. Which leads me away from the RAILs bandwagon.
Personally I am leaning towards Kohana framework (fork of Codeigniter): no ORM (not built in, anyway) but code for helping you construct SQL, Templates are just PHP (remember that PHP was just a template language originally?), use whatever AJAX bits you like (I do like prototype.js from rails, scriptaculous and ext framework). I plan to write my own code generator to handle the 80% of the boring HTML forms and DB table code, while it stays out of my way for the other 20% I know will need to be coded by hand.
-- Senior Software Engineer, Attorney appearance services, locallawyerapp.com.
No, real men code their sites in erlang. http://erlyweb.org/ And don't rate this post as funny :P
I like Python better than PHP, but I think there may be compelling
.htaccess file.
advantages to PHP when it comes to frameworks. Issues that concerns me
with Python, and Python frameworks, include: hosting, deployment,
configuration and administrative overhead.
I get the impression that Python framework developers just assume the
user has complete control over the server. Those who develop Python
frameworks seem to have little regard for the realities of shared
hosting. System requirements tend to be sky-high: Apache 2.x,
mod_python (latest version), fastcgi (at least), command line access,
PostgreSQL (recommended). Assuming you can meet the system
requirements, you still have server configuration issues such as
setting up the Path, and maybe the
For example, as I understand it, in Django:
* The database model has to be manually synced to database from the
command line, anytime any change is made to the database.
* A configuration file has to be created for every application.
* Urls have to be configured in the urls.py file to match the view.
* The webserver has to be restarted every time modify your code - or
touch every file if using fastcgi.
configuration. I don't think this amount of configuration is required
by Rails, or the PHP frameworks. Am I wrong about that? And is it
really an issue?
From a language standpoint, Ruby -- and Python -- are simply much nicer to deal with than PHP usually is. As you probably know, PHP started life as a series of Perl scripts, and even though it left that behind long ago it still reminds me a lot of Perl in its quirkiness and overall feeling of being held together with Scotch tape and spit.
I'm using CakePHP for a work project now and it highlights a lot of these problems. It tries to be object-oriented; for instance, it closely mimics Ruby on Rails' MVC system. Except, you know, when it doesn't: for instance, it returns data results as arrays, rather than objects, so you'll end up writing code like this:
Rather than Ruby's roughly equivalent:
Having said that, though, I put the qualifier "usually" in there for a reason. If you were actually taking advantage of PHP 5, that PHP code could, and arguably should, be simply:
PHP 5.1's new PDO data abstraction layer is pretty easy to work with, lets you work directly with objects, lets you iterate through returned record objects correctly with foreach loops. While there's a lot of data abstraction choices for PHP, PDO is pretty competitive in performance with any of them, very straightforward and, in recent versions of PHP, just baked right in.
PHP 5's object system in general is actually much better than I'd been giving it credit for until I finally dug into it, too. It's definitely worth taking a bit of time -- if you're used to any other OO system, it won't take long -- to learn things about it.
I wrote on my blog not too long ago that PHP shares a largely self-inflicted image problem with Javascript: they can both be fairly powerful, well-executed languages, but they're burdened with a whole lot of crap. Part of that crap is just cruft that's been thrown onto the language (particularly in PHP's case), and part of it is that most people who program in both PHP and Javascript really aren't programmers, and boy, does it show.
I suspect for my next big project, I'm going to write in PHP 5 "natively"; as impressed as I am with what CakePHP is trying to do, their implementation is grating, and I don't think any framework that insists on backward compatibility with PHP 4 is going to be able to move past that. While it may seem a little perverse in this framework-happy age to start from scratch, really, you don't have to start from scratch: PHP's PEAR library contains a fair amount of good components (a fair amount of less good ones, to be sure, too).
As for performance, I think scalability issues with both PHP and RoR get overstated by critics. Ruby's biggest issue at this point performance-wise is simply that it's a very slow language. Rails does a lot of caching tricks to minimize this, but any other language can do the same caching tricks. PHP doesn't have that problem. Neither does Python; I saw someone tagged this article rather facetiously with "django," but you know, Django's a pretty good framework, and I'd give it a serious look for any project were I you. (I'm still giving it a look myself.)
The other issue you face with Rails and Django is deployment. PHP tends to pretty much just work when you slap it up on most web servers; Rails and Django, well, don't. You need a host who knows what they're doing with those frameworks or you need to be hosting it yourself, and learn what you're doing. Rails' deployment syst
I would pick Django. Scales better than most interpreted languages, and offers the chance to write more maintainable code than PHP.
I am a sys admin by trade, and I build web sites for fun, so this may be obvious to someone (read "not me") who does web development for a living, but how does Perl+HTML::Mason compare with PHP, RoR, Django, etc. in terms of speed, scalability and maintainability for commercial/very popular sites? Just curious, since Mason is what I've used on my projects...
MCSE? No, sir...I don't do Windows. Yes, I am an idealist. What's your point?
1. Maturity of solution;
Catalyst and Perl both more mature than the frameworks/languages mentioned.
2. Features;
CPAN is bigger, Perl has more functionality which is why there is more than one way to do it (TIMTOWTDI) in Perl.
3. Size of community of skilled users (to build a team);
More skilled Perl programmers.
4. Complexity/ease of use (for neophytes to master);
Mmmm well can't say. PHP based thing with only one layout you can use might be simplest for a newbie. On the other hand, are you trying to make a serious webapp or just a cookie cutter steaming phpnuke thing? Am interested in Ruby mainly because it just might reduce typing but then again maybe not. Just seems neat. But for making a live system I'd go with Perl.
5. Greatest strength of your choice, and the greatest weaknesses of the other two.
Many available modules. Other two have a much shorter [programmer pool size] x [framework and modules powerfulness] vector.
Granted, I wouldn't write Digg in it, but *I'll never write Digg in anything*. Neither will 99% of the world's programmers
Another way to put this:
I'm a startup. RoR lets me get a 99% solution in practically no time at all. I can get everything except possibly high-volume scaling (and it's not even clear to me that it can't do that). With that 99% solution, I can show it to people and get users. I can show it to investors and get money. With that money, I can spend my time optimizing (hi, Don!) or even rewriting in Java or C or assembly or whatever.
If I had started out in Java or C or assembly or whatever, I'd never have made it past step 1. It would scale awesomely, but never have shipped because I'd have run out of money first. (I've written large programs in Ruby, Java, and C. They all have their uses, but very few startups are using Java, and for good reason.)
This is just another case of "correctness, then performance". I don't think I've ever seen that fail, and I've seen countless instances of the opposite way failing.
No offense, I'm asking because I don't know. I have seen a report where django, rails, and symfony were compared, and symfony came in dead last - by a substantial margin.
I don't have a lot of faith in benchmarks. I like to think I have an open mind.
This mentality is one of the larger reasons why the IT industry is in the shit right now i.e. people don't consider which is the right tool FOR THE PROBLEM. All that largely goes on is people trying to bang square pegs in circle holes getting the expected results.
/will/ show up once things get going. You just have to be picky when it comes to who you give cvs write access to and, for that matter, what contributions you commit yourself (i.e. quality control).
/no-one/ wants in there code-base. If they aren't competent enough to write in a given language, then they shouldn't be contributing. And arguably, for these people, the language wouldn't matter when it comes to the quality of the code they produce.
1. Maturity of solution;
I couldn't care less. As long as it works as advertised and is bug free (as much as it can be).
2. Features;
As long as it has everything that I need, who cares what else is included. Hell, even if it doesn't, one can write it themselves. As long as the list (and complexity of the items) isn't prohibitive... At any rate, I don't expect many languages would be prohibitive in this respect.
3. Size of community of skilled users (to build a team);
If you build it, they will come... sorta. Basically, if what you're building is worth while, and you've shown that you're in it for the long haul, don't worry about building a team of competent programmers. They
4. Complexity/ease of use (for neophytes to master);
Screw neophytes. All they produce is crap code which
5. Greatest strength of your choice, and the greatest weaknesses of the other two.
The problem domain has yet to be specified. So, this is an unanswerable question.
I have used Symfony for several smallish intranet projects that are used for data entry forms and data export. It is flexible and customizable enough to be almost confusing, but you can gradually learn how to use all the little bits to your advantage.
It has far more features than Zend Framework (which you can use with Symfony if you wish) and is more hackable than CakePHP.
I started using Symfony after first using html_quickforms/smarty (pear modules) and then looking at Rails and CakePHP. Rails was a new language with a new framework so I decided against it at the time, and Cake seemed really rigid. Now that I am comfortable with a sophisticated framework like Symfony, I will check out Rails to see what the hoopla is all about.
For now though, I see little need to.
So in Summary, no matter what you choose folks will complain about "how crappy it is" and how much better their solution is.
My advice.
1. get the requirements for the app you need to build
2. choose a solution that handles all of point 1 (x 2)
3. use an agile developmental methodology.
4. make sure the code you write is maintainable and extendable. (i.e. joe college grad can modify it)
5. have unit tests and code reviews.
Probably only one developer. I like structured, readable, maintainable code.
I am leaning towards python and a python framework, but I am not happy about the deployment and configuration issues associated with python.
Is there that big a difference between php and python? Is python worth the trouble?
As you may have guessed, I know some python, and some php, but I no expert in either.
I've worked in all three, repeatedly, and there's really no contest. Rails is so much easier to get concepts out, and has so many fewer bugs (in my experience), that it's silly to use PHP at this point, unless you have overriding reasons for choosing it aside from inherent qualities.
Do these have to be mutually-exclusive? Could a Rails framework be built for PHP? I've heard debates that Rails really needs the "meta" abilities of Ruby, but others have disagreed. Seems nobody will know for sure until its tried.
Table-ized A.I.
PHP: The quickest way to learn bad programming habits, bar none. Even worse than Visual Basic. You will hurt yourself and never understand why.
Comment removed based on user account deletion
Comment removed based on user account deletion
It is a class libaray similar to cpan. I can't belive you got modded up noob. Your the shit eating skript K1D
What about django ? It is bettart ! This allows python fan mods to give me mod points, do fast.
Copyright infringement is "piracy" in the same way DRM is "consumer rape"
Comment removed based on user account deletion
Use Deprec (www.deprec.org I think) on a clean Ubuntu install. Seriously, when I found it it was almost a religious experience (and we're talking Baptist-esque rolling in the aisles and PRAISE HIM! OH! religion here).
Help poke pirates in the eyepatch, arr.
using PHP to write a graphics driver is like attempting to change a car tire with a banana
Everyone knows that bananas are for attacking self defense instructors
http://en.wikipedia.org/wiki/Self_Defence_Against_Fresh_Fruit
I would advocate all three, together with our own Google Summer of Codey-licous SilverStripe platform :)
My main point is that there are far more variables that need exploring, and then you can find the right too.
For instance, one decision would be: Is it a small team of people working on this project, who want to rapidly work together in a closed application (e.g. building a software as a service application)? If so, then Ruby on Rails could work better, but on the other hand, if your website/project is going to be open source, or needs a community of people to look at it, then PHP might be better.
I think sites like opensourcecms.com could do better at seperating the tools out with questions like that!
And yet, PHP and ROR are like scattered lego blocks on the floor, waiting to be patiently assembled. If someone asks me "to build a website", I would use a system that is much closer to a working website, and tweak it.
The comments in this read about "building a digg" etc, are in my opinion, not what people generally think of "when building a website". Digg is a custom-built application that cannot leverage from existing systems as well as a website can. It probably could have just as well been done in perl or ROR. There would be different challenges, and a different number of servers and staff, but fundamentally it would have been successful enough to pay people to figure out how to overcome those challenges.
I was thinking about the non-parameterized database queries that were ripe for SQL injection attacks that persisted up until recent versions. Just that the developers would let something so huge like that slide for so long made me extremely wary of using PHP, because that's an indication to me that they didn't know what they were doing, or just didn't care.
I'm sure it's better now, but the bad first impression I got has persisted, and PHP isn't so great that I'm willing to take the risk with it.
If moderation could change anything, it would be illegal.
If you use PHP4 you can use CakePHP or CodeIgniter If you use PHP5 you can use Symfony, CakePHP, CodeIgniter or the Zend Framework. CodeIgniter has good documentation and its 100% complete unlike CakePHP. http://codeigniter.com/ Of course PHP has many more frameworks than the ones I mentioned, there are probably well over 15, but those are the ones with the biggest amount of users. From what I've read the Zend Framework is more like a big library and lets you pick and choose what you want with no set structure. I've seen tutorials where others can use the Zend Framework with CakePHP, Symfony and CodeIgniter. The pros to sticking with PHP or a PHP framework is that you probably already know the language. Need security tips for PHP? Visit Chris Shiftlett's blog (he does a good job covering several issues, plus there are books on Apache Security and PHP Security, get them and read them). http://shiflett.org/ I dont see PHP dying anytime soon, there are way too many open source apps written in it, plus tons of new stuff is coming out, like SimplePie, and other good stuff. PHP Developer's web site has some good news on it. http://www.phpdeveloper.org/ Django and Rails have a downside to you having to learn a language and a framework and most often at the same time which makes things confusing for awhile. Django isn't 1.0 yet so while its stable, its still undergoing changes and nothing is exactly set in stone until the 1.0 milestone. Unfortunately there arent any Python books for just Web Development, so that makes it more of a challenge. Rails has a definate lead over Django, since there are well over 100 books on Rails and only like 2 planned for Django. Of course Rails was got more hype earlier on and came out before Django, plus the screencasts helped promote it, a lot. Pick whichever language or framework you want, there are pros and cons to them all.
There is nothing about Python web frameworks that is inherently difficult to deploy or configure. If anything they seem to be similar or even easier than Rails or Java web frameworks.
But if you are coming from a PHP perspective it can seem harder. But that is really more to do with the ubiquity and popularity of PHP has artificially made it seem easier than the others. The web hosting world puts a lot more effort into supporting PHP than anything else - in fact it almost ignores everything else. If you want shared hosting for Ruby, Python, Java,
The lowest common denominator deployment/configuration requirements are easier with PHP, but once you start getting into more complex configurations the gap between PHP and more professional platforms gets a lot smaller.
This is true of every successful application. Once any useful application reaches enough deployment, it
becomes a target for malicious crackers. Furthermore, the more any application can do the more opportunity for
security holes. Since languages are nothing more than complex applications, anything built on languages
will have vulnerability opportunities. Yet further, the more important the information which is handled by an
application the more determined the assault. Finally, I see no lack of exploits being found for Java
either, with several exploits reported over the summer.
That's all I have time for on this "article" without meat, and a jockeying of "my web software is better than yours",
peppered with a few intelligent responses. Oh, wait, I forgot
I am putting together a framework at http://methodsupport.com/program/About.html for generating process/method(ology) support websites.
The emphasis is on document (paper form equivalent) based processes automated quickly and easily.
At this stage it is pre-alpha, but I hope to get a minimum feature set in place soon and upgrade it to alpha.
The source is available from the Sourceforge page.
At this stage, I need any comments or advice that anybody can give me.
Regards, Martin IT: http://methodsupport.com Personal: http://thereisnoend.org
PDO has existed for quite a while now (bundled as of 5.1, available from PECL since 5.0). I would guess that the lack of support for prepared queries was because of the focus on MySQL, which didn't support much of anything beyond "SELECT *" until relatively recently. The newer versions of PHP (5.1.x and above) really are a vast improvement over earlier versions (I started during 4.0.x, so I remember the bad old days).
Here you go. http://tweakers.net/reviews/649/7
For some real entertainment, check out the semantics of the === operator.
Then don't use it. The only need to use it i've seen is a few cases where functions use zero-based character indexing when they should have used one. I get around it by appending a space to the beginning of the target text, emulating 1-based indexing. If you use a tool long enough, you learn to get around it's gotcha's. I've seen no evidence that PHP has significantly more gotcha's than other languages. EVERY language has a Corner Pile of Stupity where it appears the author was buzzed out on 60's substances for the day. You learn them and the work-around, and move on.
Will the first language without sin cast the first stone.
Table-ized A.I.
OK, I've looked up ActiveRecord now. What I am doing is similar but a bit more sophisticated, in that it can put together parent and child records into a single object. Also that it can generate the whole site this way, although you may want to add in some of your own code if you want/need.
Regards, Martin IT: http://methodsupport.com Personal: http://thereisnoend.org
Did you notice the explanation of how they create the "TIOBE Index"? They run some Google searches and count the results. That's it. I wouldn't take it too seriously. And this person is asking about Ruby, which is miles below Perl on this index. In terms of actual jobs, this chart seems to show that Perl is doing quite a bit better than these other dynamic languages.
I suspect Perl's strength in the job market has to do with what you mention as a weakness: it's association with things beyond just web development.