6 ms·

PHP is the framework because it's also the runtime, the language, the VM, the std library and the template language. Yet another, it's not a framework, it a me

by fleitz 13y ago

PHP is the framework because it's also the runtime, the language, the VM, the std library and the template language. Yet another, it's not a framework, it a mess, just copy some files, edit them, whatever, the framework is your application. So zen. Imagine what a disaster it would be if every rails app had it's own slightly modified version of rails.

vezzy-fnord 13y ago
Imagine what a disaster it would be if every rails app had it's own slightly modified version of rails. I don't know how extensible of a language Ruby is (certainly nowhere near as much as Forth and Lisp, though probably more than most other mainstream languages), but couldn't one argue that if you're building an app on top of Rails as your framework... you are, in fact, making a slightly modified version of Rails? This is pure semantics, I know. But on the other hand, would such a thing really be bad? A Lisp web framework would be all about that, for instance. I'm by no means a fan of PHP, but the author does have a point that it's essentially an ad-hoc templating system which lets you glue your own framework on the spot. Obviously it becomes a mess eventually, but it may be useful for small projects where you want to develop rapidly with minimal dependencies, or as a sort of Mozart coding philosophy. I actually think it'd be very refreshing if we got more frameworks that aren't based on MVC, which instead simply give you some APIs and let you use them as you see fit. I know there are some, but they're not widespread. Although you could essentially just grab a bunch of libraries and that'd be equivalent.
- dools 13y ago
  I'm by no means a fan of PHP, but the author does have a point that it's essentially an ad-hoc templating system which lets you glue your own framework on the spot. Obviously it becomes a mess eventually, but it may be useful for small projects where you want to develop rapidly with minimal dependencies, or as a sort of Mozart coding philosophy. You'd be surprised how un-messy it can be if you remove any arbitrary directory structures and arcane framework code. A big part of making this work for me has been the adoption of "Template Animation"[1] (or DOM templating whatever you'd like to call it) which does away with the need for the server side code to "build" the interface. Once you get rid of that, and provide an easy way for things to be split up and organised into classes, and if you avoid anything too far removed from "pure" PHP, it's really quite easy for anyone to come along and see what's going on. Of course it gets messy if you let it get messy, though ;) I actually think it'd be very refreshing if we got more frameworks that aren't based on MVC, which instead simply give you some APIs and let you use them as you see fit. I know there are some, but they're not widespread. Although you could essentially just grab a bunch of libraries and that'd be equivalent. That's basically where I landed. My applications now are a bit of boilerplate configuration and a bunch of folders with class files in them, that I either write or get from somewhere else. Because the interfaces are built completely in static HTML anyway you don't get all this mess to do with where to store your "assets" and how to structure your views/templates. [1]http://www.workingsoftware.com.au/page/Your_templating_engine_sucks_and_everything_you_have_ever_written_is_spaghetti_code_yes_you http://www.workingsoftware.com.au/page/Your_templating_engin...
- fleitz 13y ago
  PHP is an amazing tool for quick 50 line webpages. The problem with non-MVC frameworks is that generally most programmers won't go through the hassle of making MVC style classes. MVC cuts across so many domains that there have to be some really compelling reasons to abandon it. I'm interested though, what do you like to use as an architecture alternative to MVC?
  - vezzy-fnord 13y ago
    I'm not entirely sure of a concrete alternative pattern MVC for the web. I like the style of independent modules that frameworks like web.py provide, but that's not a unified pattern. Pretty much all web design patterns are based on models and views, including MVC, HMVC, MVP, MVVM and so forth. Perhaps more of the latter two would be welcome, especially MVP. Decentralized modules can still be quite useful for small apps. I don't think the hassle of forcing rigorous design patterns is necessary there.
dools 13y ago
Imagine what a disaster it would be if every rails app had it's own slightly modified version of rails. I think a more appropriate analogy would be: what if there were 20 or 30 popular frameworks for building apps on Rails? The bits that provide the consistency between Rails apps (ie. how requests get mapped to controllers, how arguments get passed into the application from the query string and how a response gets to the browser) are there in PHP already. You don't need a framework to know how PHP does those things. It's quite painful to come across a PHP application which does these things using some sort of PHP framework you've never heard of. Even though you know how simple what's really going on is (ie. some web request is being processed, a response written and optionally some data loaded from a database or other source in between) you have to trawl through reams of documentation to find out what little spin this framework has put onto it.

by fleitz 13y ago

vezzy-fnord 13y ago

Imagine what a disaster it would be if every rails app had it's own slightly modified version of rails. I don't know how extensible of a language Ruby is (certainly nowhere near as much as Forth and Lisp, though probably more than most other mainstream languages), but couldn't one argue that if you're building an app on top of Rails as your framework... you are, in fact, making a slightly modified version of Rails? This is pure semantics, I know. But on the other hand, would such a thing really be bad? A Lisp web framework would be all about that, for instance. I'm by no means a fan of PHP, but the author does have a point that it's essentially an ad-hoc templating system which lets you glue your own framework on the spot. Obviously it becomes a mess eventually, but it may be useful for small projects where you want to develop rapidly with minimal dependencies, or as a sort of Mozart coding philosophy. I actually think it'd be very refreshing if we got more frameworks that aren't based on MVC, which instead simply give you some APIs and let you use them as you see fit. I know there are some, but they're not widespread. Although you could essentially just grab a bunch of libraries and that'd be equivalent.

dools 13y ago
I'm by no means a fan of PHP, but the author does have a point that it's essentially an ad-hoc templating system which lets you glue your own framework on the spot. Obviously it becomes a mess eventually, but it may be useful for small projects where you want to develop rapidly with minimal dependencies, or as a sort of Mozart coding philosophy. You'd be surprised how un-messy it can be if you remove any arbitrary directory structures and arcane framework code. A big part of making this work for me has been the adoption of "Template Animation"[1] (or DOM templating whatever you'd like to call it) which does away with the need for the server side code to "build" the interface. Once you get rid of that, and provide an easy way for things to be split up and organised into classes, and if you avoid anything too far removed from "pure" PHP, it's really quite easy for anyone to come along and see what's going on. Of course it gets messy if you let it get messy, though ;) I actually think it'd be very refreshing if we got more frameworks that aren't based on MVC, which instead simply give you some APIs and let you use them as you see fit. I know there are some, but they're not widespread. Although you could essentially just grab a bunch of libraries and that'd be equivalent. That's basically where I landed. My applications now are a bit of boilerplate configuration and a bunch of folders with class files in them, that I either write or get from somewhere else. Because the interfaces are built completely in static HTML anyway you don't get all this mess to do with where to store your "assets" and how to structure your views/templates. [1]http://www.workingsoftware.com.au/page/Your_templating_engine_sucks_and_everything_you_have_ever_written_is_spaghetti_code_yes_you http://www.workingsoftware.com.au/page/Your_templating_engin...
fleitz 13y ago
PHP is an amazing tool for quick 50 line webpages. The problem with non-MVC frameworks is that generally most programmers won't go through the hassle of making MVC style classes. MVC cuts across so many domains that there have to be some really compelling reasons to abandon it. I'm interested though, what do you like to use as an architecture alternative to MVC?
- vezzy-fnord 13y ago
  I'm not entirely sure of a concrete alternative pattern MVC for the web. I like the style of independent modules that frameworks like web.py provide, but that's not a unified pattern. Pretty much all web design patterns are based on models and views, including MVC, HMVC, MVP, MVVM and so forth. Perhaps more of the latter two would be welcome, especially MVP. Decentralized modules can still be quite useful for small apps. I don't think the hassle of forcing rigorous design patterns is necessary there.

dools 13y ago

Imagine what a disaster it would be if every rails app had it's own slightly modified version of rails. I think a more appropriate analogy would be: what if there were 20 or 30 popular frameworks for building apps on Rails? The bits that provide the consistency between Rails apps (ie. how requests get mapped to controllers, how arguments get passed into the application from the query string and how a response gets to the browser) are there in PHP already. You don't need a framework to know how PHP does those things. It's quite painful to come across a PHP application which does these things using some sort of PHP framework you've never heard of. Even though you know how simple what's really going on is (ie. some web request is being processed, a response written and optionally some data loaded from a database or other source in between) you have to trawl through reams of documentation to find out what little spin this framework has put onto it.