Agreed. The core code is actually pretty well written considering the concrete backwards compatibility standards enforced by the devs, but most plugins are a total mess (and I'm saying that as a plugin author). I guess it is mainly due to PHP's low bar for entry and PHP's historical (but arguably not now) lack of enforcement of good programming practices.
There is potential for change though. There is a project backed by the core devs (can't remember the name) which will score plugins by their code standard and show the score in the plugin directory.
I feel it's not that PHP is low bar but rather widely accessible out of the box on almost all web hosting services... you don't have to set up a lot of stuff before running your web application.
I'd argue the only reason PHP still remains at the top is because no one has made X language to work out of the box with cpanel installations and run with little to no modification to run, lets say, django apps or RoR apps. Maybe if Python or any other language spent more time on improving that type of accessibility in the realm of web applications we could see PHP fragmenting in the later years...
I think the main reason I still prefer PHP after doing web development for over a decade is not its syntax but its set-up.
Picture me, often the only programmer, supporting several-dozen business web apps. Each app is in its own directory. To add a route, I just make a new PHP file. This eases mingling other, static, files in that same directory: CSS, JS, HTML, PDFs, documents, spreadsheets, images, and videos that the users wanted to supplement the app with. Maintaining a list of routes in some other file would complicate things, especially with the number and complexity of the apps that we have. (User-uploaded files are stored elsewhere.)
That is really a feature of CGI, and FastCGI, not PHP. But I like PHP more than Perl, and I'm not sure how well the FastCGI frameworks for other languages are written. For example, I often dream of using JavaScript in FastCGI.
But then again I am also spoiled by the extent of PHP's standard library. It's mainly a bunch of functions in the global namespace, but an alphabetic namespace is vast, and there have been just a handful of times that I wanted to make a function whose name was already taken.
PHP is also stable. I've never had a problem with a script bringing down other parts of the website or even other parts of the same app (except that one time when a coworker wrote a PHP script that built SQL dynamically and did it in a bad way, and used up all the RAM on the server).
PHP has been fast for me, even back in 2005. Then again I don't use third-party frameworks. I have written a few helper libraries, to reduce code repetition.
It's not as seamless as PHP (restarting the Passenger service to reflect code changes requires an ssh session and touching a pidfile), but shared hosting isn't entirely stuck on PHP anymore.
Comments
Agreed. The core code is actually pretty well written considering the concrete backwards compatibility standards enforced by the devs, but most plugins are a total mess (and I'm saying that as a plugin author). I guess it is mainly due to PHP's low bar for entry and PHP's historical (but arguably not now) lack of enforcement of good programming practices.
There is potential for change though. There is a project backed by the core devs (can't remember the name) which will score plugins by their code standard and show the score in the plugin directory.
I feel it's not that PHP is low bar but rather widely accessible out of the box on almost all web hosting services... you don't have to set up a lot of stuff before running your web application.
I'd argue the only reason PHP still remains at the top is because no one has made X language to work out of the box with cpanel installations and run with little to no modification to run, lets say, django apps or RoR apps. Maybe if Python or any other language spent more time on improving that type of accessibility in the realm of web applications we could see PHP fragmenting in the later years...
I think the main reason I still prefer PHP after doing web development for over a decade is not its syntax but its set-up.
Picture me, often the only programmer, supporting several-dozen business web apps. Each app is in its own directory. To add a route, I just make a new PHP file. This eases mingling other, static, files in that same directory: CSS, JS, HTML, PDFs, documents, spreadsheets, images, and videos that the users wanted to supplement the app with. Maintaining a list of routes in some other file would complicate things, especially with the number and complexity of the apps that we have. (User-uploaded files are stored elsewhere.)
That is really a feature of CGI, and FastCGI, not PHP. But I like PHP more than Perl, and I'm not sure how well the FastCGI frameworks for other languages are written. For example, I often dream of using JavaScript in FastCGI.
But then again I am also spoiled by the extent of PHP's standard library. It's mainly a bunch of functions in the global namespace, but an alphabetic namespace is vast, and there have been just a handful of times that I wanted to make a function whose name was already taken.
PHP is also stable. I've never had a problem with a script bringing down other parts of the website or even other parts of the same app (except that one time when a coworker wrote a PHP script that built SQL dynamically and did it in a bad way, and used up all the RAM on the server).
PHP has been fast for me, even back in 2005. Then again I don't use third-party frameworks. I have written a few helper libraries, to reduce code repetition.
Dreamhost will configure Passenger via cPanel to deploy your Django/RoR apps.
https://help.dreamhost.com/hc/en-us/articles/215769578-Passe...
It's not as seamless as PHP (restarting the Passenger service to reflect code changes requires an ssh session and touching a pidfile), but shared hosting isn't entirely stuck on PHP anymore.