Live data from Hacker News

PHP in 2022

stitcher.io

281–290 of 318 posts

Re: PHP in 2022

#281
post #216

Earlier quoted context omitted.

Because your data is teeny tiny, not performance critical, and `json.load` and `json.dump` is easy and usually less brittle then you're language's marshalling library.

Why save 10 minutes on setting up a proper database? Data is never teeny tiny, data is never not performance critical :) These decisions only bite you in the ass.

All my side projects have teeny tiny amounts of data. JSON file in the order of KB. Performance is great.

I have one project with a dozen users that handles around 50 reads per second and maybe 30 writes per day, no issues at all. Setting up a DB for that would just bite the next dev in the behind since it would need a lot more maintenance then an apache server with php.

Re: PHP in 2022

#282
post #224
post #177

Earlier quoted context omitted.

Does anyone really deploy PHP directly on servers still..? Running it in a Docker container is the simplest thing possible, runs anywhere, and has top-notch performance.

I meant Docker. The fact that I needed multiple processes (nginx+fpm) made PHP setup tricky compared with e.g. Java with embedded server.

> The fact that I needed multiple processes (nginx+fpm)

I believe you can have fpm listen on TCP and run nginx in another container if you want, although I haven't tried it so I can't vouch for it.

Re: PHP in 2022

#283

PHP is my go to language for building simple backends that store data as json in a file and synchronize access using flock(...). There are a ton of cheap hosting providers that support PHP and all you have do to is copy your files over and everything works. I love to focus my energy on building a great frontend with React or Vue.

PHP gets a lot of criticism for its legacy of behind hacked together. One thing that does get as much criticism, and one reason I avoid it for even simple things, is since it's request-based, it doesn't have a good story for connection pooling. While working on a former employer's PHP SDK, I had to add proxy hooks to it, then document how to set up Apache or Nginx as a proxy so you can get outbound connection pooling…

Doesn’t PHP-FPM handle pooling? Perhaps we’re talking about different things

Re: PHP in 2022

#284
post #230
post #8

I was a php developer for some time two years ago, before switching to go. I was mainly solving high performance parallel processing and distributed problems. There are things like ReactPHP which are an awesome achievement, but still every lib you use needs to be developed for ReactPHP. After learning about go and goroutines I only find it painful to solve these problems in PHP, even using ReactPHP.

Quoted post unavailable.

> I've written code that uses ReactPHP, and I can't see why every lib you use needs to be developed for ReactPHP. My guess is that you're an inexperienced dev.

Not OP, but perhaps every library is a bit of an overstatement. But, as most PHP code was historically written under the assumption that blocking is fine, potentially any library you use could inadvertently block your event loop.

Re: PHP in 2022

#285
post #188

Earlier quoted context omitted.

I'm one of those web devs that tries everything under the sun, and I also happen to have worked for a lot of companies (more than a dozen already, I'm on my 40s). Laravel is such a *joy*. I've never had this feeling of using something so easy and productive. I've been recently building a side project with LiveWire and oh-my-god. I really wish I had discovered it before. From the templating system (you get components…

Laravel and Livewire is the best-kept secret ever because everybody is too busy being biased against PHP.

Php/Laravel/Livewire == Elixir/Phoenix/LiveView == C#/.NET/Blazor == Ruby/Rails/Hotwire/Turbo

It's also slowly being integrated into JS frameworks although they're still behind as the focus has been clientside and static generation so far.

Re: PHP in 2022

#286
post #74

I learned to use php when I was like 14. I’m 27 now and still derive such joy when making my own little projects that will never see the light of day. I try to be humble as far as just being a php trash coder, but I don’t feel too ashamed honestly, as it is the most mainstream thing really. I will always be grateful to php for being accessible and yeah, I guess easy. I don’t know why php is the only one I really stuc…

In a world where everything is fast becoming a JavaScript front end with “some” backend and with the improvements PHP has seen in recent years I don’t see why you’d consider yourself a “lowly” php developer. I’m mainly a C# guy myself as far as the backend goes, but I don’t view PHP as being bad in 2022. I think people who do are stuck in the past to be perfectly honest. It’s sort of like disliking JavaScript because…

The reason for PHP's hate is detailed in this great vintage article: https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/

That's from 2012 and many of the issues have been fixed since then, but it was the truth a decade ago and tainted the experience for many devs who have sine moved on to other languages.

Re: PHP in 2022

#287

Earlier quoted context omitted.

PHP gets a lot of criticism for its legacy of behind hacked together. One thing that does get as much criticism, and one reason I avoid it for even simple things, is since it's request-based, it doesn't have a good story for connection pooling. While working on a former employer's PHP SDK, I had to add proxy hooks to it, then document how to set up Apache or Nginx as a proxy so you can get outbound connection pooling…

Doesn’t PHP-FPM handle pooling? Perhaps we’re talking about different things

Isn't this for process reuse and incoming connection reuse? I needed outgoing connection pooling.

Re: PHP in 2022

#288
post #250
post #205

Earlier quoted context omitted.

I did use Rails for several months while helping a friend with his business/sideproject/startup kick-off and despite I really liked it, I much prefer Laravel + Livewire and PHP ( https://tallstack.dev/ ) over Rails + Hotwire + Ruby, but it's up to personal preferences: - I prefer things to be more explicit than implicit and lean more towards configuration over convention. - I lean more towards having types/typing inf…

I'll take Rails over Laravel any day. Verbose, doc-block-riddled, pseudo-Java PHP is the polar opposite of elegant, composable Ruby.

Well, probably you are right, but for me ecosystem, libraries, tooling, editor support, performance, etc is far more important than language syntax. But we all have our preferences and that's ok.

Re: PHP in 2022

#289
post #159

Earlier quoted context omitted.

In a world where everything is fast becoming a JavaScript front end with “some” backend and with the improvements PHP has seen in recent years I don’t see why you’d consider yourself a “lowly” php developer. I’m mainly a C# guy myself as far as the backend goes, but I don’t view PHP as being bad in 2022. I think people who do are stuck in the past to be perfectly honest. It’s sort of like disliking JavaScript because…

> why you’d consider yourself a “lowly” php developer. PHP has always been considered as a somehow bad language in all corporations I've worked at to date. The same applies to other script languages such as python, ruby or nodejs - but PHP was the most undervalued of them all. It's kinda strange because the language is really performant and relatively easy to use. Maybe that's exactly why the big brain architects don…

Let me preface this by saying that I pass zero judgment to any people who use PHP by choice or otherwise, and that I don't assume I'm "better" or smarter than anyone else for their programming tool choice.

But, if you genuinely want to know why some of us hate on PHP, I can tell you the reasons that I would never choose PHP for a production backend (now, I do think PHP is a fantastic scripting/sysadmin language- better than Python for sure, but I don't know Perl well enough to judge against that).

PHP is single-threaded. I feel like that's a pretty decent reason all by itself to not want to use it in an enterprise environment.

PHP is not really async, either. Yes, there are are run-loop libraries, and some libraries even claim to be async all by themselves, but these solutions are awkward and cumbersome and easy to use incorrectly.

PHP's array data type is ridiculously bad. In every conceivable way. If you want to use it as a contiguous, linear, collection, then it's slow and bug-prone (e.g., using array_filter, but forgetting to wrap it in array_values). If you want to use it as a dictionary, then it will sneakily convert your keys into numbers which doesn't matter until it does (like when trying to operate over filenames in a directory and someone named a file "1". Then you try to do some operation that expects a string and your code explodes several hours into its operation... Ask me how I know).

PHP's iterators and other, more professional-grade, data structures are not as "first class" as plain-old array, so nobody uses them. IIRC (it's been a while), you theoretically need to enable them in your php.ini and/or install them at the OS level, which kind of kills the whole "PHP is so easy to deploy! Just FTP a file and you're done!"-thing.

I prefer static typing to dynamic typing. PHP's static typing is weak (as in not strict enough) and not expressive enough for me (no generics, no sum types, no extending classes/types).

PHP does not allow for custom equality definitions. Also, since everything is references, I believe you can blow the stack if you try to check that two objects are equal that reference each other.

The architecture of every HTTP request getting a fresh instance of PHP is actually pretty nice. And a ton of work has been put into the language/runtime to make sure it's stupid-fast at ramping up and parsing the request data. HOWEVER, as soon as you slap one of these popular frameworks (Laravel, Symfony, etc) on top, you've basically ruined it and made it slow, with all of the extra framework initialization junk. I remember seeing engineering effort go into "compiling" Symfony code to make it load quickly (I don't remember how Laravel works). But think about that for a second- we're going to choose an interpreted language that can't cache any state beyond a single request, and we're going to add a COMPILE STEP to it?! So that we can work against the init-process-teardown cycle that it's designed for? Are we really sure we actually wanted to use PHP?

I used to have more specific complaints about strings and the numeric types, etc, but it's been a little while since I've had to write any PHP (I haven't used version 8, but I was using 7.4, I think, so I'm still fairly immune to the "You only remember PHP before it became awesome in 7+." criticism).

I'm more than sure that any regular PHP dev has no problem dismissing all of my complaints. Just like when I went to the doctor and told him my elbow hurts when I bend my arm. He told me to stop bending my arm! Problem solved. ;)

Re: PHP in 2022

#290

I started my career in PHP ~15 years ago trying to do OOP in PHP 4.x. That was "fun". In the meantime I switched to other stacks but I've been keeping a distant eye on how PHP was evolving and I still am involved with PHP projects to a certain degree, though rarely at code level. I really appreciate the effort put into fixing most of the things I hated about the language, though at times it felt like the language and…

> Why would I choose PHP when starting a greenfield project? Ease? I have not professionally used php since php4, and last set it up in php5.x. Last night I wanted to send some data to an http server, a small payload of json, that would be saved into a DB and queried later. Took me all of 5m to realise that my php test script that receives the file can be copied over to my el-cheapo webhost account unchanged and work…

If you use CGI, you can have it just as easy with any language.
Post reply on HN