Remove frameworks, replace with component libraries

[codeguy]

@philsturgeon Thoughts? I've been second-guessing frameworks since I added them. I think they're tangential at best. Re-usable component libraries (Symfony Components, Packagist packages, etc.) would better serve our audience without the polarizing and popularity-contest side-effects.

[codeguy]

As for which libraries to mention:

• Packagist
• PEAR
• Symfony Components
• Zend Framework Components

Any others you want?

[KrisJordan]

+1 for letting nature continue to run its course.

Someone newish to web dev stands to benefit from using a framework with a consistent approach and narrative over trying to put together a home rolled collection of packages.

The direction I could see this section evolving is providing a better high level narrative on the "main page" (currently the component library approach isn't given any language, and the frameworks language makes it sound black and white like you're either using a framework or plain-old PHP) with a sub page of components/frameworks/etc that does not attempt to be terse.

The node.js Modules wiki page is a great example of how such a secondary page of libraries/modules can evolve: https://github.com/joyent/node/wiki/Modules

If PtRW can grow/evolve a good, fairly comprehensive list of useful packages, with sensible organization, and brief descriptions, it'd be an extremely valuable resource. Packagist search is only good if you know roughly what you're looking for and it's inherently bad at providing any curation. Maybe it even makes sense to setup this page as a Wiki page on this repo, which is even easier to edit by the community at large, rather than a subpage which must go through the pull request moderation process.

[philsturgeon]

Ok but keep them as second options called "Zend Packages" and "Symfony Compoments" instead of using the framework name, then if we kill frameworks it doesn't matter anyway.

Emailing from my iPhone 4S like a BOSS!

On 13 Jul 2012, at 00:44, Josh Lockhartreply@reply.github.com wrote:

@philsturgeon Thoughts? I've been second-guessing frameworks since I added them. I think they're tangential at best. Re-usable component libraries (Symfony Components, Packagist packages, etc.) would better serve our audience without the polarizing and popularity-contest side-effects.

---

Reply to this email directly or view it on GitHub: https://github.com/codeguy/php-the-right-way/issues/104

[philsturgeon]

That was a little short.

I don't think we should remove frameworks just yet, as many of them are making the transition to being component based and it would be a shame to cut them out until then. I am a little bias of course as this is exactly what FuelPHP is doing, but so are CakePHP and a few others I wont mention.

Your list is as extensive as I can think it needs to be, but I dont suggest we kill Frameworks just yet. I would suggest we don't add too many more to that list, as it started as popular frameworks and will end up being as long as the Wiki list of about 50 if we add ALL THE FRAMEWORKS.

[fabpot]

Don't you think that we should first define what a popular framework/library is? If not, you will keep adding new ones over time and it will definitely become an unmanageable list with no real value.

Also, what about adding another section with libraries that solve one problem (and they solve it well) like Assetic, Monolog, Imagine, Twig, ...

[philsturgeon]

@fabpot defining the popularity of a framework is a tricky one as there are not too many metrics to go on. We had this conversation on the PHP-FIG mailing list and it didn't get anywhere: GitHub watcher lists are unfair, website traffic, community forum user counts, etc? I don't want to see a million on there, but I don't want to be an elitist jerk that keeps others out now that the two I represent are in - so I can't say much on which ones come in or not.

For the libraries, could championing specific packages for certain areas be condoned? I guess it could be, and this site would be the place to do it, as that's not something for the FIG to do.

That said what would be the reasoning for suggesting Twig over Dwoo, or Blade, for example? We will most likely end up with the same issue we have with frameworks. Do we suggest the most popular based on certain metrics (which is somewhat self-fulfilling) or do we have such a list of "or's" that the reason for having the list in the first place is no longer relevant?

[wilmoore]

Maintaining this list is likely to get pretty unwieldy. I'd vote to forgo the framework list altogether. Here are a few lists I found after 3 second web search:

• http://www.phpframeworks.com/
• http://www.phpwact.org/php/mvc_frameworks
• https://en.wikipedia.org/wiki/Comparison_of_web_application_frameworks#PHP_2

I think it may be better to link to one of those (probably wikipedia) and point contributors there to keep it up-to-date.

[philsturgeon]

Ok, let's rip out the framework list and replace it with a piece of text like:

Rather than re-invent the wheel, many PHP developers use frameworks to build out web applications. Frameworks abstract away many of the low-level concerns and provide helpful, easy-to-use interfaces to complete common tasks.

You do not need to use a framework for every project. Sometimes, plain PHP is the right way to go. But if you do need a framework, there are three main types available:

• Micro Frameworks
• Full-Stack Frameworks
• Component Frameworks

Micro-frameworks are essentially a basic wrapper to route a HTTP request to a callback, controller, method, etc as quickly as possible, and sometimes come with a few extra libraries to assist development such as basic database wrappers and the like. They are prominently used to build RESTful API's and are great to use in combination with a frontend JS-framework like Backbone.

Many frameworks add a considerable number of features on top of what is available in a micro-framework and these are known Full-Stack Frameworks. These often come bundled with ORMs, Authentication packages, etc.

Component-based frameworks are essentially collections of classes and libraries. These may be collections of PSR-0 components or simply a collection of classes that can be used together. Component-based frameworks can be used together to make a micro-framework, or a full stack framework, as using components you can do whatever you like.

Or... something.

It's my birthday, my heart isn't in it.

Whatever the text, we then link to those sites who already maintain lists of frameworks. and remove our list.

[wilmoore]

They are prominently used to build RESTful API's and are great to use in combination with a frontend JS-framework like Backbone.

They are prominently used to build remote HTTP services.

Many frameworks add a considerable number of features on top of what is available in a micro-framework and these are known as Full-Stack Frameworks. These often come bundled with ORMs, Authentication packages, and more.

Component-based frameworks are essentially collections of classes and libraries. These may be collections of PSR-0 components or simply a collection of classes that can be used together. Component-based frameworks can be used together to make a micro-framework, or a full stack framework, as using components you can do whatever you like.

Component-based frameworks are collections of specialized and single-purpose libraries. Disparate component-based frameworks can be used together to make a micro- or full-stack framework.

[wilmoore]

Happy Birthday :)

[padraic]

I'd vote for de-politicising things. As much as I'm embedded in Zend Framework, long lists will be out of place on the site. Also, "Zend Framework" can't be shortened to Zend Packages because Zend offers no such product (can't butcher a name just to fit an agenda). The same applies to libraries multiplied by a few thousand - there's even greater duplication and adoption rotation there unless it's something really hard or niche.

Externally linking to a more objective listing might be a good idea so the site can focus on the principles of deciding whether to use a framework, component library, etc (we call them all frameworks when they have MVC in RL).

There will be exceptions obviously. Some things are very obviously done better by one or two solutions (Testing and Security are two good exceptions to allow recommendations). I'm also keenly aware that I directly linked to Zend\Escaper as a reference class for context-based escaping - not for the sake for marketing ZF but it may come across that way unintentionally to a reader.

[philsturgeon]

In which case "ZF2 Packages" would be the repository name. There was no butchering intended, we're just linking to repositories of reusable code.

[padraic]

For Component Based, would note these may include MVC - ZF springs to mind. + section re Bundles since most framework have replicated them in one way or another, e.g. ZF Modules (aka Zundles to those with a sense of humour).

Also, happy birthday :P.

[philsturgeon]

Yeah I was trying to avoid linking to all the CI Sparks, Laravel Bundles, Kohana Modules, etc type sites.

If components can be used standalone - in the form of PSR-X or otherwise - and require little-to-no chunks from the framework then it can be considered a component.

For example, most of the FuelPHP 2.0 PSR-0 components require the Fuel\Utilities which have some basic array operation stuff. They can be considered standalone code. Can the same be said for Zend Packages? Because CI Sparks sure as hell don't :)

Phil Sturgeon

On Friday, 13 July 2012 at 11:55, Pádraic Brady wrote:

I'd vote for de-politicising things. As much as I'm embedded in Zend Framework, long lists will be out of place on the site. Also, "Zend Framework" can't be shortened to Zend Packages because Zend offers no such product (can't butcher a name just to fit an agenda). The same applies to libraries multiplied by a few thousand - there's even greater duplication and adoption rotation there unless it's something really hard or niche.

Externally linking to a more objective listing might be a good idea so the site can focus on the principles of deciding whether to use a framework, component library, etc (we call them all frameworks when they have MVC in RL).

There will be exceptions obviously. Some things are very obviously done better by one or two solutions (Testing and Security are two good exceptions to allow recommendations). I'm also keenly aware that I directly linked to Zend\Escaper as a reference class for context-based escaping - not for the sake for marketing ZF but it may come across that way unintentionally to a reader.

---

Reply to this email directly or view it on GitHub: https://github.com/codeguy/php-the-right-way/issues/104#issuecomment-6959917

[padraic]

The way I view it is that we wouldn't be linking - it's mostly a nod to the emerging practice of making frameworks more extensible (on the assumption we all agree that's a good thing). Seems a useful bit of awareness to pass on.

ZF2 Modules would never be components. ZF2 components are sometimes barely components. It's easy to forget I'm the grumpy one on the ZF2 team for a reason ;). Many components are freestanding though - adding DI helped a bit and reminding folk that Modules !== Library will help in the future. Inter-dependencies among packages will always exist - only FIG can really resolve that one by pushing through agreement on minimal APIs for caching/http etc. so we don't have packages grabbing N http clients.

[inoryy]

-1.

Only linking to components libraries promotes what is already a plague in PHP community - way too much code written under NIH syndrome.

If this project is aimed at beginners, then they definitely should be guided towards popular frameworks first, to avoid duplicating others work (and arguably doing a much worse job at it). Then, when they gain enough experience, they can find those components and write their own frameworks matching their specific needs, knowing how it's done in other places by other people.

[padraic]

I think the question is how to guide them to frameworks. Having a list gets political - who's the biggest, the most popular, the best, etc. Just covering the principles of what a framework is, why they exist, what they're good at (and not) can let new folk head and pick their own based on what we've told them. Finding the most popular frameworks isn't that hard anyway - most do a decent marketing job.

[inoryy]

@padraic well, we'd have to either rip out links from whole project or add every single more or less active library to appropriate section if you want to be politically correct.

Speaking of finding things, first 2 links I get from google for "PHP frameworks" are http://en.wikipedia.org/wiki/Comparison_of_web_application_frameworks#PHP http://www.phpframeworks.com/ Which gives me zero overview and guide nowhere.

On the other hand, if I were to google "Ruby frameworks", I get bombarded with links to either RoR or Sinatra...

[codeguy]

Just catching up on the conversation. I think @padraic said it best:

I think the question is how to guide them to frameworks. Having a list gets political - who's the biggest, the most popular, the best, etc.

I want to avoid the political shitstorm of having to maintain that list and explain to some why others are on it and they are not. I also don't know what metrics beyond personal preference or general popularity would guide our decision on who to include. I DO agree that we should still steer new users toward frameworks... as @KrisJordan and @Inori both said, they are great for beginners to get started quickly without duplicating others' work. We just need to find the right wording.

As for linking off-site, I'm not personally aware of a reputable, comprehensive list. I think those have the same problem we do here. So I think it comes down to: do we list them here on our own by whatever metric? or do we let users discover the actual frameworks themselves via word of mouth/google/etc.?

[codeguy]

Or, perhaps we keep our own list but with an addition that explicitly states our list is guided by popularity (and general goodness)? That's certainly opinionated, but it does give us a reasonable metric (not necessarily fair) with which we can guide new users.

[inoryy]

We can keep a small list based on some metric and add a small note saying "For a more comprehensive list of PHP frameworks, see here: ... (where?)"

[inoryy]

As for avoiding political shitstorm - we can use github most watched list. It can also be biased, but at least it's transparent

[codeguy]

@Inori Exactly, transparency is probably the best we can hope for. "Fairness" is too hard to define. That has my vote.

[codeguy]

Although, @KrisJordan (way up top) brought up an interesting suggestion about moving this list to the Wiki to avoid pull request moderation. What editorial control would that have, if any? @KrisJordan Is there any editorial decision-making that goes into the Node Module list aside from the community eventually reaching a mutual equilibrium after a series of member edits?

[philsturgeon]

It seems that the conversation has diverged into two, so I suggest we split things into two issues.

To talk about "Adding a Component Library section" please head over to #108.

As for talking about the Framework list, I see two options:

Option #1: Freeze the list as it is. After a week nobody has come up with anything truly missing, which shows that a large number of developers agree with what is there. At this point we can say that a framework needs X number of up-votes on a pull request or issue to get in.

Option #2: Shove in the text me and @wilmoore came up with and add a link to a Wiki page where people are able to update things. We can keep this under control with a T&C contract:

• The site needs to be within the two latest stable versions (sorry 5.1 frameworks, you can die now please)
• The site needs 1000 people watching it on GitHub or BitBucket (set up a mirror, these sites are important)
• They need to have a website
• If it's marked as inactive, delete it.

That should cover it? Everything currently on the list meets that criteria, but if we link people off to Wikepedia they see a LOT of terrible, terrible frameworks which have not seen a release in over a year.

If we have open terms, then we cannot be considered elitist for not accepting something into the project, and the most obvious political problems go away.

[codeguy]

@philsturgeon Regarding frameworks, I like option 2. I think the list will become more comprehensive that way and still remain good if the list adheres to the criteria. What does everyone else think?

[inoryy]

+1 for option 2

[padraic]

@philsturgeon's requirements have merit. I'd be +1.

[grakic]

+1 for option 2, I like the text and how it avoids the issue.

The solution is also very generic. If there is a similar problem with listing libraries for some task, or listing tools, editors,... it can be solved in the same way.

[codeguy]

Ok. We'll move forward with option 2. @KrisJordan Do you want to run point on this?

[KrisJordan]

Sounds like @philsturgeon has the wiki page language mostly ready above.

The 1000 people watching requirement seems arbitrary and high. Nate's Lithium is an example of a framework that wouldn't be listed. https://github.com/UnionOfRAD/lithium

1000 people is especially high for a library or component.

I'd say nix that altogether or bring it down an order of magnitude. Keep the requirement it's mirrored on GH or BB, though.

Would be valuable to mark which version of PHP is required per framework, too.

[philsturgeon]

Let's go with 500 for frameworks and not require it for a library or component (I wasn't suggesting the same requirements for components anyway).

I'll do that now.

Phil Sturgeon

On Friday, 13 July 2012 at 16:11, Kris Jordan wrote:

Sounds like @philsturgeon has the wiki page language mostly ready above.

The 1000 people watching requirement seems arbitrary and high. Nate's Lithium is an example of a framework that wouldn't be listed. https://github.com/UnionOfRAD/lithium

1000 people is especially high for a library or component.

I'd say nix that all together or bring it down an order of magnitude. Keep the requirement it's mirrored on GH or BB, though.

Would be valuable to mark which version of PHP is required per framework, too.

---

Reply to this email directly or view it on GitHub: https://github.com/codeguy/php-the-right-way/issues/104#issuecomment-6965647

[padraic]

I think the point was to be completely objective and impose a difficult bar to meet. If we drop it to say 600 (Lithium gets in) what else gets in besides Lithium? The purpose of the 1000 was to set a high enough watermark that the list would not be swamped. Maybe we should survey GH for watch numbers, agree on a list size, and then set the watermark based on that? It would still be a fixed number going forward (not a popularity contest).

[philsturgeon]

The main point of 1000 was setting a reasonable number that keeps out "Hai I made a frameworks can I be on the list?" bits of junk, of which there are many.

Phil Sturgeon

On Friday, 13 July 2012 at 16:23, Pádraic Brady wrote:

I think the point was to be completely objective and impose a difficult bar to meet. If we drop it to say 600 (Lithium gets in) what else gets in besides Lithium? The purpose of the 1000 was to set a high enough watermark that the list would not be swamped. Maybe we should survey GH for watch numbers, agree on a list size, and then set the watermark based on that? It would still be a fixed number going forward (not a popularity contest).

---

Reply to this email directly or view it on GitHub: https://github.com/codeguy/php-the-right-way/issues/104#issuecomment-6965978

[pmjones]

Once could start with the list of the FIG membership and go from there.

[philsturgeon]

Thats another political move, as projects not interested in the framework (e.g Kohana) but still very popular would be ignored.

If we say Must have X followers, OR be on the FIG, we're allowing a random clause for those who have certain alignments to come in.

Phil Sturgeon

On Friday, 13 July 2012 at 16:26, pmjones wrote:

Once could start with the list of the FIG membership and go from there.

---

Reply to this email directly or view it on GitHub: https://github.com/codeguy/php-the-right-way/issues/104#issuecomment-6966065

[inoryy]

just keep 500 and stop coming up with new rules, lol :D

[pmjones]

It comes down to judgment. There's no "technical" "fair" "objective" measure that's going to cover everything you think ought to be covered. Yes, you're going to get snapped at by people who don't like your judgment. Make no apologies for it; indeed, advertise it as such, including your biases, and then link to an outside source for a comprehensive list.

[philsturgeon]

I'm not looking for a golden bullet to make everyone in the PHP community happy, as we're world famous for never agreeing on anything.

Let's just say if the framework is a FIG member then they're a shoe-in. Golden perks for you!

[pmjones]

I think that's a good start. You can then say "additionally, these folks are not FIG but are notable for (whatever reason you like)".

[pmjones]

You may wish to further delineate by targeted PHP version; i.e., "project X is targeted at php 5.2 and higher; Y at 5.3 and higher; Z at 5.4 and higher" etc. That may be a bit much though.

[philsturgeon]

Done but was a little rushed, going dark for the weekend so please fix it for me! Laters.