Hacker News Reader

Comment by egeozcan | Hacker News Reader

PHP was, and perhaps still is despite stiff competition from frameworks like Next.js, the ultimate backend-for-frontend (BFF) solution. It's a server-side, super-flexible layer ideal for connecting various components and delivering static HTML with JavaScript enhancements.

While there's nothing inherently wrong with using PHP for tasks Java already handles well, given Java's proficiency in its domain, it's not always necessary to replicate these functions in PHP.

However, there's a tendency to undervalue PHP-based applications, often labeled as 'home.php-style' apps. It's true they can become unwieldy and unmaintainable if not properly managed. Adhering to good practices is essential, but it's also important to remember not every project needs a complex solution like bootstrapping a Laravel project for a simple task list. Everything comes with its own set of trade-offs!

View on HN

I think it just boils down to your dev pool. If you already have Java devs, why bother establishing PHP as a new language in your company? Certainly, you can't justify paying them less than your Java devs...

Let's face it, a major advantage of PHP nobody talks about is that devs are cheaper.

I don't mean this all in a bad way, I have seen PHP used in high quality code-bases for websites of medium sized companies. But you are limited to input/output operations. However, there is also an advantage to this, as the PHP devs I have seen are more prone to trying out new tools and not reinvent the wheel in source code.

Also, I want to shout out to the guys making Sulu CRM. Loved working with it, too bad it's PHP and symfony only.

> as the PHP devs I have seen are more prone to trying out new tools and not reinvent the wheel in source code

Do you mean "less prone"?

Not a PHP developer, but wouldn't the reason be a more responsive development environment?

Edit text file on server, refresh page in browser, see your changes.

That's really difficult to pull off with Java.

Difficult yes, but Quarkus can do it (Java got dynamic class loading after all: https://medium.com/geekculture/speed-up-development-and-save...

You are technically right about changing files of course, but remember:

- PHP speed is all about caching. Changing a file means rebuilding (all) caches.

- PHP debugging is nothing worth bragging about. Java is way more powerful and the jvm supports runtime reload of methods as well.

This also goes together with the fact that most php devs are println devs (from what I have observed).

And then there are other things like maintenance of old php applications is a major headache because on mac old php versions just disappear in brew. And new PHP releases like to break A LOT.

Is relying on OS bundled PHP version really a thing? I have not once in my 12 years of working in this field experienced anyone relying on the default OS installation of PHP. Most PHP lives in shared hosting platforms that are managed, and needier apps in a VPS where the PHP is also set-up, or in Docker, where again, it's set up.

> the PHP devs I have seen are more prone to [...] not reinvent the wheel in source code*
I have the opposite experience:
Because PHP and package management is relatively new (Composer is from 2012, compared to CPAN's general availability in 1995), I haven't seen more wheel-reinventing than among PHP programmers.

Even the standard library seems to be reinventing its own wheels. I'm looking at you, mysql_real*_escape_string.

> However, there's a tendency to undervalue PHP-based applications

I don't think there's that. In every thread about PHP, many people come in to explain this (edit: this = how good PHP is for use-case X, or how good it is holding up). Every time.

"We" all know PHP has its very well-fitting sweet spot. Its use-cases where it shines.

I do think, though, that the list of use-cases and the size of the sweet spot is not as big as the usage of PHP makes it out to be. What I mean is: there are many situations in which PHP is the best solution. But in many places where PHP is employed, it is not the best solution (anymore).

Being someone who spent a lot of time in the WordPress space and is building a pretty complex PHP app now, I think I see the whole movement of "server-side React" as a subset of developers doing everything they can to not learn PHP. I think I'd have more grace for them if they also didn't have multiple frameworks to not learn CSS. I know it's petty and I'm painting with a broad brush, but it can feel frustrating when so much of parts of web culture insist on using the same hammer instead of exploring the toolbox.

EDIT: All that to say, I get it, and for my part I'll try to tone it down. Thanks for listening to this old(er) guy rant.

Yes, I think there's a weakness, maybe especially with younger developers, to keep all development in just one language.

A current example for me is SQL vs ORMs. I feel like I'm more productive building SQL queries in my application (ideally using a query builder API), than using an ORM. Because SQL was created to be a language for manipulating relational data, and thus does the job better than the indirection introduced by an ORM framework.

I completely agree. Specially when that hammer is a lot more complex and heavier than it needed to be.

> PHP was, and perhaps still is despite stiff competition from frameworks like Next.js, the ultimate backend-for-frontend (BFF) solution.

I think Elixir with Phoenix and LiveView can give PHP a run for its money. But PHP is a beast.

I have asked many times why there are not more successful framework with the same design and execution model as PHP, but with a more popular programming language like Ruby or Python or, and never gotten a really satisfactory answer.

Is Ruby really more popular than PHP?

Not at all.

Probably in some places like SF but outside of that, no. PHP is massively popular outside the US.

I haven't seen a single Ruby job in my area ever. I always assumed it's a US thing.

I think Rails wins out in terms of simplicity, but I haven’t played enough with PHP.

you can't compare Rails with PHP. Either Ruby with PHP, or Rails with Laravel

Rails is a framework, PHP is a language. A more apt comparison would be Ruby vs PHP, or Rails and any number of PHP frameworks like Symfony, Laravel, etc.

Programming languages tend to fall on a spectrum of "whip-up-ability". The faster you can prototype in a language, the more god-awful spaghetti you can produce.

With great flexibility comes great responsibility

But then you'd have to write in largely untyped PHP (yes, I know PHP now has some types, but it's not the level of other languages) and not a better language like e.g. TypeScript or Rust.

The only missing thing about PHP types is generics (array<int> and similar) and non-explicit coercions, which can be fixed with `declare(strict_types=1)`. Other than that, all types checks are enforced at runtime, unlike Typescript.

It's not just having types, other libraries have to support them too. Python has type hints but some libraries support them while some don't. While this is true in TypeScript as well, the vast majority of the most used packages have TS types. And I also want my types to be checked at compile time, not runtime. For runtime, I'd just use Zod.

But .. PHP doesn't have compile time. It's an interpreted language.

Static type checking. Javascript / TypeScript is not compiled either.

Doesn't TypeScript get compiled into JavaScript? I thought TSC actually does a compilation, hence the name, TypeScriptCompiler? But anyway, this also exists for PHP. Psalm (https://psalm.dev/) or PHPStan (https://github.com/phpstan/phpstan) both offer static type checking.

TS tries to keep syntax the same as JS. So tsc usually is just stripping types and, depending on settings, transpiling newer JS features to older versions.

That's still called compiling, regardless if the thing it compiles into is similar or not.

Well then PHP has opcache compiling.

Maybe I’m missing something but isn’t TS compiled to JS?

> all types checks are enforced at runtime, unlike Typescript.

You're presenting this as if it's a feature. I think that's a good summary of PHP and its culture's relation to types.

I use Psalm to statically analyze PHP code, and in my experience the control flow analysis is actually better than in TypeScript.

Reply on news.ycombinator.com