Live data from Hacker News

A look at modern PHP

lwn.net

521–530 of 610 posts

Re: A look at modern PHP

#521

Earlier quoted context omitted.

no PHP framework is similar to the thing that NextJS/Reactis doing. The output is the same (well, isn’t the point of web framework is to spit out HTML?) but the methodology is totally different.

And about 100x more complex and fragile.

Comparing strictly SSR yes. Though if one needs a lot of dynamic client side behavior a JS framework can be easier to reason about.

Lately modern PHP frameworks have so a lot of dependencies too. So both stacks are getting fatter as their capabilities grow.

Re: A look at modern PHP

#522

Earlier quoted context omitted.

If pointing out that he's using the wrong technical term is 'missing the point', I'm not sure there was one to begin with. most examples of why php is so easy to deploy show it with hello world examples you'd never encounter in the wild. yes, you can edit the php code directly on the server that is executing it. just like with python, nodejs, ruby ... and even java if you're not worrying about scalability. there is r…

I can, on my local server, change the code, hit it again, and have my changes reflected in what happens. Doing that with Python, Node.JS, Ruby, or Java requires extra configuration . That's the point.

Rewriting a bunch of text files isn't atomic, so you need to take a planned outage or atomically rename the source dir so you don't serve 5xx errors from parsing half-written source. At that point you might as well have a deploy process, which can be as simple as "rsync && mv" into each host.

Re: A look at modern PHP

#523

Earlier quoted context omitted.

Funny, I remember everyone hating on PHP when they moved to RoR, and now they hate that are and moving on. Its almost as if they just need things to hate so they can rewrite code. its very cyclical IMO. The elitism of learning a new language and then mocking those that haven't put in the same time and effort to row in the exact same direction, has always amused me. Ive never judged anyone for what tools they use to g…

Kinda like how people used to hate typed compiled languages and migrated to scripted dynamic languages en masse. Then they discovered they want performance of compiled language so they built JIT into their interpreters, eventually adding compilers as well into their languages. Then they also realized that enforcing types are actually good, so they built typing support into their languages, finally coming full circle…

I see it both ways. While java can never let go of types, the language is doing what it can to reduce the verbosity that is inherent with types (by e.g introducing inferred types, lambdas etc). I can't say that dynamic languages stopped being dynamic. Yes, there's typescript. But there's a shit ton of dynamic code out there, being written at this very moment probably.

Re: A look at modern PHP

#524
post #505

Earlier quoted context omitted.

i haven't done wordpress in 5+ years but oh my god it had everything that's bad about php in it.

I wouldn't be shocked if Wordpress has singlehandedly tarnished the reputation of PHP in general

Writing modern php 7.2+ and creating a WordPress plugin is akin to time traveling. The experience in WordPress is not so great but they have a commitment to backwards compatibility. So I get it. But ya, I agree with this statement.

Re: A look at modern PHP

#525

Earlier quoted context omitted.

Where to begin? - No proper connection pooling with circuit breakers. - No proper multithreading (that works in web environment) or parallelism in general. - Almost everything blocks (even `new PDO('mysql:...')` can block for whatever the execution time limit is, if there is an issue with connection or MySQL server). - Most libraries are implemented in C instead of in PHP, whereas with other languages people try to a…

> - Most libraries are implemented in C instead of in PHP, whereas with other languages people try to avoid native code as much as possible. This means that code is not memory safe, and understanding or contributing is close to impossible. You want this in any scripting language if you don’t want memory use and cycles to balloon out of control for simple tasks. Most any scripting language looking for performance is g…

i think it's where the glue goes. do you implement an algorithm/write a generic library in c and then glue it to your high level language in your high level language, or do you write a plugin for your high level language in c?

in both cases you need to understand pointers and function pointers and the difference between your integer type and a c int, but in one case you're at home while you do it. in one case, you could plug in to any existing c library without writing additional c, so if the problem is already solved you just use the ffi and you're done. in the other case, your problem is just beginning

Re: A look at modern PHP

#526
post #510

Earlier quoted context omitted.

A lot of the common complaints about PHP are merely echoing the wildly outdated and misinformed "PHP: A fractal of bad design" that has been circulating for the better part of the last decade. Unfortunately people tend to uncritically repeat whatever it says without actually paying any mind to the facts that, 1) it's 8 years old, 2) it's flat out wrong about a lot of its claims, 3) it's evidently written by a guy who…

In regards to your last point, I believe PHP was intended to be a quick and dirty templating language for C programs. Right? But if we're not using it for that purpose anymore, why would we want a programming language that grew haphazardly out of a templating language and is suffused with the quirks of that legacy? Yes, it's better than a decade ago and getting better all the time, but is it good yet? Does it have an…

PHP was intended to be a quick and dirty templating language for the web, not for C programs. It was always intended to be directly embedded in HTML pages; remember, it came from the era when the assumption was that most pages were static and you only needed to embed a bit of dynamic code to make everything awesome. A natural side effect of this is that PHP programs aren't like programs in any other language: technically, they're a web framework and a templating language right out of the box, and they always start execution from ground zero at the start of an HTTP request. In some ways this is great, but in other ways it, well, isn't; implementing a front controller pattern for your MVC framework means writing code that subverts that design, as well as loading configuration and performing initialization for the entire application on every request. (Yes, I know modern PHP caches opcodes and data and I'm sure many modern frameworks are very clever about lazy loading, but no matter the cleverness they may employ, PHP frameworks simply have to do more work per request than frameworks written in languages that get all the setup and configuration out of the way once.

While the criticism that the "Fractal of Bad Design" post is eight years old is fair, the criticism that the author "doesn't understand PHP" isn't; it's very clearly written by someone who understands PHP and is frustrated by it. Not all of the criticisms are still true, but PHP's huge popularity means that it's very difficult for them to change the language design in ways that truly break backward compatibility.

PHP's biggest advantages, I think:

- it's actually still very fast, particularly if you use a well-optimized framework or (gasp) don't use a framework at all

- it's super easy to deploy, especially for small-scale sites where "first, build a Docker container" sounds like the tech equivalent of taking the Harrier jet to pop over to the grocery store

- it's got a pretty robust ecosystem around it at this point

In my extremely subjective opinion the closer you can come to PHP's laser-targeted ideal of "minimize the setup and just get going," the better off you are, and if you find yourself routinely invoking multiple factories to create dependencies to inject into your inflected reflected dejected container it may be time to either investigate a dynamic language that is not trying to become Java or to just, you know, use Java, but again, that's just me.

Re: A look at modern PHP

#527

Earlier quoted context omitted.

as a Ruby/Rails guy, I feel the same way. Seems like Rails became the top stack to shit on to feel better about your stack these days. People are just tribal. We need to feel superior to the "other" to feel better about ourselves.

Funny, I remember everyone hating on PHP when they moved to RoR, and now they hate that are and moving on. Its almost as if they just need things to hate so they can rewrite code. its very cyclical IMO. The elitism of learning a new language and then mocking those that haven't put in the same time and effort to row in the exact same direction, has always amused me. Ive never judged anyone for what tools they use to g…

I've been (re-)learning Rails now that it's at version 6 instead of... 2.x, I think, when I last tried it? I've been joking that now that Rails is no longer cool, it means the people left are probably settling down to do serious work.

While I think you're right about the elitism hype cycle, I do think Rails and PHP have something in common, though -- they were systems that people who really weren't that interested in learning how to program leapt into in droves, because they were both perceived as "anyone can learn to code" technologies. And that led to an awful lot of bad code written with PHP and with Rails, which in turn contributed to the buzz about both turning sour.

Re: A look at modern PHP

#528

Earlier quoted context omitted.

PHP has excellent development experience. After updating your code, you can just reload the page. That's it. It's seamless. This is something that I sorely miss now that I'm a .NET developer. Also, the PHP ecosystem is friendly to beginners. Compare these authentication docs for a PHP project vs a .NET project: Laravel (PHP): https://laravel.com/docs/7.x/authentication ASP.NET Core (.NET): https://docs.microsoft.com/…

> After updating your code, you can just reload the page. That's it. It's seamless. This is available with many other languages as well, i.e. https://github.com/cosmtrek/air It may require an external tool, but the deployment experience is a lot simpler for Go than PHP.

I think in all the critical pain points all relatively popular languages used for web development have a well thought out story. I think there's nothing about the "pipeline" that's a huge bottleneck for a well-seasoned developer anymore. At least there shouldn't be. It's more about (a) getting things spec'd out well, and (b) execution.

Re: A look at modern PHP

#529

Earlier quoted context omitted.

Well, Rust is playing catch up with the "change code and run" speed of PHP.

Do the two overalp in their niches at all? You'd write a web server in Rust. But is there much effort put into Rust web frameworks? It's just a weird comparison. PHP is competitive with JS, Python, Ruby and even Java. But Rust? That's C/C++/D territory. And Go is somewhere in between.

There is lots of effort by Rust devs, even if the libraries are not as mature or easy. I don't believe you meant to be disrespectful here. I think better a better words could be any of manpower, maturity, or time.

Re: A look at modern PHP

#530

I wonder if most developers that trash on PHP for trivial issues like seen in this thread haven't been using it for many years, or had a bad experience (e.g. maintaining a legacy app). Some developers live in a kind of technical vacuum where, I guess they assume, the technical features of their programming language are what makes the difference in the value of the business they're building. In reality, the difference…

Why would I ever want to use it again after php5? It might be better now but the competition is so much better than what php5 was that I have zero reason to revisit the language.
Post reply on HN