6/11/2005

57 Comments

1. Hey David,

   What was the bug you hit during the tutorials? I’d appreciate it if you could report it at http://dev.rubyonrails.org, as we approach v1.0 we’d like to get everything squared away.

   Comment by Michael Koziarski — 6/11/2005 @ 4:52 pm

2. Hi,

   Maybe CherryPy would be attractive to you then as an alternative?

   Comment by Sylvain — 6/13/2005 @ 6:25 am

3. To paraphrase the great American president Abraham Lincoln, “Rails rulez, PHP drewelz.”

   You are definitely not the first person to feel his velocity plummet after getting past the scaffolding, which is basically a joke feature in rails. There’s something wrong with the learning curve that rails people need to figure out. Of course, it’s totally possible that the framework is just not for you, but to me, Rails’ architecture actually makes me more likely to think in terms of “how should this view really work, ignoring how I’ll have to implement it.” because there is so much less friction doing something like user.neighbors.magic_data rather than writing a bunch more $query = “SELECT *…” $result = mysql_query($query)… while ($line=…

   Comment by Srimpten Q. Griderloy — 6/13/2005 @ 9:03 am

4. At the very least, though, I’m going to stop worrying about abstracting away the database and will try to learn to love it, whatever environment I use.

   I hear ya. I’m over in Perl-land, but there too, all abstraction layers have failed to really let me use a database as much more than an object persistance layer. SQL is a powerful way to combine and recombine data; all the persistance layers I’ve tried simply force me to clumsily reimplement the work the database can already do for me, and do so much better than anything I can write in the time willing to on it.

   Comment by Aristotle Pagaltzis — 6/14/2005 @ 2:44 am

5. At the very least, though, I’m going to stop worrying about abstracting away the database and will try to learn to love it, whatever environment I use.

   I hear ya. I’m over in Perl-land, but there too, all abstraction layers have failed to really let me use a database as much more than an object persistance layer. SQL is a powerful way to combine and recombine data; all the persistance layers I’ve tried simply force me to clumsily reimplement the work the database can already do for me, and do so much better than anything I can write in the time I am willing to spend on it.

   Comment by Aristotle Pagaltzis — 6/14/2005 @ 2:45 am

6. Instead, each page has some PHP code at the top that makes one or more SQL queries, followed by HTML markup with only minimal PHP added to insert dynamic results.

   I congratulate you write now Spagetticode.

   It works, it actually seems scalable and maintainable

   Is it a jocke?

   Comment by Alex Knaub — 6/14/2005 @ 2:10 pm

7. Wouldn’t a better comparison be PHP vs. Ruby or maybe Blue Shoes vs. Ruby on Rails? Comparing a scripting language to an application framework doesn’t seem like the best way to go.

   Comment by keith — 6/14/2005 @ 2:39 pm

8. I have to agree with Keith. You are comparing apples and oranges. It’s like comparing PHP with Strus + Tapestry + Hibernate. Which one would you say it’s easier? Still, you would have to admit that Rails is a lot easier that such a Java combo. Personally I make a living developing in PHP and have used different MVC PHP frameworks (and built my own) and now I’m starting to use Rails. I’m making my company switch to Rails for some large projects and I’m not looking back. Good lok with straight PHP.

   Comment by Adrian Madrid — 6/14/2005 @ 4:05 pm

9. Sorry to add to the nitpickers, but you say that Java people sniff at PHP and Rails (setting aside the fact that the apples to oranges comments are 100% correct) because they are only good as toy languages then pass judgement after working on small toy projects. Try comparing a PHP MVC-app to Rails and seeing what you think then. With erb, Ruby too supports a page oriented / templated design much like PHP. That would be a good side by side with PHP itself.

   Comment by Chris — 6/14/2005 @ 7:03 pm

10. Lots of great comments — thanks everyone. Note that I’m comparing the web application design styles that PHP and Rails encourage, not the PHP and Ruby languages themselves. All Turing-complete programming languages are equally capable when you look at them long enough — it’s the programming communities that grow up around them that differ.

    When you strip my posting down to its roots, the real question is whether it makes sense to organize information in web apps primarily as objects or as views. I used to be a big fan of the object approach, but it keeps getting me into trouble as soon as I move too far past the basic CRUD level.

    Comment by david — 6/14/2005 @ 7:44 pm

11. Its not a question of objects *or* views, the real answer is both. Rails provides that balance very nicely.

    Comment by Curt Hibbs — 6/14/2005 @ 10:40 pm

12. I can relate to this post. I come from a background of serious C++ and Java infrastructure development, but have recently done a few small websites (just a few tables) using PHP. I find the simplicty of the PHP way of doing things very refreshing. Not having to worry about configuration or compiling makes the code-test cycle very quick. It would be intersting to try to find the level of complexity where it makes sense to start using the more complex frameworkd like Ruby on Rails or J2EE.

    Comment by Toivo Lainevool — 6/15/2005 @ 1:50 am

13. PHP vs rails might be apple to oranges, but In my own experience there is much more than a grain of truth in the concept that most MVC/application frameworks are 1 - not really needed in building 99% of web apps, and 2- tend to be more complex than the problem they aim to solve.

    Separating sql from html is usually a best practice that will give you 80% of code reusability and maintainability.

    SQL-to-object layers will usually be: 1 - harder to debug: is the local cache copy of the data in sync with the db? 2 - sloooow: you are giving away the best featuers your dbms gives you. You are ususally better off writing a stored proc than a query anyway. And what about objects that map to n tables? You will have to write views first, that map into objects. 3 - much less widely known and accepted than plain SQL. Next coder in the project is likely to have had sql experience, not necessarily experience with db-abstarction-layer-ofthe-month

    Templating langauages are nice, but theings get complicated very quickly as they evolve into full fledged languages (see Smarty for a behemoth). In the end a simple language is a better bet than a good framework!

    Comment by Gaetano Giunta — 6/15/2005 @ 3:48 am

14. Gaetano — Smarty is a behemoth, but since PHP is itself a template language, all you really need is something to separate out your view logic. Savant (http://phpsavant.com/) is great for this, and it uses PHP itself as the template language, so it’s lightweight and very fast.

    Comment by Paul M. Jones — 6/15/2005 @ 8:28 am

15. Just a general note - if you want something approaching a case study of how to build a maintainable PHP application, with use of MVC framework, check out Eventum, http://dev.mysql.com/downloads/other/eventum/index.html, MySQL’s bugtracker application.

    Pretty much it’s what you’re describing here, with two further abstractions in the form of a template engine (Smarty) and classes with methods wrapping individual queries. The controllers themselves are individual PHP scripts with names corresponding to the actions they perform e.g. close.php. There are more elegant / clever / minimalistic ways to do things but Eventum represents a sane / safe approach to PHP apps.

    Comment by Harry Fuecks — 6/20/2005 @ 9:54 am

16. I had many of the same concerns with Ruby on Rails - until I moved passed the prototype and started developing real applications with the framework.

    The #1 reason I’ll never code in PHP again (and try get out of J2EE) is that RoR makes it easy to do things the right way. I reuse far more code and I find it drastically easier to track down bugs, conduct unit tests, use continuous integration, and refactor.

    These are things you won’t experience in a weekend prototype - they are brought to light when you deliver an easily expandable, well-tested, and working application to clients.

    Comment by Derek Haynes — 6/30/2005 @ 12:56 am

17. I use PHP for 5 years now and really love it. There are 2 things that bother me though. For starters there are numerous MFC frameworks, code databases and other stuff but none of them is official supported except PEAR (which i don’t like for some unexplainable reason). Furthermore there is no decent universal package system in PHP.

    Yesterday i read three Ruby on Rails tutorials from Curt Hibbs (O’reilly).

    I was impressed.

    Coming from page-oriented models en moving to MVC a few years ago (even creating my own PHP MVC framework). I like the way ruby implements the MVC model because is resembles my own solution model.

    Ruby on Rails has already surpassed my own PHP MFC framework on things like javascript integration & AJAX.

    Switching frameworks is hard, switching languages is even harder …

    Comment by W. Westenbrink — 7/2/2005 @ 8:04 am

18. […] s are not applicable to the world at large. I’ve already mentioned that I find OO a poor fit for database-driven webapps, even though I […]

    Pingback by Quoderat » Blog Archive » Sean McGrath’s obit for SOA — 7/2/2005 @ 9:07 am

19. I know the guy that put this PHP on Trax together. It gives developers the ability to program in a most popular web language, yet in a framework that mimics Rails. No need to learn Ruby. http://www.phpontrax.com

    Comment by Eran — 7/14/2005 @ 6:01 pm

20. You mean its a cheap clone of ROR and should be called Ruby on Rails

    Comment by adam — 7/17/2005 @ 12:30 am

21. […] That being said, I can recommend that if you are building systems that require the complexity of a full-stack web framework (i.e. PHP, CGI won’t cut it) and you are currently using something other than one of these two frameworks in any language (including Java and .NET) on any platform, that you move swiftly to adopt either if possible. If there is something barring you from making that switch, well, where’s your patch? Make it happen. […]

    Pingback by Rails and Django Compared [@lesscode.org] — 7/17/2005 @ 2:49 pm

22. I’ve worked in PHP for 7 years (and some Java). Perl people had similar backlash to PHP when PHP was taking over its web niche.

    I think Ruby on Rails is good beginning in making itself a niche of web applications.
    It takes more thought to make a “realworld” * application fit into MVC, so I don’t think RAILS is going to take over PHP.
    ( * limited time, limited experience, limited scope of the application)

    Ruby itself, or Python, might. (I’d speculate more towards python because it still lets you mix functional and object programming.)

    I think the real problems MVC and other design patterns attempt to address are clear logical separations of code in larger systems. We’re all still in the infancy of a kind of architectual engineering. UML, flowcharts, requirements and specs written in English are our blueprints.

    Check out aspect oriented programming, mostly used in javaland if you want to find a way to address big architectual issues. Otherwise, if you use PHP, try to clean up your code and separate and abstract functionality that was a happy, dirty hack a few years ago. If you use Ruby or Rails try to address critcisms as well as bugs, because the customer is always right.

    Comment by Jonathan Hendler — 7/19/2005 @ 9:41 pm

23. Apparently even the Rails people prefer PHP:

    http://www.rubyonrails.com/index.php
    http://web.rubyonrails.com/includes/iframe_header.php?body_id=weblog

    Comment by Thomas Joad — 7/21/2005 @ 11:53 pm

24. PHP fanboys are failing to see a very important distinction here - Rails is for building scalable web *apps*, not for building a quick data-driven website.

    My own site is 100% PHP, and I will not likely change that. My newest project, however, will be in Rails, because it’s simply far easier to build an object-based web application in a framework like Rails, than coding in PHP. I should know, this is my 5th attempt at building this project. I’ve tried Perl and PHP, and am finding that 2 months of rails work is already surpassing 3 months of PHP work, and the system is far easier to debug and extend.

    Making the database invisible shouldn’t cost speed. Rails creates the SQL and you can view it all in the logs to see what’s going on. I’m not going to claim the SQL is as good as if I had hand-written it, but it’s not something I’m concerned about causing speed issues. The backend seems to be pretty well-written, and continues to improve.

    Another consideration is that all RAD tools come with a cost in speed. VB is a language I despise, but I can’t deny that people with vision have been able to throw together an app in a short time, and provide a valuable and useful product that fills a hole somewhere. At my previous job, we originally aimed for Visual C++, scoffing at our competitor who used VB. The competitor constantly outdid us, building new features faster (and with more stability) until we switched to Delphi.

    What was my point… oh yes, speed tradeoffs. In most cases, if you use a RAD tool properly, you’ll lose a small bit of performance and cut down the development cycle drastically. For most web apps, the query performance isn’t the problem - it’s the bandwidth. And with rails’ architecture, using proper page/action/fragment caching is a breeze, so you can optimize *later* if you need to, without any code redesign.

    Final thought: don’t rag on rails if you don’t spend a good deal of time playing with it. It may claim to be easy to learn (and it is, mostly), but there are things that make a lot of PHP/Java/Perl people change their minds when they dig deeper than the first layer. It’s really easy to use non-traditional database table and field names if that’s what you want to do, or if you’re connecting to a legacy database, for instance. Many-to-many relationships are expressed so easily it’s almost criminal. Hierarchical data structures, which are usually a pain to implement in a relational database, are a breeze. AJAX functionality, as of 0.13.1, is extremely powerful and still easy to use.

    Dig deeper; you may be surprised at what Rails can do.

    Comment by Jeremy Echols — 7/22/2005 @ 2:39 pm

25. The real question is: what framework in PHP offers, right now, about the same stuff as ruby on rails with a great community and great docs? I work in PHP everyday and I love it, but I loved how I can build a prototype/application in RoR with just some lines of code. Most of my admin backend systems could be made in RoR in hours instead of days. Any ideas to improve productivity in PHP development (CRUD aplications and not-so-CRUD apps).

    Comment by Paulo Silva — 7/24/2005 @ 4:20 pm

26. […] .blue { color: blue; } [23:18] I said: You have to read what I found today… [23:18] I said: http://blog.workhabit.com/ [23:18] Aaron spewed: I kinda figured, since you said you were gonna work on it yesterday afternoon, which was baby class. [23:19] Aaron spewed: looking. [23:19] I said: I worked on it yesterday night! [23:19] I said: But it’s more complicated than I thought… [23:19] I said: https://addons.mozilla.org/extensions/moreinfo.php?application=firefox&category=Developer%20Tools&numpg=10&id=697 [23:19] I said: This is really really cool. [23:19] Aaron spewed: even funnier is that he misspelled “primitive” [23:19] I said: Lol. [23:20] I said: English? [23:20] Aaron spewed: sure ;0) [23:20] Aaron spewed: you played w/spring? [23:20] Aaron spewed: I’ve actually fell in love with spring+(struts+spring IOC) [23:21] I said: I have [23:21] I said: I started readying up on it last week after we talked. [23:21] I said: Dude, cool. [23:21] I said: I mean, it’s really, really, really cool. [23:21] I said: Beats the HELL out of the weblogic JSP I programned with, and beats the living crap out of ATG Dynamo droplets [23:21] I said: IMHO [23:21] Aaron spewed: I ended up refactoring a struts impl today.. ended up with 4 more classes, implemented the IOC layer, and managed to cut out 120 lines of code. [23:21] I said: struts+spring [23:21] I said: yep [23:22] Aaron spewed: droplets == teh sto0ped [23:22] I said: Lol. [23:22] I said: No kidding [23:22] Aaron spewed: and the code ended up being far simpler, and I even got a chance to mock objects, write tests, and have them all pass. [23:22] I said: Check this out: [23:22] I said: http://www.phpontrax.com/ [23:22] I said: Well, that’s what the rebuttal was about. [23:22] I said: You have to read it. [23:23] Aaron spewed: I’ll read it..s till checkin’ the blog. [23:23] Aaron spewed: I need to stress something: [23:23] I said: phpontrax is seriously fucked (please do). I’m not sure what to make of it. (I hope that’s a good thing). [23:23] Aaron spewed: BE VERY, VERY, VEEEERRRY CAREFUL about what you implement as an aspect. [23:23] I said: Huh, really? [23:23] I said: What’s the impact? [23:23] Aaron spewed: ooh yes. [23:24] Aaron spewed: aspect: layer of application logic that tends to apply across an entire project or module (e.g. security or logging layer). [23:24] Aaron spewed: What does that mean? [23:24] Aaron spewed: (i’m asking) [23:24] I said: I’m confused. [23:24] I said: What are you asking about? [23:24] I said: Schmoo? [23:24] Aaron spewed: no, AOP. [23:25] I said: Read this when you’re done with the other two links. [23:25] I said: http://www.megginson.com/blogs/quoderat/archives/2005/06/11/rails-vs-php-mvc-or-view-centric/ [23:27] Aaron spewed: The problem with Aspects is that when you implement one, you better be DAMN SURE that it applies to everything in your project, and hope to GAWD that that’s not gonna change. [23:28] Aaron spewed: Oh, and I disagree with your blog.. Software *IS* becoming more complex, it’s just that the tools we use are streamlining the process to make complex things easier to develop. [23:28] Aaron spewed: smarter, not better, and simpler, not easier. [23:28] I said: Right. [23:29] I said: I don’t agree. [23:29] Aaron spewed: how come? [23:29] I said: Software is becoming more technical, but in actuality it’s easier to mantain, easier to write, and more scalable with less code. [23:29] I said: So, while it might have more pieces, it is inherently simpler. [23:30] Aaron spewed: I agree with you partially, but I think it’s because we’re using different vocabularies.. [23:30] Aaron spewed: I thin the concepts we are trying to describe (in code) are becoming far more complex.. The applications we write do more, are more intelligent, and for good reason. [23:31] Aaron spewed: The tools we use to implement those have in turn become more complex, and allow us to do far more than we would have, say, 5 years ago. [23:31] I said: Ok… go on, you realize I’m going to have to post this online somewhere right? [23:31] I said: Indeed. [23:31] Aaron spewed: Of course, for those of us who write those tools, it becomes far more complicated. [23:31] Aaron spewed: and yes, I do. [23:31] Aaron spewed: [23:32] Aaron spewed: Take, for example, your generic web-services platform.. [23:33] I said: ok. [23:33] Aaron spewed: the baseline for any Webservices platform consists of a five basic concepts: Data, security, metering, billing, and support. [23:33] I said: why don’t you bring the shotgun to the meeting, aaron? [23:33] I said: ok, go on… [23:33] Aaron spewed: The majority of companies (that I’ve seen) focus on data and support only. [23:34] Aaron spewed: I have yet to see a company focus on the other three, but only because there are literally NO turnkey solutions for doing so. [23:34] Aaron spewed: With the data layer, one might use a standard SOAP or rest library to leverage a pre-existing dataset.. That’s easy. [23:35] Aaron spewed: Simplest case is that of an RSS feed. [23:35] Aaron spewed: For support, there are innumerable CRM tools to mitigate customer support queries. [23:35] Aaron spewed: Worst case on support is developer forums. [23:35] I said: Right. So far I’m with you. [23:36] Aaron spewed: For security, metering, billing.. I haven’t seen _ANYTHING_ workable.. Companies are writing their own solutions, and half the time the technology hasn’t caught up with the requirement, leading to an INSANE amount of reinventing the wheel. [23:36] I said: Indeed, I’m in that weird place right now with a few projects I’m working on. [23:36] I said: So… [23:36] I said: ? [23:37] Aaron spewed: A good example of a security issue that might be addressed within the webservices arena: [23:37] Aaron spewed: Say you have a data feed that you’d like to charge $1.00 per 1000 requests for a particular subscriber. [23:38] I said: Right. [23:40] Aaron spewed: You have a few different requirements, but you’ve eventually settled upon a system by which each subscriber needs to authenticate against the system, but the subscriber in question may have several hundred (or thousand(!)) customers that in turn make direct use of the feed from your web service. Now what? How do you authenticate? How do you manage the subscriber? How do you handle this particular need (which, I might add, is a requirement for what I would guess to be about 90% of the paid web services in development)? [23:42] Aaron spewed: On top of that, the customer is requiring that you mitigate any fraud against his feed, and compensate him for any issues that may arise. [23:42] Aaron spewed: So suddenly the data layer leaks into the authentication layer, and subsequently into the support layer. [23:43] Aaron spewed: So a solution that seemed simple at the technology level suddenly becomes far more complex from a business perspective, requiring the software to mitigate far more reaching business issues. [23:43] I said: OK, you’ve just nailed the essential problem of web services — and Google and Amazon haven’t solved this yet. Neither have I btw. I think honestly, that *relative* billing might hold the answer (usage based on other customer’s usage) so those that use the most pay the most, but that’s my own personal thinking. I’ve never read much that anyone else has though about the subject to be honest. [23:43] Aaron spewed: and such, the tools evolve to handle such an issue. [23:43] I said: Right. [23:44] I said: Well, so much of software development is like that. I’ll bet you 9 out of 10 lines of code written for a web application is in reaction to a requirement that was never conceived of until users started actually using the application in question. That’s normal. [23:44] Aaron spewed: But what I’m getting at is that businesses are far more interested in solving business problems rather than software ones.. And so that’s where the trump card lies in the current iteration of this industry. [23:45] Aaron spewed: Nobody in business cares anymore how a mysql table is rendered into HTML.. they’re more worried about what user x will do with data y, and keeping user z from seeing what user x is doing. [23:46] Aaron spewed: and with good cause. [23:46] Aaron spewed: Which brings us back to what spring, struts, and rails have to offer. [23:47] I said: Wait, stop right there buster. Nobody in business was *ever* worried about software problems. Even in the height of dot bullshit insanity, no tie guy every cared about the implementation over the result. [23:47] I said: All they cared about was controlling costs. [23:47] I said: But ignore this point. Go on, I want to hear where you’re going… [23:47] Aaron spewed: Don’t get me wrong, I’m agreeing with you. [23:48] Aaron spewed: It’s that the PROGRAMMERS themselves are starting to worry less about software issues and more about business requirements, which means that software has far more potential to do what it’s intended to. [23:50] I said: Indeed, and it also means that software has gotten out of software’s way, which is the point of the article, and the reason I am saying that it is simpler. [23:50] I said: Easier to use, faster to implement, better than it was last year, happier than a dog in a bone factory and what not. [23:51] Aaron spewed: Now, these MVC/IOC frameworks have a lot to offer where the olden-days of so-called 4gl applications (e.g. powerbuilder) failed.. They allow for a level of flexibility and simplicity while increasing, INCREASING reusability and modularity. Software systems are maintained by frameworks, and are tied together modularly, allowing for each subsystem to exist on its own, lending to the overall complexity of a particular application. [23:52] Aaron spewed: So in part, you are correct.. software systems are becoming simpler, but only because the business problems those systems support are becoming more complex, and for us lowly programmers to understand what’s actually happening, those systems NEED to stay simple. [23:53] I said: Right, but that’s the natural order of things. [23:53] Aaron spewed: Oh, absolutely. [23:54] Aaron spewed: My big concern at this point is the enormous level of process required in order to correctly integrate these systems, which seems to be (in the eyes of some programmers) a replacement for the complexity of individual systems. [23:54] I said: All programming solutions ultimately evolve to the minimum level of effort required to effeciently solve them, given enough time. Unless you’re working with Windows. [23:55] I said: Ah. [23:55] Aaron spewed: (don’t get me wrong, I’m not sold either way on this one) [23:55] I said: Look, I think you’re really hitting on something there. [23:55] Aaron spewed: I think I’m close. [23:56] I said: Futurists have suggested the next step in computer programming is AI, which ultimately begs the question of whether the complexity can be handled abstractly. It is the most logical choice, albiet a little trekky. [23:57] Aaron spewed: we’re getting close to that.. At present, most modern shops are dealing with spring, which results in “wiring together” bits of functionality, albeit with a config file. [23:58] Aaron spewed: I recall reading in one of the XP advocacy groups that “Meetings are no substitute for lack of process, and process is no substitute for communication between peers” [23:59] Aaron spewed: Which is a great analog for the interaction between subsystems of an application, don’t you think? [23:59] I said: Well, I have to tell you, my favorite quote relates, but it not quite complimentary [23:59] Aaron spewed: “Committee.. A life form with 12 legs and no brain” ? [00:00] I said: Ike said, “A plan is useless, but planning is invaluable”, and I think progressive developers recognize this. [00:00] Aaron spewed: I agree wholeheartedly, and it quite closely summarizes my stance on “design as you go vs. design up front.” [00:02] Aaron spewed: with one, you reduce the cost of change, with the other, you increase the cost of initial concept, but have the potential to plan more accurately for known circumstances. [00:02] I said: Right, so you must agree with my simple tenant that software is in fact becoming simpler, because obviously you reconize that it’s development has become more streamlined and development methodologies are finally evolving to take advantage of the non-plodding dynamism of intellectual software development [00:02] I said: That sounds unclear. [00:03] Aaron spewed: And one of the reasons that there are so many semi-mediocre java developers in the market for work. [00:03] I said: But lets say that methodologies are developing that recognize that risk mitigation can best be accomplished by flexibility, instead of concretized plans. [00:03] I said: Ah yes. Please, let’s not go there. But I agree. [00:03] Aaron spewed: Because one of the tenets of agile is that the programmers involved are smart enough to make design decisions on their own. [00:03] I said: [00:04] I said: Exactly. [00:04] I said: And PM are necessary, but not for the reasons you thought they were in 2001. [00:04] Aaron spewed: Oh, they are? Wow, missed that one. [00:04] Aaron spewed: Product Developer? Yes. [00:04] Aaron spewed: Marketing Director? Yes. [00:04] Aaron spewed: Programmer? Yes [00:04] Aaron spewed: Usability? Indubitably [00:04] Aaron spewed: Designer? Yes [00:05] Aaron spewed: Project Manager? What exactly can they do that the product developer can’t? [00:05] I said: Symantecs. [00:05] Aaron spewed: So they sit around futzing with Antivirus while I code? I don’ [00:05] Aaron spewed: t think so ;0) [00:05] Aaron spewed: (j/k) [00:05] I said: did I spull thit write? [00:05] Aaron spewed: Semantics? [00:05] Aaron spewed: […]

    Pingback by workhabit: blog » Blog Archive » A conversation with Aaron. — 7/28/2005 @ 6:56 pm

27. Interesting article and discussion.

    Another interesting thing is that people seem to mostly be concentrating on two-tier apps, where the server code accesses the database directly. These apps tend to be simpler which means that they can easily be written in straight PHP but they also can easily be achieved with something like Rails, which wraps the database with an object layer. The stuff that people do in J2EE tends to be three-tier architectures where there’s a layer of business objects and business logic on top of the database. Perhaps Rails would be a bigger win in this type of situation? In this type of situation, you’d have to write a bunch of glue code in PHP, but presumably in Rails you’d just modify the pre-generated scaffolding.

    I’m no Rails or J2EE expert though. My experience is with PHP, building for the most part, two tier kind of stuff. I see Rails as being interesting for prototyping.

    Now that I’ve gone through a basic tutorial of Rails (http://webmonkey.wired.com/webmonkey/05/28/index4a.html) and have seen how to build really simple apps, I’d like to hear from the Railophytes about how it fares for more advanced stuff…

    Comment by Marc — 7/29/2005 @ 12:53 pm

28. Getting your feet wet with Ruby on Rails

    This article doesn’t teach you a lot about Ruby or Rails, but the nice part about it is that it shows you how easy it is to build web apps with Rails.

    I went through his tutorial last night and looked at my watch before and after. Literally, i…

    Trackback by Marc Abramowitz — 7/29/2005 @ 12:56 pm

29. The best framework I have seen so far is Perl’s Catalyst, which improves on Rails in many ways, and builds on of the killer apps of the Perl world — Template Toolkit (TT2) and Class::DBI. The flow control mechanism is superior to Rails’ (and borrows from Cocoon), and the syntax of TT2 makes implementing a true MVC and page-centric app a breeze. People seem to bust on Perl just because it has been around, and it’s syntax isn’t “clean,” but it still seems to have the best apps at the end of the day. PHP is great — in part because it retains some Perl and C grammar — but to date it has nothing like CPAN, which is the real reason Catalyst ist possible.

    Comment by w1tness — 7/29/2005 @ 9:24 pm

30. Thanks for the article. When I tried out the Rails tutorials I didn’t find the paradigm pleasing. I’m still trying to figure out if that is because I’m not comfortable with web-based OOP or becuase I’m too familiar with the page-based PHP style. I certainly thought Java OOP was elegant, though I didn’t use it too extensively - but I haven’t been able to feel that elegance on the web side yet, and I think that this article points out why - because, fundamentally, traditional web apps are view-centric, and don’t adapt easily or particularly well to the MVC model. Certainly, there are plenty of ways to make web apps work with MVC and other OOP frameworks, but it doesn’t seem straightforward to me, at least not yet.

    Comment by Ryan — 8/3/2005 @ 5:32 pm

31. The problem here stems from the incorrect definition of what a web application is — it is not about views, nor is it about objects. A typical web application is centered around the state.

    The MVC metaphor (or pattern) is solely concerned with the state as well. This is why it is a very natural fit for the web application paradigm. As the user/community interacts with a particular web app, it changes its state. That change governs how is the web app going to behave, which in turn facilitates various behavior from the end-user/community. All these changes in state need to be detected/processed/communicated by the web app.

    Rails is by far the most sophisticated platform for enabling developers to articulate the above described dynamics. Placed next to Rails, J2EE and/or .NET platforms look like a very elaborate simultaneous translation session during a rock concert for the hearing impaired. Yes, it is possible to ’sort of/kind’ of communicate in real time what’s going on at the concert stage using the sign language, but the real thing is to actually plug in and experience the performance directly.

    Alex

    Comment by Alex — 8/4/2005 @ 5:09 pm

32. > Rails is for building scalable web *apps*, not for building a
    > quick data-driven website.

    That’s a somewhat arbritary distinction. The Relational Model is able to provide data-schemas for every “need” that arises in the real world. It only starts getting “problematic” if you develop a (complex) OO-application first, and then want to “tack-on” persistence at the end using an RDBMS. Obviously programmers not familiar with the relational model and how to take advantage of it, favor this way of development - hence the hype and the many fanboys.
    But then there are also those that believe it is going to cut short their development time (which does cost more than performance), because they don’t have to think and write DB-stuff. And to those the article gives a nice answer, IMHO. Sometimes it may, but often it won’t.

    Comment by Frank H. — 8/6/2005 @ 9:29 am

33. There’s a lot of misunderstandings here. PHP is not comparable to Rails. PHP is a language. Rails is a platform.

    PHP is not page-based. The easiest way to start with PHP is to write page-based PHP, that’s all. But you can write php scripts that output no html.

    I use my own homegrown MVC php platform regularly. The webhit hits a very short php script that looks like this (pseudo-code; not accurate php):

    tpl->assign(”user”, new User($this->userid));
    $this->tpl->display(”index.tpl”);
    }
    }

    new Index();

    ?>

    The Page is a Model. The User is a Model. Index.tpl is a smarty template.

    My system is homegrown so it isn’t anywhere near as configurable as some of the open source models. But you’re comparing Rails to the absolute worst way of coding within PHP. Only newbies program in php by shoving php code (and sql commands! Ugh!) in the middle of an html page.

    Comment by tunesmith — 8/20/2005 @ 2:54 am

34. Ah well… the blog code wouldn’t output my php code example. Oh well.

    Comment by tunesmith — 8/20/2005 @ 2:55 am

35. […] Because of all this, I can never get MVC quite right. I end up in PHP land, embracing the messiness. Throw the code into the template, mix in some of the controller in there too even though I know I shouldn’t. The MVC way won’t be clean for me anyway, so let me at least get the job done quickly. PHP is great at that. I think Dave Megginson is expressing a similar sentiment here? […]

    Pingback by Standard Deviations » Blog Archive » AJAX and the clean Model-View-Controller — 9/7/2005 @ 11:06 am

36. […] Quoderat ? Rails vs. PHP: MVC or view-centric? […]

    Pingback by zuzara.com » Ruby on Railsについて調べる — 9/19/2005 @ 10:10 am

37. What about IBM and Zend working on an official framework that is supposed to be better then sliced bread and a visual studio type IDE….. I am excited, all these new frameworks, etc.. are really make each other work harder

    Comment by ryan — 10/20/2005 @ 12:51 am

38. check out http://cakephp.org

    Comment by gwoo — 10/21/2005 @ 1:21 pm

39. Maybe the reason you got tired of updating your persistance PHP layer is because you had to do them manually. I know that’s the reason why I almost gave up on persistance layers and “object databases” in general. But yesterday I found this website: haven’t used it too much yet but it looks pretty nifty, since apparently, whenever you need a new field, you simply regenerate your class. This might reinforce your choice of PHP vs OnRails.

    http://www.phpobjectgenerator.com

    Comment by jake — 11/4/2005 @ 7:42 pm

40. I’m sorry but this article is very irresponsible. You played with the two languages for a couple days and then you write an apple-to-oranges comparison with nothing more than a cursory first impression.

    First of all, you haven’t spent enough time building PHP apps to realize that you end up doing a ton of repetitive work. Sure it feels faster than the ever-verbose J2EE, but combine a dynamic language like PHP with a good MVC framework and you’ll triple your productivity again.

    As for Rails, you claim that it tries to hide the database, is difficult to debug, and only helps with CRUD. You are wrong on all counts. First of all, RoR is very careful to give you hooks to any level of abstraction you want, from the common find and find_all queries through custom joins and where clauses, down to raw SQL. Why is this better than raw SQL? Because 90% of queries are the simple ones. Just because you are familiar with SQL doesn’t mean a simpler syntax isn’t better.

    As for debugging, Rails is slightly weaker than PHP in terms of raw print lining, but it excels with features such as the breakpointer and logger. Not to mention you can debug the model completely separately from the command line. The ruby console allows you to modify instances of objects, not only changing methods, but modifying and creating singleton methods on the fly. This opens up debugging doors that users of almost any other language can only dream of. Debugging rails is actually pretty easy, but of course it will be hard when you are a complete beginner to ruby and rails.

    The whole CRUD thing is a typical argument by people who make a snap judgement after watching the 15-minute video. Scaffold is not even 1% of Rails. It’s practically an afterthought. What makes Rails special is how it utilizes Ruby’s advanced features to set up a framework where you can truly Not Repeat Yourself to the maximum extent possible. Look into routes, flash, helpers, filters, callback, validation, and observers before making these kinds of snap judgements.

    There are definite criticisms that can be made of Rails, but this kind of knee-jerk reaction just pollutes the web with misinformation. If you’re going to ‘try something out this week’, please give it a serious try.

    Comment by Gabe da Silveira — 11/8/2005 @ 2:37 pm

41. Eventhough I haven’t used Ruby on Rails, I have seen their promotion video. Been on PHP boat since 2002, and I must say It’s just up to you! It’s OO now with PHP5 and it has matured to the level that it’s become enterprise level. Check Zend.com the official & commercial back of PHP. Lately IBM, Oracle, and others been partnering with Zend for PHP integration. SAP is in the game too! And with introduction of Zend Platform there is no excuse why not to use PHP.

    PHP5 has all that you’re used on in Java, XML libraries, unicode, and many MVC frameworks that are available and waiting for you to grab them such as Mojavi, ZNF, Prado, BlueShoes, etc…

    And if you’re worried about IDE or deployment tools, then check out Zend Studio at Zend.com

    One very important point about PHP is that it’s joint the big players, we’ve got PHP certification now!

    To conclude, use what makes sense for your job, project, and prefrence. I beleive you could never compare apples & oranges! Rails is a framework while PHP is a language and a platform.

    Comment by M Saleh EG [dotone] — 11/17/2005 @ 6:04 pm

42. […] So for a long time have been avoiding anything MVC and sticking to page centric designs because they work and stuff get’s done. Side note: those that scream “spagetti” should evolve—with self discipline (yes—something that doesn’t usually scale to team development) you can write stuff that you can live with this way. […]

    Pingback by SitePoint Blogs » Looking at Catalyst — 11/18/2005 @ 5:32 pm

43. In reference to the original post, I find it ironic that a Java developer is complaining about the “deep layering” of Rails apps. Java, and all its Three Letter Acronyms (TLAs), have become the essence of superflous complexity. Ruby-on-Rails, by contrast, is very lightweight.

    Comment by Dean — 11/20/2005 @ 12:13 am

44. You should really, really try CakePHP (www.cakephp.org) it has all of the advantages of PHP, many advantages from Rails and a few little more things that make life easier.

    Comment by sosa — 11/22/2005 @ 1:33 am

45. […] This might just mean finding smarter ways to write view centric code, emphasizing DRY while avoiding spaghetti—consider the “article.php” in this URL. […]

    Pingback by SitePoint Blogs » MVC and web apps: oil and water — 12/22/2005 @ 6:38 am

46. You may consider www.achievo.org is a RAD in PHP, in few line you can code a CRUD application. They started in 2000 and there is a version 5.5.3 of their framework ready for download.

    Comment by fabio — 12/31/2005 @ 10:03 am

47. Please consider that if only requirement to WEB server is to publish XML then what is the position of Spring or Structs os Rails?

    In my point of view, PHP is ok, mod_python is ok, snakelets is ok, servlet is ok. JEE or Rails may be good but useless. Everything for build page is XSLT or AJAX which runs within browser.

    Comment by klaus — 1/19/2006 @ 5:09 am

48. PHP feels good by accepting that you don’t have to hide the SQL.
    For persistent ‘objects’ I like visible SQL (queries and views for your abstractions). PHP is scalable as long as your SQL is scalable.

    In Java I like iBatis instead of Hibernate.
    Comes down to ‘I use PHP/Ruby/Java whatever to acces my SQL data’ versus ‘I use SQL to store my PHP/Ruby/Java objects’.
    What I find lacking in object oriented programming are (SQL) views. In SQL I can combine several tables/queries into one view and then treat that view as the basis for other queries.

    Comment by Rinie — 1/27/2006 @ 10:40 am

49. what is better ??
    this type of questions are not applicable in the software field , because the best is the best for that particular problem as an example my company is devoloping e-learning materials and tools and we devoloped all the projects using php becase
    1- the all team knew it very well.
    2- whe were dealing the database in a very low level.
    3- we dealed with multimedia files in very low level format , creating swf,image and audio files from php.

    after we produced our application we needed to have all those tools as a cd based applcation so we crafted apache,mysql,php together and with some addiotional exe’s whalllla we had a custom version that works in a cd.

    could this be done in ruby ??? i doubt but it still possibel.
    does that make ruby bad ??? of course no but in this particular situation i think it would be a bad choice

    Comment by Mohamed Elyas — 2/11/2006 @ 9:25 am

50. rotfl,

    cakephp vs. ruby on rails -> GOOD!

    PHP vs. ruby on rails -> BAD!

    Comment by mroq — 2/14/2006 @ 10:09 am

51. even if I love php, I feel the lack of what cpan is for perl and rails is now for ruby, i think the php comunity’s real problem is that pear is not as good as php itself. too concerned of beeing perfectly designed… none uses it.

    Comment by smt — 2/16/2006 @ 6:57 pm

52. […] to prevent this, i’ve tried not to use MVC yet but i ve tried a popular php template engine; named as smary but it’s sucks. it is complex(some say it’s a behemoth), slow, and doesn’t work when the page has java scripts and other irritating miscelleneous codes in it. today, i meet savant. i hope it is not as bad as smarty. as i took a glimpse on the codes, seems like even worse… other than php, there are web frameworks which is Ruby on Rails and Django. both are popular open source web application framework. hoping from page to page, i found out this page which is good to read and i love the comments coming from the rest of the readers. check it out: Rails vs. PHP: MVC or view-centric? […]

    Pingback by litiumOnline » it’s all about web app — 2/17/2006 @ 11:58 pm

53. >> I think that the answer has to do with the fact that web applications — whether producing HTML for people or XML for machines — are really about views, not objects. In anything but the most trivial cases, the views involve information from many different types of objects merged together to create a new object type.
    —
    I would disagree with that. Maybe my programming has not been proper MVC, but I have found that for something more complex than a couple of webpages put together - I spent about 6 months helping convert a legacy Foxpro app to PHP/MySQL - the separation is essential.
    Imagine - we had like 10 developers in 3 countries, all trying to convert different parts of an around 120 screen Foxpro app (they defined the job amount by the “screens” converted).
    Not separating Model into classes independant of controller/view pages would have been suicidal.

    A typical page that user would call, would fulfill the role of Controller - getting input, validating it, and then depending on input and general app state, calling the appropriate actions in different models, assembling all the presentation info received into a structure, which then gets passed to a View (we used Smarty for Views, and it worked quite OK).

    something like (pseudoPHP):

    AddressEntryManagement.php (controller class):
    …
    if (user input action is delete && $id is sane and some other checks)
    {
    $addr = new AddressEntry($id);
    $addr->delete();
    $VIEW[’result’]=’Success’;
    }
    … // other actions

    $tpl= new Smarty(’AddressEntry.tpl’);

    $tpl->assign(’DATA’,$VIEW);
    $tpl->display();
    =============
    not entirely proper MVC maybe, but definitely loads better than the default approach used of simply making all the DB calls in the same place as presentation and controller.

    Comment by Grrr — 2/23/2006 @ 6:17 pm

54. […] A couple of weeks ago, Tim Bray posted about PHP and received a firestorm of comments, just as I did when I posted about PHP and Ruby on Rails almost a year ago. PHP generates a lot of passion, for good or for ill: my posting still gets a new comment every week or two. […]

    Pingback by Quoderat » PHP, XML, and Unicode — 3/1/2006 @ 12:26 pm

55. Obviously, .net is the way to go.

    Comment by jake — 3/3/2006 @ 11:47 pm

56. I agree with this article for the most part. In fact, I am trying to do some independent research about frameworks in general which will hopefully clarify when a framework stops relieving the developer of tedious tasks so they can concentrate on their problem and starts forcing the developer to fit the problem to the constraints of the framework.

    Comment by Simone — 3/11/2006 @ 10:24 pm

57. […] This might just mean finding smarter ways to write view centric code, emphasizing DRY while avoiding spaghetti—consider the “article.php” in this URL. […]

    Pingback by Steve’s Log » Blog Archive » MVC and web apps: oil and water — 3/17/2006 @ 3:43 pm

RSS feed for comments on this post. TrackBack URI

Sorry, the comment form is closed at this time.