Hacker News new | past | comments | ask | show | jobs | submit
I use to joke about PHP in the early 2000s, but now that I see the "better languages", I am starting to like PHP.

If you want a web page that works with a database (aka. CRUD), presents it in HTML form, and with a bit of business logic, like 90% of websites, then PHP does it simply. None of these astronautic patterns like you see in Spring, the dependency hell that comes with node, or whatever the cool kids are using right now. There is a reason PHP became so successful despite the hate it gets.

PHP is not great for security, it was terrible when it started, but now it is decent. And sure, a vulnerability was found, it is now fixed, every time a vulnerability is found and fixed, PHP becomes better. New technology may have an advantage due to better design, safer languages, etc... but you shouldn't dismiss the qualities that 20 years of bugfixes get you.

As for x86, yep, it is legacy, but it is not completely stupid either. The "RISC core" is not right, it is not like x86 become ARM or RISC V code internally. It is translated into long microcode-style instructions that wouldn't make sense as an ISA, where a compact representation is important for memory/cache reasons. RISC code is also translated just like x86 code, and the advantage of CISC vs RISC has gone back and forth. Now it seems we are going back towards RISC again, but before that, it was CISC, and before that, RISC again. The quirk about x86 that complicates things seems to be the variable length instructions. But the real problem is not really about which ISA is the best (it is a very small part of modern CPUs), it is more about licensing and backwards compatibility.

Yeah PHP was the first time web applications really "clicked" for me because there were not a hundred layers of abstractions between the html page and the application code. I was new to programming, and I took a look at J2EE and its literal million lines of code pet store that was supposed to be the shining example of how to do J2EE right, and I was like wtf is all of this... PHP though it was so easy to just make a page that gets some stuff from a DB, does some stuff with it, and outputs the result. I didn't need to read a 500 page book to get started with it.

In the end, PHP wasn't great, but around 2000 it was a great intro to building things on the web.

Having lived through that era, J2EE was ultimately a disaster. I remember an "entity bean" (terrible name for a class that manages data persistence) requiring multiple java files and at least a couple XML configuration files. It was complete madness. It was slow to build, slow to deploy, slow to run.
PHP's other advantage is deployment: it's simple. In the 2000's, I used to work at an enterprise Java shop but also did PHP freelance work. The amount of bullshit you had to go through to deploy a Java app on JBoss was insane.
> None of these astronautic patterns like you see in Spring, the dependency hell that comes with node, or whatever the cool kids are using right now.

Verbosity of a language/framework is meaningless now. Pick a language or platform that makes it as hard as possible to write insecure code, no matter the tedium, and let a coding agent bang away on the keyboard for you.

Verbosity and architectural complexity matter to a coding agent. LLMs have limited context windows, and the less verbose the code, the more you can fit in there.

Complex architectures are even worse, again due to limited context. LLMs work well at the function level but have trouble seeing the "big picture". I would argue that working with agents is all about managing context and things like skills, subagents and the practice of writing plans are just a way to optimize context use. If you could stuff your entire code base in there with full attention, it would be much easier, but the costs of doing this would be prohibitive.

I have a soft spot for PHP but these days I would reach for https://pocketbase.io/ by default for a crud app. It’s really great. :)
Yes, I never totally understood why the PHP execution model wasn't copied by frameworks in other dynamic languages like Ruby and Python.

PHP is hard to beat for development velocity. Edit a file, refresh a page in your browser, see the results.

You could always write CGI scripts in Ruby and Python, but other than catering to the PHP-infected, why would you want to?
Ish. I remember when the earliest versions of Rails used a CGI runner. Development didn't carry on long before application startup time became so horrendously slow that it was no longer viable. That is when it started to become popular to add a server in the application.

Now that people are back to writing their applications in languages that aren't as slow as Ruby they've, in many cases, taken the server back out of their application and have returned to the CGI model again; what is often marketed as "serverless".