Dan Allen to Code School: Why does Code School steer away from php?

    Jan 1
  • danallenhtn

    Why does Code School steer away from php?

    Any insight you can provide will be very much appreciated.

    danallenhtn · 1:58 am · dan@houston-data.com
  • Jan 5
  • Stefan Nychka

    Hi Dan! I don't know exactly but we're a Ruby on Rails shop, so we have tons of expertise in that, and php wasn't as popular as Python/Django which we're working on now.

    There are no plans of which I'm aware to do any php.

    I've heard php can make it very easy to write code, but also can result in poorly written code, namely logic directly mixed in with html.

    Rails, a framework built on Ruby, but they're both intertwined tons, is mvc and I think the first mvc web framework, so for large code it's better. More complex though, and I think arguably .NET and Django have matched or eclipsed it. I don't know enough about the various php web frameworks though to comment properly, and that knowledge would be needed for a fair comparison. But, again I think, all these frameworks were added well after programmers created php-only sites, with no framework or hard conventions to help improve a large code base.

    Anyway, last 2 pars. are my opinion solely, and as php is popular, even though there are no plans now, things may change down the road!

    Stefan Nychka · 9:48 am
  • danallenhtn

    Thank you very much for writing to me on behalf of Code School and its
    opinions on php.....


    Thank you for sending your candid thoughts, I appreciate them immensely.

    The topic of frameworks..... hummmmmmmmmmmmmmmm....

    So here is an opinion of mine. All that talk about separating logic from
    html, I think it's mostly wrong.

    Frameworks for large code base? That is crucial, no doubt about that.

    I believe it is possible to have an excellent framework that achieves all
    the benefits of frameworks and intermingling html with logic as part of the

    The key to frameworks is not that they separate logic from html. The key
    to frameworks is the common understanding and structure that everyone can
    use to facilitate teamwork, almost regardless of what the structure is.
    There is no real requirement for separating logic from html, that is an unfounded
    popular belief, passed on over and over but not correct.

    I have seen a lot of systems built around the principle of not mixing logic
    with html, and in every single one of them here is what happens:

    1. Either, the system is a pain in the ass to work on
    2. OR there are exceptions to the rule that says no logic mixed with

    The reason it has to be like that in a large dynamic system, there always
    are conditions that apply to writing html. Those conditions have to be
    somewhere. If they are not with the html, then they are somewhere else you
    have to go find, and that is what creates the pain the ass, because you
    have to deal with two parts of the system instead of one, to get the result
    you are looking for in a certain spot. It is not possible to separate html
    from logic. You always end up having to bring them back together. The
    trick is not to separate them and look for something else for organizing
    your framework.

    Here is my Challenge to you:

    If you can refer me to a course where a framework is used to separate logic
    form html and the frameworks is not a pain in the ass, and does not have
    exceptions to the separation of html and logic, then I will take that
    course immediately, because I need to know if there really is an exception
    to what I am talking about.


    danallenhtn · 12:22 pm · dan@houston-data.com
  • Jan 6
  • Stefan Nychka

    Hey Dan!

    No separation is perfect, of course. MVC is the current way most web systems do it, although they all have different takes on that, and technically other similar methods.

    Using apis, which I believe separates things even more, is another common approach. Plus there're similar separations solely on the front-end, too.

    One key benefit to separation is that front-end designers or developers can work on html, and although they need to know what the back-end does and how to interact with it, they don't often need to know how it actually works.

    They can concentrate on html and JavaScript, and documentation or an interface for the backend, and not get bogged down in any server/business logic.

    Similar I believe for separating db/model concerns on the backend from any communication on the backend between the front-end.

    Ruby on Rails does this. It's a huge pain to learn initially, I believe, but is worth it for the separation. This, like you said, in part allows teams to better work on the code.

    ASP.NET does this, and there's a version that uses MVC which is popular. That's eclipsed plain old ASP.NET web forms where everything was intertwined. Proof to me, although not perfect, the separation is way better.

    Those two would be good options.

    Also, I didn't mention to definitely vote for php and any related frameworks at


    Again, the frameworks may do the same thing as RoR and MS MVC, and if there's no legacy code and programmers are doing things properly, they'll likely work as well (and for all I know better, as I don't have enough experience like I said especially with php or its frameworks to really compare it to other frameworks).


    Stefan Nychka · 1:26 pm