Re: [RFC] [Discussion] Using and Mentioning Third-party Packages in PHP Documentation and Web Projects

From: Date: Wed, 28 Aug 2024 08:00:38 +0000
Subject: Re: [RFC] [Discussion] Using and Mentioning Third-party Packages in PHP Documentation and Web Projects
References: 1 2  Groups: php.internals 
Request: Send a blank email to [email protected] to get a copy of this message
On Wed, Aug 28, 2024, at 09:51, John Coggeshall wrote:
> 
>> And that is how you will find that the "new" languages will "win". If
>> we
>> don't promote how modern PHP Development works, then there will be more
>> "PHP, a fractal of bad design" articles to come for decades.
>> 
>> We *must* do better than this. It probably doesn't all need to be in the
>> documentation (doc-en), but it absolutely belongs on our website.
> 
> Hear Hear Derick!!
> 
> I am not advocating that php.net put its finger on the scale in favor of Laravel over others
> with this comment, but why php.net does not have a documentation analog similar to how
> Laravel's documentation is set up is beyond me. Useful installation instructions, sections on
> "How do I do database stuff", "Security", "Filtering Data",
> "Installing third party packages" etc... there are too many people who have embedded in
> their brains that PHP is a badly designed language because we don't teach or even advertise to
> people how to write good PHP code... as others have mentioned as an example, the lack of even a
> mention of composer on php.net is mind-blowing.
> 
> As Derick said, back 20+ years ago PHP had amazing documentation for the times -- miles ahead
> IMO than most open source projects. But the world has moved on, developers want and need higher
> level documentation that is more opinionated on not just the dry APIs available you might use to
> connect to a database (for example), but how to properly connect to a database. Back 20 years ago we
> had companies like Zend around who devoted considerable resources to filling that gap for the
> community (along with O'Reilly, etc.) but those entities are gone now and it is up to the
> project to pick up the slack.
> 
> I also think it's a mistake to get too caught up with the concept of
> "endorsements" and people worrying that "oh gosh if php.net talks about Laravel and
> Zend Framework then that means something bad for XYZ framework" (pick your favoriate techs
> here). It's easily solved by having a section on "Popular PHP Frameworks" that
> explains the concept that PHP as a language doesn't embrace any particular framework, the
> importance that you do generally want to embrace a framework to do anything serious, and provide a
> list of popular ones that people commonly turn to when building their apps. As for using a framework
> or any other PHP-related tech in the project's codebases... I think we're grossly
> overestimating how much weight that decision would carry with the PHP community at large. Short of
> the PHP Project stating "X is the official framework of PHP" (and especially if we say
> "We don't have an official framework but here are good options that are very popular"
> instead), the concern over the appearance of endorsements at this point is really an invented issue
> rooted at least in part by historic concerns that simply don't exist anymore.
> 
> Coogle

I agree with this to a point. What if I want my newish framework listed on the page? What are the
qualifications for being listed (or unlisted) there? Can anyone add their own framework?

If anyone can add something to the list, then it eventually will become as overwhelming as https://github.com/uhub/awesome-php and if there are
strict qualification requirements, the list needs to be reviewed periodically to remove projects
that no longer meet those criteria.

— Rob


Thread (31 messages)

« previous php.internals (#125335) next »