Hacker News new | past | comments | ask | show | jobs | submit login
PHP in 2019 (stitcher.io)
901 points by brendt_gd 4 days ago | hide | past | web | favorite | 469 comments





I've actually been really impressed with Laravel after switching back to PHP for a few projects. Not only is the developer tooling experience some of the best I've experienced, it's just really the only framework I've ever experienced with a high quality ecosystem of tools—from Forge[1], which makes it dead-simple to deploy a Laravel app into production to things like Horizon, for managing Redis queues.

A great example of this in action is Laravel Spark[3], a first party base for building paid SaaS apps. I built and launched a writing tool, Write Together[2], to the world in under three weeks, payment systems and all, and got 150 paying customers in a matter of a few weeks. One hell of a great way to MVP an idea and build something useful, in a low amount of time.

I'm basically developing two Laravel apps full-time at the moment, and it's the most fun I've had in years...compared to the hellscape of NPM dependencies and other complexities I'm usually bogged down with. Composer, the package distribution system, really needs work and is incredibly slow, but other than that—I'm really happy.

[1] https://forge.laravel.com

[2] http://writetogether.space

[3] https://spark.laravel.com


Agreed, Laravel provides the best dev experience in the PHP world.

The funny thing is that Laravel basically took the Ruby on Rails philosophy and applied it to PHP. Just looking at their site it's clear they have a very similar vision: simple, fast and fun. One can always find differences but the basic principles are the same.

IMO this is great kudos to the Laravel guys, whatever language I use I always look for the tooling that follows the KISS principle. In PHP you have Laravel, in Java/SCala you have PLay, etc.

I need to add that, because of the job, I did a lot of PHP, Ruby, Java, Javascript with many different frameworks and I can say that Rails is still the best for me when it comes to dev experience if you need to move fast. Laravel has come a long way but it's still not at the same level of maturity in terms of tooling and ecosystem. As a bonus with Rails you use Ruby which is designed for programmer productivity and fun.

Anyway, whatever language/framework you use just keep it simple, that's the most important decision you can make for the health of your project.


It's funny, I remember when I started working on my first PHP framework, I knew about Drupal, CodeIgniter, Kohana, Symfony and Ruby on Rails. Back then, Symfony was the Ruby on Rails applied to PHP. And I wanted to have a more "php-like" approach to everything. That's when I made phponpie.com (the early attempt).

Fast forward to now. After 10 years there is https://qbix.com/platform . If you're reading this and know PHP / LAMP, I would encourage people here to try it and give me feedback. I've never really spent time growing the community or popularizing it like Laravel. But at every turn, it's made decisions that are as close to PHP and standards as possible.

In particular, the Db module may be better than Doctrine, for example.


> I knew about Drupal, CodeIgniter, Kohana, Symfony and Ruby on Rails.

I was a huge fan of PyroCMS which was based on Code Igniter. I stopped using it when the all of the JS frameworks exploded. I went back last year to check on them and found out they moved to Laravel.

https://pyrocms.com/

The community since then has grown by leaps and bounds. Good to see the Pyro team still out there making a great CMS.


I used both Laravel and Symfony but I ended up with the second. I didn’t like the way Laravel’s ORM has its models structured plus the Symfony PHPStorm plugin is a miracle. Your mileage may vary and this is just me but I never quite understood why people ended up loving Laravel so much vs. Symfony.

I used Silex (the symphony micro framework which was merged back into Symfony), which means I'm now using Symfony. I too prefer it to Laravel. I thinks less opinionated maybe?

honestly its ok to have a different opinion, different people prefer different things.


I feel Laravel is fantastic for Junior and medior programmers, while Symfony appeals more to seniors.

I’m a senior programmer and love Laravel. But maybe I’m a junior at heart ;)

All the worst projects I've inherited and rescued were Symfony. Developed by senior devs that overengineered. I'm sure newer Symfony is better and there's some good stuff out there but as a decade+ senior engineer I like Symfony components but not the framework. Love Laravel and Lumen and also some of the other microframeworks for some things. Enjoying Laravel Nova right now too.

Yep. Laravel is basically PHP on Rails. They do a great job with it too.

I dunno... Their home page looks like something out of the Panera Bread playbook looking at the homepage. 'Web artisans'? Why is it 'clean' because it has an absurd amount of whitespace and comments of platitudes for the code example?

"Clever" "marketing" language like this is not unique to Laravel, most frameworks use language like it for tag-lines on their homepage. Pyramid, a framework for Python, even goes with the same "artisan" language. They're just trying to be fun, inspiring, etc

From the home page of a few other frameworks:

Django: "The web framework for perfectionists with deadlines."

Flask: "Web development, one drop at a time"

Express: "Fast, unopinionated, minimalist web framework for Node.js"

Pyramid: "You need a Python web framework that supports your decisions, by artisans for artisans."

Why is it clean? Build an application with Laravel and you'll find out. :) The documentation and community are excellent. I've used many frameworks across many different languages, and (imo) it really is very nice to work in.

It's funny how the most negativity comes from people with very little experience, or at least recent experience, in the thing that they don't like.


It’s not funny. People who have bought in something have (1) to rationalize their choice and (2) cheer so the project remains alive and a major contender.

That's not my experience at all. Most developers I know have worked with technologies before and come out saying, "I would rather use something else next time."

They should have used "Laravel: The Framework Thomas Kinkade Would Have Created."

Glad I'm not the only one who thinks "modern PHP" struggles to fit more than a couple of lines of real code on a screen surrounded, as it is, by space-wasting nonsense such as block comments, blank lines and K&R brace style. No wonder people prefer Ruby. Around the time of PHP5 the language ditched its own identity and sought to become the scripting version of Java. Give me back my procedural PHP4.

Lol, I agree their packaging looks a bit different but the contents of the package are basically the same.

Working with both Laravel and Rails will make it clearer that they try to follow the same principles of convention over configuration and programmer happiness :).


PHP frameworks crack me up. They so often claim they're "powerful." What does that mean exactly, who is that language aimed at?

Then there is Laravel, why "artisans?" The word generally means pre-industrial. In my mind, that evokes devs doing edits on live code. Also, "Laravel" sounds like something to do with larvae.

Then there's Drupal, which for the longest time was "community plumbing," which did match the experience of having to call someone in for mysterious specialist emergencies.


The command line tool for Laravel is named 'artisan'. You use it to do everything in Laravel, from setting up controllers/views to seeding databases.

I guess "Laravel - The PHP Framework For Web Scaffolders" wasn't catchy enough.

(Can't edit. I meant the word "powerful," not the language PHP).

I don't like their code and architecture though. The code is ugly because it is built around static methods instead of proper OOP, and uses magic methods a lot. It is not easy to read.

Also, they love to invent their own names for existing things. For example, they named a folder with interfaces as "Contracts", although there are only interfaces.

You are using "Ruby on Rails" as some sign of quality, but if it uses magic and static methods like Laravel, I would consider it ugly too. Also, I remember reading somewhere that they were hotpatching imported modules. Luckily in PHP you cannot do it.


> it is built around static methods instead of proper OOP

The fake case against Laravel that never dies . The truth is found in the docs: https://laravel.com/docs/5.8/facades

> Facades provide a "static" interface to classes that are available in the application's service container. Laravel ships with many facades which provide access to almost all of Laravel's features. Laravel facades serve as "static proxies" to underlying classes in the service container, providing the benefit of a terse, expressive syntax while maintaining more testability and flexibility than traditional static methods.


What isn't fake is that Laravel uses magic methods everywhere, especially in the ORM layer.

There are way too many magic things happening under the hood for my taste.


Magic methods in PHP are very commonly used to help reduce code verbosity - having come from working mostly in C++ I appreciate being able to express things succinctly.

Much more important for code, especially library code is readability

Laravel is moving away from magic methods to using facades, FWIW.

The static methods you are seeing are by and large facades -- convenience methods -- but Laravel is still absolutely "proper OOP."

https://laravel.com/docs/5.8/facades

"Contract" is not a term they invented; it's a term from "design by contract programming," and Laravel enforces the "contracts" through interfaces.

https://en.wikipedia.org/wiki/Design_by_contract

(And, no, they did not invent the term "facade," either.)


If you think Rails is ugly you're going to have to frame this with what you think is beautiful so we know where you're coming from.

Rails does take a lot of established concepts like MVC and mangles them pretty badly, but the Rails version of MVC works well in practice if you're willing to overlook how unconventional it is. The beauty is not in the adherence to dogma, but the day-to-day experience of using it when you know how it works.

It takes surprisingly little code to do some complex things in Rails. I'm working with GraphQL now and it's stupid easy to build out an API with Rails.

Laravel might seem all sorts of "wrong" to someone who has expectations of "how things should be", but the Laravel way, when accepted for what it is, works. It provides structure and cohesion which in the PHP world is in extremely short supply.


There are comparable things with other frameworks too.

For example I wrote a course on building a SAAS app with Flask. It's available at: https://buildasaasappwithflask.com/

It covers everything about user registration, profiles, subscription billing, 1 time billing, invoicing, and about 50 other things you would likely want to do in a SAAS app or any application really.

The course comes with the source code along with 15+ hours of video explaining every line of code in stages, life time free updates and life time support for close to half the price of what Spark charges just for the source code for 1 site license (with the Flask course you can use the code in however many projects you want).

Spark's business model seems interesting though. I don't use it personally but do you just get the source code and nothing else? How do they limit you to 1 site if you end up with a local copy of the scaffolding / code base?


Nice! It looks very nice and complete. I've found this other one in Go lang https://buildsaasappingo.com (I'm not affiliated nor tested it) I think it is a good idea to turn something that you need for yourself into a side income, I've though about doing this same thing myself in a different language.

What can you tell about your experience building this course, is it worth it ? rewarding ? Did you find difficult to promote it ? what are the main channels to adquiere customers ?

And if you don't mind sharing some numbers, how many people purchased it so far?

I'd like to get an idea on how profitable (or not) and personally rewarding are type of courses, to motivate myself and write one of these one day.

thank you!

edit: I'm thinking maybe that was too many questions, sorry if so, you could create a "meta-course" on explaining all these things and I'd buy it! :)))


That's how the course came into existence.

I built a number of SAAS apps (and apps that had similar functionality) for a few freelance clients. Then I eventually thought "hmm, lots of repeated patterns here, maybe I can make this into a course", so then I made the course.

As for the process. Funny you mention it. The changelog just had me on as a guest for their "backstage" podcast last week where we talked about content creation and the process of recording courses. That's at: http://changelog.com/backstage/4

It covers most of your questions but it doesn't cover nitty gritty details on sales figures and revenue. Thousands of people have signed up for the course but I still do quite a bit of freelancing. Freelancing and course creation is my full time job.

I find it really rewarding at a personal level. I just like creating things, but it is a lot of work. It's not just hitting record and being done in 2 days. Expect it to take 3-6 months of full time work to make a course. Then there's having to keep it updated (because tech changes so fast) and ongoing 24/7 support.

Couple people have asked me to make a course on making courses. Maybe one day but at the moment there's still a bunch of technical courses I still want to make, a million blog posts to write (I have 85 draft posts that are unpublished) and some side projects in the works.


wow, serendipity I guess :)

Definitively I'll check the podcast, thanks a lot!


No problem. If you still have questions after the podcast shoot me an email and I'll do my best to answer everything.

Hey thanks for mentioning my book. Like nickjj after building 2 SaaS in Go, I noticed that there were lots of pieces that could be extracted into a library.

I'm currently building another with that library.


Every time I try out Flask, Aiohttp or even Express.js I appreciate more the stuff Django normally does for me.

Django abstracts away a bit too much, if you ask me. For a simple REST API it's complete overkill. I prefer Flask or Falcon[0], in which you don't just get better performance[1] but also a lower level of control.

[0] https://falconframework.org/

[1] https://klen.github.io/py-frameworks-bench/ or https://github.com/the-benchmarker/web-frameworks


Why exactly do you want a lower level of control?

You want the complete opposite; have as many problems solved for you already with battle-tested ways to break out of the happy path when you need to.

Every sufficiently large Flask app becomes a half-assed reinvention of half of Django, except without the hundreds of thousands of eyeballs and man-centuries of bug fixing.


I agree with your parent. When I started with (Python) webdev some years ago I picked Flask, but nowadays I use Django, as it has superb documentation and useful things built-in. In particular I miss the user-management, authentication and authorization in Flask.

Personally I consider Django without any additional apps less complex than Flask with apps (or "plugins" in Flask jargon) to handle basic stuff like auth.

If performance is a concern, both of them are insufficient and I would rather pick another language like Rust, Go or even Java.


I started with Flask, moved to Django, and now at work am back on Flask. It all depends on what you are building; if you are going to need some ORM, standard auth, etc, Django is a no brainer. However if you are going to be building out much of your own idiosyncratic architecture, Flask gets out of your way and avoids including lots of things you don't need.

For performance, we are building some parts of our system with Clojure. It feels extremely well suited, albeit with some initial learning curve.


How are you implementing REST using Faclon if I might ask ? fully custom ? or is there anything like DRF hanging around ?

Dito.

Really well done site for the course. The flow of the single page to the sign up is compelling.

Seem's like it'd have to be the "honor system". They could certainly add somethings to detect the software being used on multiple domain, but you could ultimately remove that if you were motivated to.

Tokens are issued from within the Spark customer dashboard and the token is required in order to pull the repo during install. It’s basically the honor system.

Thanks.

I noticed they have a public repo with a tool that manages a way to download the spark code base.

I'm guessing without a token you can't access whatever code that public tool pulls down, meaning you need an active token to get future updates of the code base? Pretty cool system if that's the case (there's motivation to keep your purchase to receive updates).

I'm not asking to try and rip him off. I was just curious about the mechanism of protecting the download. Sounds like the only real difference here is the download is done over a command line tool instead of a web interface. Other than that, it's no different than serving a protected file?


I believe so. Updates are handled through composer package manager and the process is no different than updating a normal Laravel installation. I've never seen any info about how Spark is protected, so I'm just going off of my personal experience using it.

I cut my teeth as a developer on PHP, back in the 4.3 days before they'd really placed their bets on OOP, and we were dealing with mysql_real_escape_string, needles and haystacks, and haystacks and needles. No PDO, XSS and SQL injections up the wazoo.

I can't say I enjoyed working on any of those projects compared to the kind of stuff I do now (and how much I've learned since), but I've been remarkably surprised by some more recent codebases, despite the architecture sometimes feeling a little over-engineered (Symfony 2, for an outdated example).

It's not the style of code I enjoy writing at all but I've seen some incredibly clean stuff that would put a lot of Rails apps to shame. And I'd take that PHP over a badly maintained Rails app any day.

I wouldn't use PHP by choice still, but I no longer care to be snobbish about it. People are doing some good stuff in it, just the same as has happened with JS.


Modern PHP is light years ahead of 4.3. Not just the ecosystem, but the language itself, the performance. It's really not bad.

> Composer, the package distribution system, really needs work and is incredibly slow, but other than that—I'm really happy.

It's also use abysmal amounts for RAM for some reason. I managed to use Chrome headless for my app with only 512MB, but not Composer.


How long ago was that? There were some issues if you had xdebug enabled, but AFAIK that has been fixed.

Just few months and I did not use xdebug on that server. To clarify it's was just CRUD app on Laravel with few small dependencies on top of it. Composer used like 700MB RAM to install it for whatever reason.

Just today, I had to resize the swap on a raspberry pi so composer could update the dependencies.

I've had fun issues recently where Composer crashed after hoovering up 1.5 GB of memory. (Composer sets that limit by itself on startup, I didn't arbitrarily choose that number.) XDebug was off. I fixed it by telling Composer to use unlimited memory.

I had to raise Composer’s RAM limit last week for a fairly simple Symfony project with less than 10 extra dependencies. I had to up it from 2 to 4 gigs. PHP 7.2.8. without xdebug.

To speed up Composer you can install Prestissimo [1] globally, it speeds things up considerably.

[1] https://github.com/hirak/prestissimo


> Composer, the package distribution system

a package distribution system.

Composer suffers some of the same issues NPM does, IMO: it encourages stuff like 'install dependencies at deployment' and "why write it when you can blindly trust someone else's code".

Not everyone who uses PHP uses Composer.


The vast majority of people using a package manager in the PHP ecosystem are using composer. It makes sense to call it "the" package manager.

I’d argue that the only “the” is one that’s distributed with it, which is PEAR. I’m not saying PEAR is used more or that it’s better, just that it’s the only one close to “default” with the language distributions.

PEAR hasn't been distributed with PHP in well over a decade, and the last commit to the PEAR "modernization" project was in 2011.

PEAR is an abandoned tool used by no one. Arguing for it to be considered "the" package manager is a really weird fight to pick.


I don't like that PEAR by default needs administrator privileges and installs packages into system directories. That's inconvenient because you might have many PHP applications, and each needs different versions of dependencies. What did PEAR developers think? That I will be working on a single app for whole life?

Installing libraries globally is inconvenient for developers. Sadly, most Linux package managers have same problem and do not allow you to install several versions of PHP or Node.


PEAR installation will be disabled by default in PHP 7.4, see https://externals.io/message/103977. It was a good tool, once, but the community has moved on.

pear/pecl are more for installing extensions TO php in my experience, where composer is for installing packages built IN php, so composer is more the defacto community package manager, pear/pecl are useful though when you need to install gmp, gdi, intl, etc on your local dev environment. I don't know anyone who uses pear to install carbon or guzzle, or any other php package though.

I literally know no one who uses PEAR.

I do. I was using it back in 2003... pear/DB. I still have some code from that era that uses it.

Would you use a pear dependency in a new project if you weren't pulling bits in from an older one?

Personally, I wouldn't... I worked with pear and pecl and composer is just far more pleasant to interact with.


I agree... No, I would not. That code is old enough to drive at this point...

actively maintained pear packages can be installed also with composer

Which is literally irrelevant to my point.

Last time I used composer (about 3 years ago) it had a nasty memory leak that eventually meant I had to run the build on a higher specced instance than the actual application. This was mainly due to the ridiculous dependancies of the application, but it was almost a show stopper. Has this improved?

Composer is very useful in penetration testing. Lot's of good information in the composer.json files people keep forgetting to block..

A Laravel or Symfony app operates out of the public/ directory, so composer.json shouldn’t need any blocking typically - it’d be outside the web root.

Yeah I remember the problems with composer. It's good now.

It is not a leak, it just loads too much data into memory so you need about 1 Gb of RAM to run composer update.

Yeah, that's not a thing anymore.

I hear you on composer being slow. One thing I found that works extremely well to speed up composer installs:

https://packagist.org/packages/hirak/prestissimo

Give this package a try, it really worked for me to speed up package management with composer.


In my opinion the framework matters more than programming language. One typically doesn't need the "odd" or "fancy" features of a programming language if the framework is well designed and/or a good fit for the shop's conventions or needs.

No doubt its great, but does anyone know how does it compare to django for saas apps?

Laravel was fantastic. The first month I followed the tutorial, I was bitter about the complexity, but when it came time to building my back end, it took only a few weeks.

I would recommend.


Laravel is interesting for greenfield stuff. I'm working on a legacy project and we've had a bunch of good times with zend as it allows you to transition to it more naturally piece-by-piece.

kudos to laravel team (and symfony, since IIRC, laravel is built on top of sf bundles)

I think the easiest thing to forget is what made PHP popular was how easy it was to get started writing software that worked good enough. The barrier to entry was incredibly low. It caused a lot of bad code & gave PHP a bad reputation but a lot of good was also made from it.

PHP made a lot of careers for developers as they were able to fake it until they made it while learning how to code & providing significant value to a businesses.

While PHP is nothing like its former self, most people who developed web apps in the first decade of the century will probably always remember PHP for what it was.


The thing that I like about PHP is that I can mix HTML, code, and database queries into a single file.

This is incredibly useful when learning basic web development, even though it doesn't scale for more complicated applications.

It's also incredibly useful when trying to bang out a simple experiment.


In the world of machining people will often build a tool for a job. Its a one off, or something that will rarely if ever be used again.

These features of PHP are still eminently useful if you have to do the dirty one off. You can eliminate a massive amount of time pressure (an emergency or time invested vs time saved) if you dont have a ton of overhead that comes with modern frameworks.


It also allows you to utilize and extend the full http protocol, something which most "serious" frameworks hinder.

PHP doesn't have anything to do with the HTTP protocol, Apache/Nginx/etc handle HTTP and simply call your PHP script with some global variables set to values parsed from the HTTP request

No, but PHP does not get in your way unlike many other web frameworks.

And many of us took the jump and refused to do things that way. You're wrong, PHP scales and you CAN do separation of concerns and have pretty, maintanable code, using a framework or not: just a matter of knowing what you are doing

It's pretty clear that he meant mixing HTML, code, and database queries into a single file was what didn't scale, not PHP itself.

I think you're missing the point of the comment - when it comes to prototyping PHP is incredibly easy to whip out a buggy test thingy in minutes that breaks all best practices but still lets you prove a concept or prep a demo.

> PHP made a lot of careers for developers as they were able to fake it until they made it while learning how to code & providing significant value to a businesses.

Unfortunately it also provided a lot of careers to developers who never got to the "make it" stage.


I think it's a bit harsh and elitist to label this with "unfortunately"; for developers like the ones you mention, often their goal or aspiration is not to work in a FAANG or silicon valley startup; they want to make a decent living as a developer in their city and this provides that career for them. Many of those companies aren't trying to be the next unicorn, they're just small dev teams trying to maintain a web site for their business.

Why on earth is that unfortunate? Seems like a positive thing to me, even if some people don't make it to the pinnacle of their craft so what? If someone has gainful employment and meaning in their life I see that as a net positive.

> Why on earth is that unfortunate?

Because many times, they write bad, buggy software. Because other people end up having to maintain it, or fix it, or replace it. Or they release things like plugins that malfunction, but because they're the best out of a set of bad options, end up being the de-facto solution that everyone has to deal with.

I'm not talking about people who build software that works ok, but has bad patterns. I'm talking about people who write cash register software that uses floating-point math to do calculations, or Wordpress plugins that fill up error logs with garbage or nearly DDoS sites because they don't understand how to write efficient code.

Not that I've done any of the above as an early PHP developer, no sir...


On one hand, I do see that HN (and probably Reddit) live in a bubble. Where most of the darling languages and tools have very low use in the real-world. And where most of the languages and tooling that actually run the real-world go un-discussed, or simply dismissed, because they're boring and don't appeal to students and entry-level devs working on side projects. I realize that the perspective most rookies get from these forums is completely distorted.

On the other hand, I ALSO think that PHP is only still relevant because of WordPress. The business world runs on Java, and .NET to a lesser extent. I see job postings for Python all the time, as it and the JVM run the worlds of data science and big data. One can even still make a thriving living with Ruby. But I just don't see any recruiter activity around PHP at all. And whereas my Java shop will hire Python or Node junior devs, on the theory that they can learn, we would more likely to skip over a PHP-based resume (if we ever actually saw any).


Often when there is a post about PHP I read over these treads sort of subtly trying to figure out how a language with such a large user base has remained basically invisible to me. And I don't think I live in the HN bubble, though I do use a lot of Python, in my consulting work I've also done plenty of work with .NET, JVM to a lesser extent and other "boring" tech.

But PHP has literally never come up, even as a suggestion or as a tool that is a small part of the company stack or whatever. It feels like I'm looking into a strange parallel universe of software development reading through these threads. PHP devs, where are you?


Right here! PHP and JS/TS is what I do every day.

PHP has its tentacles all over the web: WordPress and Drupal are immensely popular for simplistic sites and short-lived promotionals, Magento and WooCommerce attract many e-commerce users, and Symfony/Laravel handle the custom stuff. I've worked with all of these and have the scars to show for it.

All popular projects have swarms of consultants offering advice, prebuilt additions, and custom development. (E.g. WordPress plugins and themes are everywhere.) This is also a significant factor for the penny-pinching customer — from their point of view, they avoid vendor lock-in and expensive development this way. (Spoiler: it rarely works out, in the end. "Tower of Babylon" and "shallow learning curve" mix in very exciting ways.) So there are masses of people who know the basics of PHP and call themselves "PHP developers". In my opinion, just a fraction of them actually deserves that title.


So I get the sense that PHP is sort of the tool of choice for web development at small or medium businesses which are not primarily software businesses, but are looking to create a website and maybe do some ecommerce? Is that right? If so I guess it makes sense that I wouldn't have seen it, most of my consulting work has been at relatively large enterprises.

Pretty much any shared hosting service (which is the default for a small business not going for a more handheld hosted solution like Squarespace or Shopify) is cPanel enabled with PHP, MySQL (via phpMyAdmin), one-click Wordpress installation, and other similar features.

It definitely feels that way, yes. I've mostly dealt with small businesses looking for the lowest bidder and medium businesses unable to spend a fortune on software licenses and highly-experienced devs, and PHP fits that segment well.

> [WordPress and] Drupal are immensely popular for simplistic sites

That's not a sentence I expected to see. Ever. Drupal is popular for many things but for simplistic sites?


This may be a regional thing. I've seen Drupal 6/7 on a lot of sites where the original dev threw together five content types in the admin GUI and told the admin how to post new content. It worked well and was certainly less worrisome than seeing (outdated) WordPress.

We run about 1,000 simple websites off the same Drupal codebase. Custom forms, page layouts, etc.

So your argument is that a multisite project running a thousand sites off the same codebase containing custom forms and layouts is simplistic? Then, I pray, what do you call complex?

Maintaining 1000 servers

Right here! Started working for a PHP shop straight out of college, and have never been able to get hired for anything else since then.

Right here! Drupal has been moving into the enterprise sector with their latest release (v8, built on Symfony). I get a lot of interest from recruiters based on my Drupal background, especially lately.

ever heard of Facebook? Slack? Etsy? WeWork? Box? Yelp? just to name a few.

Or mediawiki

Here’s one right here!

In the world I’m in and the journey I’ve taken in my career of being in digital/dev for 10+ years, PHP is what I have based my dev foundations on. (albeit web rather than software)

I am recruiting PHP developers for my team now, and they are out there, but maybe not here?!

We make websites, and not a tremendous amount beyond that bar a few Laravel apps.

I suspect we travel in totally different worlds?!


I think the bubble has to do with purists vs pragmatists.

I once joined a Java team as a front-end dev (I'm full-stack). They would do the back-end. They had done everything by the book perfectly. Following all the best practices. But the back-end wasn't doing what it needed to do by a long shot. They were stuck. Meaning I couldn't make progress. So I cooked up a simple (temporary) PHP back-end so I could easily build the needed queries. All nicely secured with LDAP. I was literally running circles around their solution. But it was blasphemy.

Eventually they ported my code into Java. Some portions literally one-to-one. Nobody will ever know the critical role PHP played in this Java success story.


Sounds like they needed a better back-end developer, not PHP.

Java guys didn't ship much at my first real gig. Lots of tooling time and watching movies or discussing Star Trek.

I shipped apps in 2 weeks myself that the company got paid ~70k for. And we kept my clients.


I don't think so. "The bubble" is more about using shiny new languages like go and rust.

I was just talking about with a student who got on to a PHP project with an older developer lead. We decided that PHP is a code smell for a poorly managed project. You know, the kind that were common in the early aughts that featured poor version control practices, no tests, no automation, live changes, live database schema, etc., etc. That's certainly not the way things have to be, but it's never surprising if it is. The root cause is the developer in charge and their reports, but PHP usage is an easy marker to check. We found most examples using other languages (you mention) to be generally better managed in our area/sampling.

> PHP is a code smell for a poorly managed project

Woo, that's a harsh but honest assessment.. Having lived through countless PHP projects, I'd have to say I agree.

> That's certainly not the way things have to be

As the article pointed out, there are new developments in the language, frameworks, tooling, etc., that support better practices and well-managed projects. It's just that the average codebase still tends to be haphazardly organized, idiosyncratic, bloated, complicated, tough to maintain and extend.

The popularity and evolution of PHP have been impressive, and having used it for years I do have some fondness for it. But at some point, I think it becomes necessary to move on to other languages and systems that encourage best practices from the beginning, with a higher baseline/average code quality.


Well I've been gainfully employed for pretty much my entire career using PHP and I've never had a problem with recruiters. It really depends on the city, the companies in that city, and the overall market in your region.

Big business runs on Java/.NET, but small-midsized businesses run on a variety of different platforms partially based on the history of their IT department and their development needs.

The bottom line is that you can write a good greenfield web application for a midsized business faster, with less overhead, and with fewer headaches using PHP and a good framework than you can with Java or any of those other tools you mentioned. The tradeoff is that they don't integrate as easily with the huge backend software packages and may not scale as well as Java and .NET. Which is why huge businesses don't run with them as much.


> PHP is only still relevant because of WordPress

There's also Drupal, which is very common in higher ed.


Indeed, and also Joomla. But the thing with all of these CMS systems is that they're already written. So the related "PHP work" is writing or tweaking plugins for them.

It's kind of like acknowledging the footprint of Microsoft Excel and VBA. Yes, it's quietly a huge deal, and thousands of people hold a job largely because they maintain it for an organization. But it's also the sort of thing one "stumbles into". They don't get hired specifically for that, and it doesn't really transfer to more general developer jobs.


There's still lots of small-fish web development agencies who specifically hire PHP developers.

That's about it though, I think the web development industry is specifically tied to PHP because of their excessive dependence on WordPress, Drupal etc, this also produces developers who are overly specialised in niches using these platforms at the expense of general capability. Think back to the mid-2000's where there was a big difference between a JavaScript developer and a jQuery developer - while they both wrote JS the latter was generally incapable of using vanilla JS proficiently because their use of jQuery's abstractions as a crutch impaired their learning of the underlying fundamentals. A lot of "WordPress developers" are so heavily specialised in using WordPress they probably can't even remember how to write a vanilla PHP site.


Isn't Facebook running on HipHop PHP? What about Zalando, one of the biggest platforms out there? They started using Magento and tuning it

What's wrong with Laravel or Symfony?

I don't know if there's anything inherently wrong with them.

I'm just saying that I don't see any job listings for them as an interviewee, or see any resumes with them as an interviewer. In contrast to other technologies that HN or Reddit declare to be "dead" or "dying", yet actually seem to run the world with no serious disruption on the horizon yet.


Are you in the US? There are TONS of PHP jobs here in the UK (possibly second to JavaScript, although there are a lot of Java jobs too), and I hear that in general PHP is very popular in Europe, whereas Ruby is more popular in the US (some people use ruby here, but not many).

Laravel is not only fine, but one of the best frameworks I've ever used. It's like rails/django, but less opinionated in all the right ways (while still providing loads out of the box). I think PHP has a very bright future.


Where do you live? In the US there are a shitload of PHP and Laravel jobs.

Laravel and Symphony, in particular, have the terrible code smell of elongated toolchains, that are specific to the frameworks.

> php artisan serve # laravel

> symphony server:start # symphony

Same poor thinking that NodeJS introduced, albeit less offensively integrated.

If you need additional toolchains, you're not using PHP per se, but another meta-language. There's literally no good reason to do this other than to remove the concept of tradeoffs for a "we know better" or "don't worry about it". These frameworks have never added anything that I couldn't do simpler and faster, nor have they provided me with constructive guidance in the design or maintenance of a project.


Never met a Laravel developer who actually uses php artisan serve. Sounds like you're fighting windmills.

> Sounds like you're fighting windmills.

Every Laravel developer uses artisan to do something. They were highlighting the names of the magic binaries.

Of course, every Laravel howto starts with a quick guide telling you to use artisan serve, illustrating the point.


I can't speak for symphony, but that's just not the way it works in laravel. The "artisan serve" action is used when you want to make a quick demo (maybe). The actual deployment is in an apache server like everything else.

The rest of the actions that use artisan, for the most part, are for creating boilerplate code like database models or empty controllers quickly. They aren't a requirement to use the framework, but are faster and less error-prone than copy/pasting an old empty class file.

The last class of actions that call artisan are for things like cron jobs which you setup once and forget about. Their use case is pretty obvious once you read the manual.

> These frameworks have never added anything that I couldn't do simpler and faster, nor have they provided me with constructive guidance in the design or maintenance of a project.

That's nice to hear, but it's probably not true for the majority of people. The entire point for these projects is to allow programmers to create a rapid prototype for design purposes that can then be iteratively developed into a final product. If they don't make sense to you, maybe it's because you aren't working in that space, and not because the tools themselves are lacking.


You make a sweeping statement about a bubble and then demonstrate the edge of yours:

> The business world runs on Java, and .NET to a lesser extent.

Flip those.

> I just don't see any recruiter activity around PHP at all.

This is probably true. My own anecdote: I'm at a primarily-PHP SaaS provider in a major tech hub, and for the couple hires we've made in the last year all of our applicants with extensive PHP experience said we were the only PHP shop they'd talked to, many of them over a year into their job search.


> Flip those.

Nope. That's just incorrect. From Experian to JPMorgan Chase to Cambia Health to Amazon, Java is the typical case for every project. Look at stream processing tools at netflix via any given youtube presentation about stream processing. There are entire tooling segments where .NET is absent, despite their quality tools that run on Windows. Nobody trusts Windows by default and this has mortally wounded .NET


Having done a lot of .NET programming at JP Morgan Chase, allow me this Marshall McLuhan in Annie Hall moment ...

I have no idea which language is more popular, but I can certainly list 1,000+ companies including the majority of the Fortune 500 who use .NET in the enterprise.


I have worked for all the companies mentioned, of course. Having done a lot of Java programming at JP Morgan Chase, I can confidently say that Java far outstrips .NET usage. Orders of magnitude.

And I can say the opposite is true at Credit Suisse and the Royal Bank of Canada and WalMart and Toyota and Chevron and AT&T ...

What of it.


Which one is more popular depends a lot on which country you're in, and sometimes even where in that country.

Writing with PHP is better than ever... and getting better and better.

And... you don't need too worry too much about the server, or the request lifecycle, or networking... you just write your app, in a language which is, in my opinion, going in the right direction with a stronger slant towards OOP and types.

Of course it's still entirely possible to write garbage PHP code... but it's possible to write garbage in anything.

I'm increasingly proud to say I'm a PHP developer; it still gets a lot of bad commentary but it all tends to be based on historical stigmas which are increasingly untrue. Yet all the original benefits are still here, and the language itself is going from strength to strength...


My issue with modern PHP is that it's essentially becoming Java. And with the JVM and the Java ecosystem, what is the compelling reason to not just pick Java at this point? With Java you are basically writing exactly what you would be writing with PHP, except with more language features and the ability to opt into other languages on the JVM like Kotlin and Scala.

The modern additions are fantastic for projects and teams that have a specific need to stay on PHP. I still work on projects with PHP and am thankful it has so many improvements. But in its current form and direction, I'm not sure how it has not become simply a little bit worse version of Java.


Interesting analogy, performance wise PHP has made impressive progress. On par with node and the JVM. But Java code specifically is just so bloated. And then there is the worker-per-request model in PHP - All resources isolated to a worker and cleanup on exit. This avoids global garbage collection freezes by design. Something you would get otherwise only from Elixir/Erlang natively. Compared to the JVM that allows PHP applications to scale vertically to any amount of RAM/CPU, and horizontally to any amount of machines. If you let me free choices I'll do Elixir all day long. But pressed on Java vs. PHP for a web app it's PHP for sure.

"On par with node" wow looks fairly close "on par with JVM" thats a big stretch

Fun stuff here is that PHP hipsters currently gravitate towards node like runtime models. It isn't really eating the platform right now, but I see it as a risk.

I don't get it. Java is bloated but PHP isn't?? PHP has been doing its best since 5.0 to become a Java clone.

Have you ever tried building, deploying and maintaining Java? There is more to a language than the syntax

I have. And honestly, with modern, professional PHP development, most of us are not just FTP'ing PHP code to our shared host to deploy. So realistically, we are dealing with some of that deployment complexity regardless.

The modern Java ecosystem has tooling like Maven and Gradle. IDE support and static analysis in Java is more advanced as well.

As I said above, the additions are fantastic and I think they have absolutely improved the PHP experience for projects where PHP is required. But for new projects, I just do not see deploying PHP vs deploying Java with modern tooling as holding up like it may have 7-10 years ago.


I agree that once you get a certain size of application, you effectively reduce the complexity of deployment to a small portion of the overall work. In those cases, something like Java is probably appropriate. In fact, most companies leave Ruby/PHP for Java service once they mature.

I was more referring to your statement of using Java over PHP. PHP's syntax may be approaching something like Java, but the differences between the languages are still so vast, that they are only similar in syntax.


I'm not one to proselytize since I use a handful of languages every day, but when my Java hat is on, I double click a build target, my software is tested, built, deployed side-by-side with my current production build.

New users are automatically pushed to the new build, and users with existing sessions remain on the previous build. When I undeploy the previous build, the rest of the users start seeing the new build as well.

That's all out of the box with small config tweaks for our environment. It is truly torturous.


What's your setup?

Grails / Tomcat

Java is killing itself at a rate of 6 months. They removed javapackager, which means the official tool to build releases is missing from the LTS version. The EE ecosystem is collapsing thanks to Oracle opposing the Eclipse Foundation, making the quest to build enterprise applications challenging due to namespace collisions and overrides, because of modularisation.

PHP is on this aspect still strong and you can still choose your weapon of choice to build whatever you want and not being hostage of a company.

The only missing part is a good private composer repository for companies who don't release source code.


You can push libraries privately to GitHub and use with with composer directly, no packagist or anything else required.[0]

[0]: https://getcomposer.org/doc/05-repositories.md


It looks like Packagist has a private commercial offering: https://packagist.com/

And it even looks like the code for Packagist.org is open source, although not meant for self-hosting as there is no docs, support or BC compatibility guarantee: https://github.com/composer/packagist


> what is the compelling reason to not just pick Java at this point?

Oracle.


Except PHP is not Java, and it never can be.

What is PHP's multithreading model again? Hotspot VM? NIO?

I'm sure someone will chime in and cite something similar in PHP, but the comparison will be laughable in reality.


I'm not a concurrency expert (haven't had to do much high-performance stuff), but php does have coroutines like go's --if you use swoole, the performance is actually higher than node in some benchmarks and other multi-threaded / parallel programming paradigms, which comforts me to know that if I have the use case it's there, so I don't necessarily need to drop everything and pick up rust or java or go or another language w/ native concurrency models.

Not saying php is better, there's definitely reasons using rust, elixir, et al would be a better decision for scalability/etc... Just saying it isn't as far off from java, and it's getting JIT I believe in 8.0 (tentatively), whether that improves speed/proficiency is yet to be determined.

That said, I've been a laravel dev since 2013, getting a little bored, so have been branching out and toying w/ other things like clojure, elixir, rust, and node.js for backends to web/mobile apps. Though, laravel is easiest/fastest most of the time to get a project completed by myself.


In my experience Clojure with Luminus is the quickest for getting something up and running. No brittle ORM to deal with - just HugSQL for turning raw SQL into functions.

Coroutines do not mean that you get parallel execution. Concurrency is not the same as parallelization.

If PHP does not have JIT, then it's nowhere near the speed of Java. Even if it did, Java would likely beat it significantly. I would encourage you to read about Java's Hotspot VM and its adaptive optimizations.


Multithreading is not strictly parallelism, typical discussions of multithreading regard concurrency, and multithreading is what you initially asked about. PHP 7.4 will ship with a JIT as an experimental feature and PHP 8 will ship with it built in standard.

Multithreading in Java means parallelism, which is what I was originally asking about.

You're confused. Nowhere did I claim that multithreading always means parrelalism.


>What is PHP's multithreading model again

Since it's inception, the PHP implementation hasn't been threadsafe and since, the way of doing paralellism has been process forking. Later iterations where released with support for long-lived processes and threads but it's still not officially "stable" since again, historically the model of process forking made the ecosystem take for granted non-memory safety.

On the other hand, at least since the last time I was doing Java, paralellism is done via multithreading. Sure, there must be someone doing some else out there, but relevant frameworks like Spring work by making 1 thread by http request.

IMHO the right way of dealing with concurrency is the Node way. But comparing the PHP vs Java y think the PHP way is better. In small-medium scale the Java way is obviously more performant. The problem is when you scale to more instances. The PHP way of immutable processes really makes vertical scalling easier.


PHP scales better than Java? Java is only suited for small to medium scale? That's absurd and you are completely wrong.

Java web servers are multithreaded. Java has JIT. Java has a Hotspot VM with JIT optimizations at runtime.

This is why companies like Google and Amazon run their stacks on Java. It scales. Facebook had to write their own fork of PHP due to performance issues.


>Java is only suited for small to medium scale?

Never said that. What I said was that in the small to medium scale Java was obviously more performant because of the persistent instance & multithreaded model. But beyond that it really is no longer true. The immutable "shared nothing" process forking model of PHP scales horizontally very easily.

>Java web servers are multithreaded

this really is a disadvantage when scalling. The default linux thread stack is 1024k for 64-bit VMs, can't find what's the minium if you tweak it enough. You can see how bad that scalles to thousands of concurrent requests.

And then there's containerization and microservices, where each instance needs a full JVM.

>This is why companies like Google and Amazon run their stacks on Java

You can make anything scale with Google or Amazon budgets.

Again, just listing some pros and cons of both approaches, both of which I think are not even the best.


You don't seem to understand the basics of how Java web containers work. The thread stack size is irrelevant in most cases. You're going to be using a thread pooled server anyway to handle requests. Conceptually this is no different than using a forked model. You just use a pool of threads instead of processes.

Are you telling me that you run a process pool of thousands of PHP instances on a single machine? I hope not.

Your notion that forked = better is outdated. Running processes has overhead, even with read only shared mem. Micro processes are the way to go, and are being embraced by newer languages. You get min mem and context switching overhead, along with the parallelization of running on multiple cores.

Even so, threads are still going to be lighter weight than forking new "heavy weight" (non micro) processes.

And this doesn't even get into the more efficient compilation. PHP has no JIT yet. There's overhead for type inference. Etc etc


>Your notion that forked = better is outdated.

You're beating a strawman here. Nowhere did I make the claim that it was better. I even said multithreading is more performant. The only claim I make is that immutable and shared nothing model of PHP servers makes horizontal scalling more straightforward.

>You're going to be using a thread pooled server anyway to handle requests

That doesn't take away the fact that n parallel requests will require n threads.

>And this doesn't even get into the more efficient compilation. PHP has no JIT yet. There's overhead for type inference. Etc etc

I don't make any claims here either. Of course Java is faster here. My point was specifically about which model of concurrency and paralellism is better for server IO.


>That doesn't take away the fact that n parallel requests will require n threads.

What's your point? In PHP's model, n requests will take n processes. There's no event loop in PHP.

The forked model has nothing to do with making scaling horizontally more straightforward. In either scenario, you'll end up running a different process on another machine once you exhaust your resources.


The funny thing is, I don’t like java because of all of the historical problems and reputation it has. And I’m a PHP dev.

I really do need to get over all of that and give it another shot.


Even the nature of server-side PHP is bad. Running the script like an executable and using opcache on better case is no good. Also it is not uncommon to upload a php shell using some crappy upload.php forgotten script... Come on, it's Personal HomePage language - you shouldn't do anything bigger than your home page in it.

One of the main takeaways I got from the original Fractal of Bad Design post was the myriad of inconsistencies in both representation and execution of code. This was barely touched upon, mostly this post focused on how PHP has added features and ecosystem. But then so has Javascript.

Unfortunately this is true and it can't be changed, the functions are named and parameters are soemtimes inconsistent like strpos and str_replace, I would have to use the docs all the time if my IDE wouldn't show me the param names.

But after you get productive with PHP there is no feature that I think I am missing from other similar languages.


Features that I miss in PHP:

- expressive type system with generics, union types, literal types, basically TypeScript. I can say "this function returns a string" or "this function returns an array", but not "this function returns an array of strings".

- specialized collection/hashmap data structures with good support across third-party libraries. Having one array() structure acting as both a sequence and an associative array at the same time is awful.

- a templating solution similar to JSX. I am spoiled by TypeScript's ability to typecheck my HTML views along with other code.


It looks like Facebook had your exact problem; you want Hack:

https://hacklang.org

It's based on PHP, but adds:

Expressive type system with generics:

https://docs.hhvm.com/hack/types/generic-types

Specialized collections: vec, dict, keyset

https://docs.hhvm.com/hack/types/arrays

Templating solution similar to JSX: XHP

https://docs.hhvm.com/hack/XHP/some-basics


I'm aware of Hack and it's quite nice, but I can't use it because a) my coworkers are … less open to new ideas … and will rightfully resist a "whole new language", whereas mgmt will see it as an attempt at "job security", and b) the biggest use-case for generics is third-party libraries (e.g. [0], [1], [2], [3]) which will never add support if this is not a core language feature.

[0]: https://github.com/doctrine/collections

[1]: https://github.com/schmittjoh/php-option

[2]: https://github.com/schmittjoh/php-collection

[3]: https://github.com/widmogrod/php-functional


I am not trying to say PHP > TS, just wanted to let you know in case you still work with PHP codebase that you can get good enough type checks with PHPDoc, here is a good example for the case you mentioned , in Intellij the built in linter will mark as warnings when you use types wrong https://i.imgur.com/NqlAsTd.png (zoom a bit out and sorry for the bad crop)

About the array issue don't we have same situation with JS and TS where you don't have dictionaries or hashmaps in the standard library and you have to use array or object ?

I like JSX too, maybe some PHP template would be made to copy JSX , but not all ages need to be that interactive and not all PHP code is rendering HTML, my current project uses angular1 for the frontend (it was something already created so there was no debate what tool to be used where I could have voiced an opinion).

As a personal opinion I prefer react to angular because I don't like the angular magic compile stuff, I like that react components are JS functions and I can breakpoint into a render functions. I also done some side toy projects with TS, I like it and I hope it gets more popular so new projects would use it but I am worried that we could get a wave of front end languages and we will not have a standard great language but many non standard languages.


IntelliJ will detect cases like that, yes. But it is difficult and slow to get IntelliJ to inspect your whole project like `tsc` does. With PHPStan or such tools you can do that more easily, but they still have interop problems due to non-standard annotation syntax. Having native support for such type expressions would be much better.

ES6 has Map and Array, which are perfectly sufficient and distinguishable from each other. PHP core only has array() which tries to do everything. You can use array() to build a collection or an associative array and you cannot force it to only behave as one of those. Even Zend's PHP certification contains questions about what happens if you try to push a value into an array that uses associative keys. This is a joke.

I prefer React over Angular as well, but interactivity was not on my list of goals. I want a template syntax that combines valid markup, escaping by default, and TSX-style typechecking. Basically, I want XHP [0]. There is no other template engine for PHP that validates "values passed into this template" against "values used in this template" like TSX can, and no engine that ensures you're generating valid XML/HTML markup. I certainly agree that this is far less important than powerful types, but hey, one can dream :)

[0]: https://github.com/hhvm/xhp-lib


>ES6 has Map and Array,

Bue ES6 is new, I never seen APIs that use Map , I often had to use an Object as dictionary and had to Google how to properly do it not to get extra keys and values from the Object.prototype.

I am not trying to say that PHP is better then TS, but as far as type safety my PHP code with PHPDoc is better type checked then JS code with JSDoc (we are using ES5).

I don't have experience with PHP rendering, but I assume you only have to escape unsafe input, don't have to escape markuup, have you tried twig, is it not safe https://twig.symfony.com/doc/2.x/filters/escape.html ?

I admit I like rendering with react, but I admit that reading a twig template is much simpler then reading JSX code (but I am condemned to use angular :-( ).


It can be changed.

You have some syntax to opt into a later release (e.g. doing `<?php(version=8)` at the start of a script.

In a major release, you then get rid of a load of cruft.


> You have some syntax to opt into a later release (e.g. doing `<?php(version=8)` at the start of a script.

imagine the exponential complexity as old behaviours need to be kept around for various levels of opting in.


I would see it as javascript's strict mode, and I think most devs would ok with a binary switch.

The only fear I'd have is a lack of big entity committed to PHP. In the heydays there was Yahoo, facebook and other giant companies relying on PHP and guaranteeing that there would be enough man power to weather any type of changes. Now I wonder how many people are left to push through breaking changes and rewrite/modernize the libraries and the ecosystem.


PHP already has a strict mode as well. It's pretty hard to imagine every developer typing in a long block of compatibility switches at the top of every file and then the mental load of maintaining a code base with some of those on and off.

There's already been a degree of that with php.ini flags, and some of the behaviours available via those flags have been deprecated then removed over a period of years. It's not impossible. Yes, it's complex, but the process for dealing with that complexity has already existed and worked out ... relatively smoothly. The bigger issue is getting people to upgrade - I'm still dealing with a couple of projects - one started in 2017 - that are on PHP 5.6.

That's why you want to do it on a per file basis, not on a per interpreter basis, which allows a project to incrementally move.

You also want a single version, not a gigantic pile of things to opt in to.


The complexity still has to exist somewhere, right? By avoiding this, they're just keeping it in all the developers' heads, rather than a legacy mode in the compiler.

I'm not sure that's the wrong decision, but it's not a great one, either. Too much complexity in the implementation can kill the project. Too much complexity in the language can kill a person's hope of learning it.


Many complaints are about the PHP standard libraries and not about the language itself, so you can learn the language just fine and just don't learn the old deprecated functions at all unless you hit such a function in a codebase and tehn you research it. . Is not equivalent to compare PHP+ standard library with JS core , PHP included function to read and write files, streams, databases,json,XML, run executables(if enabled), where in JS or other languages most of this functions are not standard.

The libraries can also be treated in a similar manner.

Named parameters would be nice.

And JavaScript is the best language in the world (with TypeScript).

It's sad how many people think I'm crazy when I say this. No other language feels as good as writing JS with ES6+ features.

Gradual typing (that you can opt-out from) makes for a smooth prototype-to-production experience. Wish more languages supported it.

The thing that matters is language consistency... A language with a pure clean vision of itself in which the programmer can guess at syntax because they understand the general syntax principles to which the language adheres. Nothing here says PHP has been fixed in this regard.

Python made the big leap and fixed some huge problems when it went to python 3 - yes it's migration approach was a total fail, but it further cleaned up what was and already clean and consistent language.

The only thing that would have really interested me in this post would have been to hear that PHP had been cleaned up into a consistent syntax, but that's not what this article says.


I've been coding in PHP for almost 20 years now. I think I can count on one hand the number of times where I have had an issue regarding inconsistent function signatures. It becomes second nature, and if I forget, the documentation is available online or in worst case built into my IDE.

I can understand why people make this into such a pain point, but quite frankly it isn't for anyone who works day in day out with PHP.


23 years here (php/fi in jan '96) and I probably hit the 'parameter order' issue more than you. I still need to look param order stuff multiple times per year. Normally I can get it in the IDE, but doing remote vim stuff, for example, I need to look it up.

Yes, it's technically a non-zero problem. I get it. Having spent several years in the Java/Spring world, the classic ASP world, and the Perl world... they all have problems, both with the languages and the ecosystems. There will always be people who will throw out Rust or Go or Erlang as 'better' by some metric.

For the types of projects I work on, the modern PHP stacks of the last 5-6 years are all probably the best ROI. Colleagues/friends are running medium-sized SaaS on Rails, and it works, but we compare headaches sometimes, and it's not carefree in the Rails world. There's issues there. Regardless of whether your language is 'clean' or 'discoverable', the rest of the ecosystem can still present problems.


Since you mentioned Perl, I wonder if you've tried Mojolicious at all and what you think of it? I've found it pretty nice to work in, and easily scalable to small and large projects.

That said, I don't have is a lot of experience with other frameworks in other languages to compare it to, so I don't exactly know how it compares.


That's what really gets me.

Anyone that works with PHP on a daily basis very quickly gets used to some of the naming differences or inconsistent signatures. Anyone that works with PHP rarely is almost assuredly going to have to look it up regardless of how inconsistent it is. (do people really guess at function names, signatures, and return values in other languages!? I've guessed that they exist, but I don't ever think i've tried something without first checking the docs just to see about any surprises or differences)

Consistency is nice to have, but it's pretty far down the list of requirements in my opinion. If it's different for some, I can see how they wouldn't like PHP, but calling for it to "clean up" it's syntax in a giant "python-3-esque" move seem really misguided. People who program in PHP regularly don't really mind the warts, and the language has improved significantly in areas that it's users found most important. Types slowly working their way into the language, easy closures, traits, nice new operators, and the massive speed and memory usage improvements have all been very welcome improvements that have made me more productive in the language.

The time spent on "cleaning up" the standard library would be a welcome change by most, but it wouldn't really have any material impact for me or any of the other PHP devs I know.


For a while it was popular to just create your own functions with your own naming convention and parameter order, easy to do and you have whatever order is sane for you. Lots of frameworks around now so you don't even have to do that any more.

See, I code php very rarely, I review php code a bit more often, and I stumble upon these inconsistencies all the time. So because you got used to something bad doesn't mean it's not bad.

That would break too much things and the benefits will not be enough. They could add some new things, deprecated the old things and keep them all but then you get a manual twice as big. All the changes in PHP feel pragmatic, like better SQL support, better cryptography support, better defaults, better performance and less on cool looking syntax or latest cool features.

IMO pragmatic is good, especially when you have to use an existing code base and you have to upgrade it to the latest supported version you don't want a Python 3 migration story(I migrated a medium project to latest version and the only problem was a cryptographic function that was used to generate some random looking strings that was deprecated, I replaced with the new safer function and done , my project is now compatible with the older and the new version).


I don't disagree with your points -- but then it turns out that PHP is still the same old crappy language it was ten years ago.

Is that and more, I mean everyone uses classes and namespaces now and structures code better so there is this improvement. Projects use autoloaders now and things again are better.

Have a look for example http://image.intervention.io/getting_started/installation how you would resize an image if you used a framework, it is much different then you would see in a code that was written 20 years ago.


My point was, people can still shoot themselves in the foot if they read an old tutorial. This should not be possible in newer versions. That would be a true improvement in my eyes.

But then that means breaking backwards compatibility, stranding huge parts of the internet on older versions, splitting the community into "pre-massive-change" and "post-massive-change", and a LOT of work by both PHP maintainers and "users" for what will end up being a marginal increase in dev happiness and practically zero material benefit for anyone.

And that still doesn't solve the problem of bad blog posts... You can't control what others write about the language, and if someone writes some posts or has a website with bad information, the maintainers of the language can't "fix" that. The best they can do is what they already do, make sure the PHP documentation is among the best and most approachable of the languages that I've used.


It is a good point but it is a big disadvantage for the people that need the backward compatibility, is the same issue with C++ or other similar old languages that keep the backward compatibility so old code continues to work.

Though if you work on a new project or existing project that uses a framework you will not even need to do the bad search queries like "how to insert an user in a mysql table", the framework is forcing you to use the correct/safe patterns.

Most beginning level tutorials are super simplified and are not following the correct patterns, like they don't check for errors, don't clean user input etc.


You mean to say that namespaces and classes are an improvement?

Yes, you mean you want everything in a global space, you have then issues where 2 dependencies define the same type named "Task" and on dev machine a different Task is initialized then on production (it happened to me when working on an old code base that was not using namespaces).

If you are an anti OOP person then I would prefer not to debate here religions.


> Python made the big leap and fixed some huge problems when it went to python 3 - yes it's migration approach was a total fail, but it further cleaned up what was and already clean and consistent language.

People keep saying it was a huge failure, but honestly, I don't see how it was supposed to be done better otherwise. Either you make breaking changes that will impact your entire ecosystem or you don't and live with the same cruft from 20 years ago.


Rust did it with its "edition" system, where you can freely mix and match modules from the 2015 edition with modules from the 2018 edition. Unfortunately, in the Python 2 to Python 3 transition a fundamental data type (strings) changed, which would make freely mixing Python 2 and Python 3 code much harder.

In retrospect, for me many of the problems would have been fixed it they'd wrapped everything in one release, like gcc with the -std flag.

Then once someone had (say) python 2. 6 I'd know they also have python 3.2, and I wouldn't have to figure out that name of the executable to call, it would just be python, with (perhaps) either a command line option or a comment at the top of the file.


> The thing that matters is language consistency.

To be fair, we are talking about standard library consistency and not language consistency. PHP is a consistent language but it's standard library is very low-level. In Python, you don't call the mysql C library functions directly, you use an object-oriented abstraction. In PHP, you can call those mysql C library functions directly or you can use an object-oriented abstraction.


That's irrelevant. When talking about language consistency, we should also be including the language's standard library.

The problem is that PHP wasn't designed as language-first but as a tool to make web development more accessible. Hence the acronym for "Personal HomePage". PHP was merely a native interface to modules written in C (e.g. MySQL), with the interface hosted in a simplified version of Perl.

The draw of PHP was that you didn't need the CGI bin, and it was easy to deploy with Apache.

Nowadays, the deployment issue has long been solved. No one should choose PHP if they have a choice as there numerous languages better designed, more performant, and more generalized than to just web dev.

If you are still writing PHP in 2019, you are either very unfortunate or just very lazy.


> That's irrelevant. When talking about language consistency, we should also be including the language's standard library.

As you said, PHP was merely an interface to (many already existing) modules written in C. When people complain about mysql_real_escape_string() in PHP they don't realize that that is the actual name of the function in the MySQL C API. Same with the image functions (imagemagik). And so on. Some are named directly after the corresponding C standard library function.

This was actually part of the huge success of PHP -- it made available, for the web developer, a huge library of existing open source technology. This did not exist, in a scripting language, before PHP. The open source community wasn't as large.

But PHP does have high-level abstractions and, like with other languages, you would also use a framework that has high-level abstractions.

If you compare PHP to JavaScript, PHP's standard library is far superior. But it's a ridiculous comparison there as well.

> The problem is that PHP wasn't designed as language-first but a tool to make web development more accessible.

Yes, but all the ways that PHP as-a-language were less than ideal most of those have been solved now. So unless you're complaining about the standard library, there isn't much left.

> Nowadays, the deployment issue has long been solved. No one should choose PHP if they have a choice as there numerous languages better designed, more performant, and more generalized than to just web dev.

Nowadays there really just isn't that much difference in design or performance between PHP and the majority of languages you would suggest.


Genuine question, because I do not know the answer. Does it support:

Lexical scoping

Coroutines

Generators

Decorators

Generic type containers

A functional API (e.g. something like Java 8 streams)

An extensive selection of data structures (collections) included in the standard lib

?


> Lexical scoping

Yes.

> Coroutines

No.

> Generators

Yes.

> Decorators

No.

> Generic type containers

In progress. But also PHP has dynamic/weak typing and static/strong typing so this isn't strictly necessary.

> A functional API (e.g. something like Java 8 streams)

Available as a 3rd party library.

> An extensive selection of data structures (collections) included in the standard lib

https://www.php.net/manual/en/book.spl.php


Thanks for the thoughtful response. But based on your answers, PHP does lag significantly behind other modern languages. FYI the SPL you linked is quite meager compared to languages like Python and Java.

My opinion remains unchanged. Using PHP in 2019 only puts you at a disadvantage when compared to the alternatives.


Honestly nobody uses the SPL. PHP's array type is more than powerful enough for the vast majority of data structure tasks and the standard library has functions for treating it as a stack, a list, etc.

Coroutines are not necessary in PHP. In fact, the share nothing architecture of the LAMP stack is one of it's advantages if that suits your needs.

The setup of a Java web stack alone is painful enough to make PHP a viable option in comparison.


Thanks. Again, I am asking out of ignorance:

What is PHP's concurrency model? Is it still a forked process pool via something like PHP-FPM, or has it changed?

Does the VM enforce a GIL? I'm assuming there is some kind of threading API?

Can you run an event loop using epoll, and is the standard library well supported in that execution model?

FYI, I was a PHP developer from 2003-2011. I did enjoy it back then. I never bought into the Rails hype at the time, opting instead for copycats like Yii and CI.

But I was ignorant. Honestly, after switching to Python for web dev, I saw no reason to ever return. Since then, I've dropped web dev altogether, and I now work in C++, Java, and Python on a daily basis.

It may be the nature of the work, but I still cringe at the thought of using PHP again after learning how capable other general purpose languages are. From a CS point of view, working in PHP just isn't very interesting... or pleasant.


> What is PHP's concurrency model? Is it still a forked process pool via something like PHP-FPM, or has it changed? > Does the VM enforce a GIL? I'm assuming there is some kind of threading API?

As far as I'm aware PHP is still mostly run PHP-FPM. It also does have a threading API: https://www.php.net/manual/en/class.thread.php

> But I was ignorant. Honestly, after switching to Python for web dev, I saw no reason to ever return. Since then, I've dropped web dev altogether, and I now work in C++, Java, and Python on a daily basis.

I haven't done PHP seriously in a very long time. I currently work in C# and ASP.NET for web and I do C++, Python, and JavaScript. Personally, I'm doing work in Python right now and I don't enjoy it very much -- I'd much rather work in PHP for web development over Python. I prefer a good strongly typed language.

> I still cringe at the thought of using PHP again after learning how capable other general purpose languages are. From a CS point of view, working in PHP just isn't very interesting... or pleasant.

I don't know. PHP has Lambdas. It has generators. It was strong typing. From a CS perspective, there isn't much PHP does not have for the purposes of web development. It's limitations, in my opinion, mostly come from being a dynamic scripting language but those same issues befall Python and Nodejs as well.

If I had to code in PHP again, my code wouldn't look much different from my code in any other language.


That's fair.

I think if you're building CRUD apps over and over again, then yeah, there isn't too much difference.

But if you're building a web service with more complicated business logic and you need more control over your concurrency model, then other languages look more appealing.

And it looks like PHP doesn't have JIT yet, which is another huge mark against it.

So PHP is probably fine for passing params and rendering back HTML. But anything sitting in between that's more interesting should be built in something else.


> The thing that matters is language consistency... [...] Python made the big leap and fixed some huge problems when it went to python 3

And yet, here we are over a decade along and the Python project is still maintaining Python 2 and I still need to maintain a copy of Python 2 on my computer because of the number of actively maintained projects still using it. How many developer-hours that could have gone into doing something else have instead gone into this "language consistency" project?

At any point in the past 25 years someone could have forked PHP to clean the syntax up and accomplished the exact same thing -- and yet apparently nobody has seen the inconsistency as a big enough issue or time sink to do so. I would take that as prima facie evidence that this isn't nearly as important as you seem to think it is.

Meanwhile, one of the strengths of PHP in my opinion has been how carefully they have maintained and managed backward compatibility. While "move fast and break things" might be the new norm, there is still a huge contingent of developers and businesses that see value in slower, more considered change.


What are you talking about is just a syntax. Which is not an issue for a PHP dev nowadays. I am typing much more custom method names than vanilla PHP functions. And when I have, my IDE shows me the right syntax after a few keystrokes.

So, it's apparently a good reason to hate, but by no means a reason not to use PHP.


I often run into this argument - "inconsistent syntax", followed by zero proof. Then I wonder - is the person making the comment even using PHP or is the person behind the comment.. even capable programmer?

Yes, PHP has been "cleaned up" and you have always had the option to use clean, concise way of coding without language interfering or hindering you in any way.

There's no programming language out there that makes up for the sloppiness and inability of the person behind the screen.


Back in the PHP 3/4 days, a lot of related functions would have different argument orders.

str_replace(old, new) vs. stri_replace(new, old) kind of thing.


Here's the thing that always grates a little bit for me about these posts:

I don't have a choice.

I've worked at a couple of organisation where there are hundreds of thousands of lines of code written in PHP. It's been there for years. It does its job and - from a business perspective - it does its job pretty damn well. And I get paid to keep it ticking, and to improve it. Not to rewrite it to fit my personal tastes.

In my spare time I've played with Haskell, Rust, C, Lisp, assembly languages, and I enjoy them. I dearly miss some of the more functional aspects from these languages every time I write PHP.

I work with a large PHP codebase right now (amongst others) and while there are a great many technical benefits I could wring from it in another language, runtime, or environment, a lot of the changes needed to get there would be prolonged, painful, and would provide no noticeable business value.

I'm somewhat reminded of Python, where there is the concept of a "pythonic way" of doing things. There is very much a "PHP way" of doing things, a "${LANGUAGE} way" of doing things, and of course an "${ORG-SPECIFIC} way".

I'm also somewhat amused at Rails as a frequent comparison. I've also worked with Rails, and I hated it. It was quite some time ago, I'd probably enjoy it if I tried again. But I will try to remember in future that opinions formed from bad experiences need to be reviewed in light of the time elapsed since then, and my own personal/professional growth as well.

More generally, when I hear a developer (in my own office ;P) espousing the view that "${LANGUAGE} is garbage", I assign more meaning to the fact that they choose to make that statement than I do to any particular view of the language in question.


I've been using PHP semi-regularly since the late 90s. It's been empowering and infuriating.

The ecosystem is radically better than it used to be. Composer and the Packagist registry are as mature and dependable as npm, PyPI or RubyGems. (despite hours lost to my own namespace screwups). I'm also happy to see the Prettier-PHP project automating and enforcing code-style standards.

For whatever reason, I often feel clumsier after working on a PHP project. After working in other languages like JS or Python, I tend to feel like I've leveled-up my skills.

One thing I wish PHP would address is the inconsistency in its map-filter-reduce functions -- their argument-order doesn't match (array, callback) vs. (callback, array):

    array_filter($arr, $fn)
    array_map($fn, $arr)
    array_reduce($arr, $fn)
The amount of cognitive overhead I've wasted on those is ridiculous.

- https://packagist.org/

- https://github.com/prettier/plugin-php


I hear this complaint a lot but I find those argument orders completely intuitive.

You filter (1) an array with (2) a function. You map (1) a function over (2) an array. You reduce (1) an array with (2) a function.

It follows exactly what I'm thinking when I type it. To reverse the orders would be, what? "Mapping an array with a function?" "Filter a function on an array?"


Why is "map an array with a function" unintuitive but "filter an array with a function" isn't?

This sounds a lot like the arguments used in favor of Perl 5 sigils.

Precisely. Not sure what the fuss is about.

Laravel has Collection class that wraps arrays - as such you can do `(new Collection([your array]))->filter(function(){})` or `(new Collection([your array]))->map(function(){})`. It also adds other helper methods. I guess Symfony has something similar

Reference: https://laravel.com/docs/5.8/collections


Or collect([your array]). I love Laravel collections.

From a performance perspective, you likely want to do those with `foreach` anyway in PHP. Especially when the array function is fed a closure. I know it is not as interesting as using those functions, but because of PHP internals, `foreach` is almost always preferred.

https://stackoverflow.com/questions/18144782/performance-of-...


Infuriating? I'm not here to defend php but even when I do agree that inconsistencies are not nice, nothing stop you of creating your own wrapper for these functions.

Infuriating? really?


Yes, it is really infuriating that PHP literally cannot commit to any coding standards whatsoever for its standard library. Even if you choose to write your own wrappers, it doesn't change other people's code which you have to read. It's idiotic that the developers of PHP didn't take 5 seconds to consult their other functions before adding new ones with the arguments reversed, and it is totally appropriate to feel angry at them for their unconscionable shortsightedness.

Back when I wrote PHP, the solution was to use an editor which shows you functions arguments after you type the open bracket.

As far as I'm concerned the bridges have burned a long time ago and I definitely can't see myself giving PHP a second chance. That being said, if I'm wrong and PHP has really managed to become a decent language (or at least something that's not completely insane) its defenders should focus on actually showing what modern PHP code looks like.

Is performance that much of a big deal for most people? In a world where Ruby on Rail exists I find that hard to believe. Server are cheaper and vastly more powerful now than in PHP's infancy, I'm sure that for the vast majority of use cases PHP's performance (whatever it is) is good enough.

The infamous "Fractal of Bad Design" wasn't about that, it was about the ridiculously inconsistent and error-prone API, the insane defaults, the counter-intuitive behaviour of '==', the headless chicken development roadmap where maintainers would add features because they were popular in other programing languages without trying to figure out if they had their place in PHP,...

Surely a lot of this has turned into technical debt? Even assuming that "modern" PHP managed to come up with better ways to deal with all of this, I assume that these obsolete functions and operators still linger for backward compatibility? If so how do you avoid them?

Again, I personally don't really care, but if you want to win new converts who haven't been as scarred by PHP as I have been I think that's where you should focus your efforts. Maybe somebody should write a point-by-point rebuttal to the "fractal of bad design" article?


I was pretty anti-PHP before I worked for a multi-billion dollar company that was built on top of it. It's not a beautiful language, but it offers a lot of side benefits in terms of dev-ops, and tooling, and frameworks. As a company, the language was not something that held us back. The company moved really fast, and PHP was a large part a big part of why. In my career over the past 14 years I've done web work using ruby, python, C#, javascript, and Java. but that ugly PHP site was the one that impressed me the most. People moved fast in it, our tooling never held us back, everything just worked. It was the most utilitarian environment i've worked in. The first time I touched PHP, it was a spaghetti disaster... but today, next to python It's my go to language. It gets the job done faster, and it's maintainability is just fine. It really doesn't matter if sometimes things just look odd.

I have to echo this.

I worked on a data pipeline that was a mountain of PHP scripts bolted together with Bash and it was such a breeze to maintain. Using Symfony ensures that every command is well documented and consistent in design and use.

Something I never appreciated about PHP until recently is that character encoding is so much more robust in PHP than other languages. We were forced to replace our pipeline with Python because of a combination of "Eww, PHP" from new management and "data scientists use Python." Character encoding was a huge, unexpected annoyance.


Which version of Python? I ask because making fundamental changes to character encoding was the single most disruptive feature of the Python 2/Python 3 split.

> character encoding is so much more robust in PHP than other languages.

This is not what I expected -- my limited past experiences with anything outside of Latin-1 using PHP have been perplexing and not smooth (and I generally like PHP well enough). Can you elaborate on what features or approach can make things robust?


PHP doesn't care about your encoding. Therefore it's simpler to work with any encoding in it, because you're managing it manually.

Most of this would apply to Perl, as well. Which I can't fathom why Perl didn't easily beat out Python in the data science world. It's incredibly stable (version 5, that is), fast, and can just about rip apart and parse any raw data you have with ease. Python may "feel" newer, but there are only a few years age difference. Even Ruby isn't that much newer.

Tragically, Perl developed its "unreadable" reputation because it was the language du jour of the system admin/hacking world. The first time most people experienced Perl was by finding some crufty old script that glued a bunch of shell tools together haphazardly. Few developers today have actually seen what good, production Perl can look like.

No disrespect to the wonderful system admins of years past, but those guys were a different breed. They weren't programmers. But Perl still let them get their job done. Their unmaintainable messes caused a great deal of harm to Perl.


I maintain others Perl code and am no expert. Its our most use web tool and has been running for 10 years. I think Perl is different enough to confuse people who look at it (@,%,$) and it can make it hard to follow. I still have a little problems switching to it from other languages sometimes (do x unless y seems backward to me). I've also been told I write perl like a c programmer. Perl does have some beautiful parts though..

CPAN is great, but its hard sometimes when I just want to install something easy. It was the first great shared library and it shows its age a bit. Last time I ran it, it was compiling C code for some strange reason. We have trouble setting up shared perl environments, something we don'e have with python.

Biology has a lot of Perl code still, but it seems to moving to python.

Terrible code exists in many languages.


I appreciate you sharing this. The goal of my post was not to convince people to "switch to PHP right now", but rather to tell them you can do pretty cool things with it, and that it's actually fun to work in.

> ven assuming that "modern" PHP managed to come up with better ways to deal with all of this, I assume that these obsolete functions and operators still linger for backward compatibility? If so how do you avoid them?

I think the "path of least resistance" is important: developers are time-constrained, understanding-constrained, lazy (if they're virtuous), etc. There's a big incentive to do whatever is easiest/quickest.

When I last used PHP, about 5 years ago, there were OOP APIs cropping up to replace many of the standard global functions; namespaces had just been introduced; closures had become useful; frameworks like Symfony (and Drupal 8) were becoming established, rather than the old "plugin" approach of throwing around arbitrary code and hoping for the best; dependencies were being managed by composer; files could be autoloaded from sensible locations; testing frameworks like PHPUnit and PHPSpec had become best practice; etc.

Yet all of those things were opt-in and verbose. The path of least resistance was still:

    <html>
      <body>
        Hello <?php echo $_GET['name']; ?>
      </body>
    </html>
(For non-PHP programmers, this is appending a GET parameter straight into the page, which is an XSS vulnerability). Doing things "properly" took a great deal of effort and discipline.

Compare this to something like Java: it favours class-based OOP so much that even "hello world" needs a class. The path of least resistance is to do things "right" (from Java's perspective). Haskell's path of least resistance is simultaneously easier ("hello world" is just `main = putStrLn "hello world"`) and harder (`main` uses the `IO` type, whose API enforces certain conventions).

Deprecation warnings, linters, etc. can help with this; but PHP's only real strength is its installed base of code and developers; changing the language too much would throw away this advantage (akin to being a new language, see Python 3 and Perl 6); not changing it enough prevents the more serious and/or systemic issues from being dealt with.

I wish the language designers and users luck, but I'm really hoping to never use it again ;)


The $_GET/$_POST pattern is rare in modern applications (anything built in the last 5 years) and is rightly recognized as an antipattern. Similarly many of the older obsolete functions have been either removed or fallen out of fashion.

You are absolutely right that the path to this has been fixing the path of least resistance. Laravel and other frameworks have made it easy to get variables using their preferred methods (and automatically sanitizing input). Learning resources (tutorials, docs) utilize the OO functions and many of the older functions were deprecated and have been removed for years. If you look at one of the more infamous functions, mysql_real_escape_string (https://www.php.net/manual/en/function.mysql-real-escape-str...) that was removed entirely in PHP 7. If you look at the more modern mysqli, they've chosen to have both escape_string and real_escape string, but one is an alias to the other. Similarly, sane defaults have become the norm, especially since most developers are using containers or VMs/vagrant to program. The one major outstanding issue is the api naming is still inconsistent.

On a sidenote, the PHP docs are great with pages showing examples and notes talking about potential issues. When I switched to python I couldn't believe how bad the docs were in comparison.


To understand that, you have to take a closer look at its origins. For me, this talk by Rasmus Lerdorf (creator of PHP) was a real eye-opener: https://www.youtube.com/watch?v=SvEGwtgLtjA He mentions that what we now refer to as the "PHP language" was originally intended to be only the templating system, and you were supposed to write your business logic in a "real language" such as C. However, as PHP got more popular, bits and pieces were added until the "templating system" became a full-fledged language. Sounds like this happened more by chance than by design. And because you can't throw all of that out, it shows until today. You can introduce new features, but doing that in a way that stays (more or less) backwards compatible is difficult and forces compromises - see type declarations, which are actually just type hinting and of very limited use. So sure, PHP is wildly popular because of its "first mover" status, so it will probably stay with us for the foreseeable future, and working in it may have become more pleasant over the years thanks to better tooling, but it will unfortunately never be as pleasant as in other, more well-designed languages.

That's kinda the problem with any domain-specific language: it either requires a full language for support, or it becomes one (and generally not a very good one). Every language is an opinion about what things should be easy and what things are allowed to be hard.

I've got nothing against DSLs and template languages and such, but most of the ones I encounter make me sigh and say, "I know you thought it would be easier but it's just one more thing I have to figure out how to debug, without any of my usual debugging tools."


> what we now refer to as the "PHP language" was originally intended to be only the templating system, and you were supposed to write your business logic in a "real language" such as C

I did get a little perverse amusement at writing HTML files containing nothing other than single `<?php` element; where that PHP's job was to generate HTML; and it did so via a templating language (e.g. Twig or Smarty)...


You can't remove those old APIs without changing culture, and culture is really hard to change.

One thing that shocked me during my brief foray into PHP was how heavily popular PHP apps like WordPress rely on the filesystem. Want to move a site? Copy the database, and copy a bunch of files. It seems like there's a cultural expectation that applications run on a single server in your closet. Of course you don't have to write code this way... but people still do.


WordPress is NOT an example of modern PHP practices though. The amount of legacy insanity in WordPress is enough to make any sane dev cry...

Why was it shocking? PHP (originally) stood for "Personal Home Page" after all...

comparing a web page with a potential XSS vs a java 'hello world' (assuming console output) is a bit disingenuous, no?

<?php echo "hello world";

There - no XSS, no HTML, no class requirements.


I think you're confused. The PHP snippet was to demonstrate my point that:

- The path of least resistance in PHP is often directly at odds with the "proper" way of doing things (including many things listed in this article).

- This is important because PHP's intended domain is Web development, so this can easily cause security flaws.

- Any attempt to "fix" this example will inevitably make it longer, more complicated, harder to remember, etc.

Your PHP "hello world" does not demonstrate those problems, since it has no XSS or HTML, so it is a poor example.

After this demonstration, I abstracted to the more general concepts of "path of least resistance" and "'proper' ways to do things", irrespective of language or domain.

To clarify my meaning for these phrases, and to demonstrate how language designers can use the former to push the latter, I gave two examples: Java pushing its preferred approach of class-based OOP, by disallowing raw, top-level statements; and Haskell pushing its preferred approach of monadic I/O, by enforcing the type of `main` and restricting the available APIs. Notice that neither of those examples make the "proper" way easier (that can be very difficult, in general); instead they eliminate anything that's easier (like top-level statements), such that the "proper" way is the easiest thing that's left. In other words, Java's requirement that even "hello world" be wrapped in a class is a good thing for Java programmers, since allowing top-level statements like `System.out.println("hello world");` would undermine the principles of the language. This general argument is not specific to PHP, and certainly not a direct comparison to the XSS snippet.

After defining and demonstrating these general concepts, I then returned to the specific case of PHP, to point out how backwards-compatibility with its legacy of easy, insecure approaches undermines the attempts to improve the situation. In other words, the "proper" way to write PHP (at least, back when I used it) is to use OOP, namespaces, type hints, escaping of user input, etc. Yet the design of the PHP language discourages all of those, by providing easier alternatives which are "improper" (like in my XSS example); and removing those alternatives (in the same way that Java forbids top-level statements) would break almost all existing PHP projects and require the majority of PHP developers to change their habits; and doing so would eliminate PHP's main selling point (installed base and developer mindshare).

I hope that clarifies why the comparison is not disingenuous (i.e. because I'm not making the comparison that you claim).

If I were to make a comparison of that vulnerable PHP code against something else, it would need to be against a language which is primarily designed for Web development (to avoid being disingenuous), and it should be designed to make the "proper" approach the easiest. The Ur/Web language fits these criteria nicely, and (from a quick skim of the tutorial at http://www.expdev.net/urtutorial/step1.html ) the equivalent to that PHP would be:

    fun greet data = return <xml>
      <body>
        Hello {[data.name]}
      </body>
    </xml>
Not only will this will perform the correct escaping, it will also be a type error if another page tries linking to this one without giving a `name` parameter.

funny, because it's what React.js allows to do nowadays

The difference is React actually handles escaping properly. It won't just dump out raw HTML by default, so you won't have an XSS issue.

PHP, on the other hand, requires manual escaping with htmlentities() ... It is very, very error prone.


You are comparing a framework to a language though. Escaping in PHP is usually handled by the templating component, you don't go around writing htmlentities() everywhere.

If you're dealing with decade old code that uses no framework, you certainly do. PHP is, by default, a primitive templating language...

PHP comes with a Web framework built in (that's what things like `$_GET`, `$_POST`, `htmlentities`, etc. are). It is also a templating language, that's why we need to write `<?` at the start (to open a PHP tag).

Agreed, articles like these do absolutely nothing to address PHP's insane warts, some of which you mentioned.

That's not helpful. Laravel can objectively be the best web app framework in the world and I still won't touch it, because of PHP.

Predictability, minimum WTFs per minute, consistency, sane defaults -- these win over short-term convenience, every time.


For what it's worth, here's the source code of one of my personal side projects, written in PHP and Laravel: https://github.com/brendt/aggregate.stitcher.io

One of my old friends has been working with php since forever, we’ve teased him over the years.

Since then we’ve moved to a world where every program is web-based. I mean, even huge enterprise systems in healthcare run on some JavaScript MVVM framework and a web-backend in the cloud.

The truth is that php is more adapt at handling this than a lot of the stacks you see in enterprise. It’s really kind of silly, but I don’t think we’ll ever adopt php either exactly for its bad rep. But sometimes I wonder if we shouldn’t.


> [...] its defenders should focus on actually showing what modern PHP code looks like.

Laravel does this very well, not just by being a great framework but also in its ecosystem (Envoyer, Forge, Spark, Nova, Horizon, Socialite) and its documentation (https://laravel.com/docs/master).


Laravel has a Java-like problem of too many indirections, and has a really complex application model that breaks a lot of things. For that you gain an end of 00's quality templating system and ORM.

I understand that PHP developers love it. It's orders of magnitude better than doing everything by hand. But no, thanks.


Just out of curiosity. What type of comparable work are you doing and what languages/frameworks are you using? How do they compare?

I've created reasonably complex projects on Django (with late 00's capabilities), I've done things in Flask, Asp.Net, Java (with very out of date components), very simple things on Rails, and also used some non-OOP frameworks like snap, I've also used some newer templating systems. I have never created anything in Laravel, but I have done some maintenance.

Compared to Django and Rails, Laravel has those two problems I said. I don't think I ever saw a benefit of Laravel compared to them, except for the easy to deployment of PHP (that is a mixed bag anyway).

The ASP.Net and Java frameworks are so different that any comparison could join Django, Rails, and Laravel as a single point. Everything on those languages is more bureaucratic and stable, easier to compose more complex projects, but harder to create simpler ones.

Compared to snap (I've used very little of Yesod, but looks like it's alike here), the trio Laravel, Django, and Rails compose pages much better (it's a shame really since "compose" and FP go hand to hand, and I expect that to change in the future), but the FP frameworks are much better for creating data services.


If laravel is the best we have were fucked.

Laravel is fine for prototyping but it breaks backwards compat constantly, probably due to the massive amounts of over abstraction, not to mention layer upon layer of IOC hell.


Symfony is better at handling backward compatibility and managing deprecation.

Still over-engineered I guess but sometimes it means you won't have to go against the framework for some complicated tasks.


Can you share some of the BC breaking changes you've seen? I personally haven't seen any in quite a while, but I'm not using all parts of the framework.

Read the migration notes for the last few releases. Anything that requires you to change your code is a breaking change and the reason you can't skip versions.

Can you explain the IOC hell? isn't most IOC / Dependency Injection patterns suppose to help the software maintainability ?

I tend to think of these more as enabling modularity and convention-over-configuration (being Rails-y if you will) rather than maintainability.

Prior to Laravel, the PHP way was minimal indirection and simple execution flow. I think it was hard to do something something different with Laravel, and definitely hard to do it in a way that offers performance and security and any other good thing you might want in addition to pretty code.

One disadvantage IOC/DI carry in every language and particularly in PHP is difficulty with debugging. If you have a file of functions and a template that generates HTML you could just read through the code yourself or use prints, now it can be hard to know where to put the print when each page load may involve a couple dozen files.

That, I believe, is IOC hell. My belief is you get through it by learning the framework internals, which is a lot of work (especially if you also have to fit something like Wordpress, Angular, your family, or Photoshop in your mind as well).


Yes, they are supposed to.

The problem is that it gets taken to extremes when it's done at the framework level.

The pattern tends to encourage overly decoupled abstractions that are nigh impossible to wrap your head around.

Dependency injection is useful when you need to decouple for testing. Other than that it's rarely useful.

If your trying to decouple everything because "coupling is bad mmkay" your just cargo culting.

IOC is just anti OO. And I'm anti OO. But when you use IOC for every class yove got a huge fucking problem.

The only time I've seen IOC work well is across module boundaries in a system where modules were boundaries that could not be crossed without the IOC.

Within modules usual namespacing and new constructors were used liberally.


>I assume that these obsolete functions and operators still linger for backward compatibility? If so how do you avoid them?

This. If there isn't a linter that bombs out on those things that used to be standard PHP, modern PHP is a non-starter. There are too many bad examples out there that will make their way into modern code if you let them.


https://www.exakat.io/

https://github.com/phpstan/phpstan

https://github.com/phan/phan

Lots of great static analyzers to run in CI and during development to catch all kinds of issues.

Also, https://github.com/FriendsOfPhp/PHP-CS-Fixer to clean up code syntax (configurable rules, has good presets).


> its defenders should focus on actually showing what modern PHP code looks like

This is one of my personal side projects, written in PHP and Laravel: https://github.com/brendt/aggregate.stitcher.io

Here's a list of all OSS package we maintain at work: https://github.com/spatie


some very interesting stuff in there! Thanks for sharing!

Yeah, I've been burned too badly by PHP. There are languages I haven't done in years that I would go back to if there was a compelling need to.

PHP is not that language. Far to many sleepless late nights trying to clean up some security hole. PHP is like that abusive Ex that everyone says has changed. It may be true, in which case, good for PHP

But I won't be putting myself in that position again.


I've been burned by some language that create a poor developer experience with long compilation time and garbage collection.

Maybe V language (vlang.io) could pique your curiosity.


You can be burned by every program language if you dont know the in and outs. It all boils down to, pick the right language for the job and more important, know the language you choose.

Seems like to know PHP, though, you need to know all the history that the author has picked up by following the PHP space since forever. Which mysql functions are appropriate, etc. If knowing the language means "being a working programmer in 2010 so that you could gain a working knowledge of the old APIs and some context for the new ones" I'm out. Keep PHP, I'll move to a different language where knowing historical baggage isn't a prerequisite.

There are languages which have great design from the start though (like Clojure).

PHP, javascript are not them.

Probably that's the reason why Clojure tends to be in top of the "developer happiness" polls.


.... and the bottom of "jobs available".

Languages have foot guns. Most however don't default to being loaded and already pointed at your foot.

I did know PHP. I was actually pretty good at and wrote non-trival software in it. Even then the relationship was pretty abusive. Even when I was writing bug free code the author of a library I was using wasn't or a co-worker wasn't.

It may in fact be that PHP has improved to the point that the relationship isn't abusive anymore. But I'll never go back to find out. PHP and me were done years ago.


Saying that all programming languages are equally good is about as true as saying that all sorting algorithms are equally fast.

That i didnt say.

> Server are cheaper and vastly more powerful now than in PHP's infancy

Slightly off-topic, but I think that nowdays it's actually less of an argument than when PHP started becoming popular. The thing is, back in the days, statically typed languages were just bad and unproductive. Today, they are way better, and the fact that I can run my service on $3/month server with 900M of RAM and not think about the price tag at all is actually quite a decent argument to stay away from dynamic languages (but not the main one, tbh).


With more companies moving to virtualized hosts, I bet performance becomes a real consideration. With most services I've seen, you buy server capacity in doubling increments. So either your application fits into 2 vcores @ 2.2GB with 8GB or RAM, or you step up to 4 vcores and 16GB, with costs also doubling.

Good point! Let's not forget that, unlike the old days, it's kind of a standard to require redundancy and load-balancing from day 1, so not fitting machine's RAM hurts even more.

It's gotta be the easiest stateless system to get started with, right? It's decidedly not a BAD language anymore. It probably has some of the best tooling for said system as well. And it has a GIGANTIC community.

That's worth a lot to most people, I think?


Your comment reads as "I like ruby therefor php is dumb"

> Is performance that much of a big deal for most people? Yes obviously. Performance is important no matter the language.

> the counter-intuitive behaviour of '==' You should learn the languages type system instead of assuming it works how you think. Again this is true of every language.

> I assume that these obsolete functions and operators still linger for backward compatibility? If so how do you avoid them? The built in linter gives you a warning that its obsolete.

The inconsistent naming and arguments. Dumb defaults and thousands of functions in a global namespace is the real problem and there is no solution to it. Oh and calling functions is unacceptably slow, that they can and need to fix the rest of this is just I like my language better.


I haven't used Ruby in about a decade and I was never a fan. I used it as an example of a technology that managed to become popular despite abysmal performance. I think that's proof that in many situations, especially for web development, performance is a very secondary concern.

> You should learn the languages type system instead of assuming it works how you think. Again this is true of every language.

A good language should have good ergonomics. Criticism that `123 == "123foo"` is not reasonable cannot be brushed away by claiming that users should RTFM (although arguably in this case it's less an issue with == than "123foo" being implicitly cast into an integer).

Maybe this has been fixed and is no longer relevant though (I'm citing the Fractal of Bad Design page).


> Is performance that much of a big deal for most people?

For most people outside VC-funded startups, yes it is. It is also an environmental concern, imagine if 80% of the web was running on ruby.


Well if 80% of the web was running on ruby there wouldn't be any difference.

Most people don't understand that 99% of performance issues are not caused by language performance but by bad architecture and bad developers.

Always choose the best tool for the job, you rarely get to that scale and quality of software design that only the raw language performance is left to be optimized :)


There absolutely would be a difference. IME, people take this "performance is not a major concern when choosing a stack" thing a little too far and apply it too broadly, often without ever having benchmarked anything. When I can handle 300+ requests per second in one implementation and only 50 in another on the same hardware, that's going to be a big difference in costs that matters for everyone except fledgling businesses. I've seen 5-10x differences in performance between languages with none of it being attributable to anything the programmer did being suboptimal --just the language/standard libraries/runtime.

5x-10x differences only exist between statically compiled and dynamically compiled languages. The differences in performance between dynamic languages is marginal. As for Ruby it's now slightly faster than Python for most things except C-based numerics.

I agree with your costs argument, but my point is you can rarely blame the language. If we bring the frameworks in the discussion it gets even more complicated.

If you build a Rails or Laravel app in the same way you would build a Java app, the Rails/Laravel app will be dead slow. And I've seen that happen. But if you know what you're doing you with Rails/Laravel it will be a long time before you say: we should rewrite this in Go/Rust/Erlang.

The main criteria for me when choosing a tool for the job is: how well does the team know the tool? can they use it at full potential?

I've been involved in java project with 20k monthly cloud costs. Most of the workload is handled in the background by consumers that pull messages from RabbitMQ. I'm pretty sure I could rebuild that with any language while actually reducing the costs because the bottleneck is not the code but the architecture. Would it matter if I would rewrite it in Java instead pf Python or Ruby, in terms of performance, yes, if we need to consider other things, like speed of development, etc it gets complicated again. :)


Tbh most of it is wordpress, and that is not terribly inefficient.

I haven't touched wordpress in 8 years, but with old codebases you always inherit a lot of bad design decisions that always have an impact on general performance.

Maybe the wordpress guys have done a great job in rewriting the internals and cleaning things up in the last years, I wouldn't know, I don't follow their progress.



Your parent comment has a point about performance; I don't see why he is downvoted. Crystal is cool, but it is still immature in terms of ecosystem, the language could change, limited library support, and most importantly, not many great engineers. Particularly not outside of the valley.

Performance is a concern for many people, and this is somewhat overlooked because of the number of people here who work for companies where scaling is the primary concern. I think this is what he meant by people outside of VC-backed startups. I know of multiple companies that have had outrageous cloud-hosting bills and have had to hire fancy consultants to fix it.


I simply meant that Crystal lang features ultra high performance, and yet shares much of Rubys syntactical elegance. Much is built into the standard library and I have to ask what your experience with Crystal has been like so far? I find pretty much everything I need, and the easy FFI with C takes care of most of the rest (see the Mongo.cr wrapper for the C mongo driver, for example...)

I agree with that assessment. My experience has been reading a good bit into it. I considered learning it a few months ago, but wanted to focus on things that people were currently hiring for. Maybe at some point I will learn more, but I am a bit too broke right now to spend that much time on something that doesn't pay. I don't say that to be disparaging, it goes back to my point about it being immature and not having many engineers or companies using it.

despite it's pre 1.0 status it's arguably more production ready than php ever was/will-be etc.

I bet you rely on things written in PHP way more than you realize.

Exactly. See: Wikipedia, Facebook, WordPress, etc. People talk crap about PHP but it is a workhorse of the web.

indeed. this is largely legacy, but good luck changing that. I can't say that i miss it much, but then I don't work for either of these 2 entities. I'm familiar with what you are speaking about, so I don't think the lack of respect stems from a general ignorance of what you are referring to. It's rather people who have interacted with PHP in the past and didn't enjoy the experience.

That's a fair point.

I'm familiar with the usage stats on wordpress, lol. I can't say that this is a good thing, but if it suits your needs, have at it.

I see no reason to start any greenfield project in 2019 in PHP unless you literally only know or ever want to learn PHP. I could be wrong in terms of the entire language and it's ecosystem could have changed in the 18-20 years since I deliberated interacted with it last... We have a lot of things since mod php, so there's many other options, most of which don't involve PHP, so I suppose true fans will build their web apps in forth, I dunno...


My main beef with PHP is performance at scale. Doing 100.000+ req/s, the memory footprint for PHP is ... annoying.

What ended PHP were not the worst parts of its design, but upstream's unwillingness to simply change the language for better.

See, as a commercial enterprise (begware as a business) all kinds of "foundations" and sponsorship pools surrounding the language already accumulated a big enough pool of clients who were happy enough with PHP as it was in 4.0 era. They had no intensive to progress. Especially if their business depended on "fixing brokenness"

Open source and sponsorship does not always mix well. Just as with front-end frameworks/libraries that live off sponsorships, eventually it leads to people prioritising pleasing sponsors, and working on pushing their software over improving the software itself.

The current allergy in JS world about genuinely required breaking changes is all about that as well. Any times a talk of genuine "JS 2.0" starts to entertain minds of powerful players in the JS world, there will be tons of people with commercial interest coming and extinguishing the conversation with "no, we absolutely can not ever break anything, ever, even if it is already broken"

Breaking changes in JS world do occur, but most of them being near accidental, security related, or being done as part of actual sabotage like intentional breaking of synchronous AJAX requests after they were shipped.

My logic is, if breaking changes are still unavoidable in JS, why not to do them in a controlled manner, rather than through sneaky sabotage ops like one above?


I think ended is pretty strong word for a language that powers a huge portion of the web. Yes the lang. has issues and yet WordPress, Magento etc. are used an order of magnitude more than alternatives written in other languages.

Behind the language, the early day of shared web hosting make it affordable.

> but upstream's unwillingness to simply change the language for better.

Wow that could not be more wrong. PHP definitely changes things to make the language better, especially breaking changes. PHP5 changed objects from value types to reference types -- you don't get a bigger change than that.

But they don't just change things willy-nilly -- they do try to maintain backwards compatibility as much as is reasonable otherwise it wouldn't still be PHP.


Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: