Live data from Hacker News

PHP in 2022

stitcher.io

221–230 of 318 posts

Re: PHP in 2022

#221
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…

> I think people who do are stuck in the past to be perfectly honest.

I've recently tried to help out a friend who got stuck with a half-finished PHP project and a deadline to deliver, I have not touched PHP in 10 years and it still has the stench of a bad language from the get go - "modules" requiring VM config, "include" files ... what is this 90s ?

PHP might have had a huge patchwork competent people did to keep things working once projects using it grew enough, but coming back to it after 10 years it still felt like it was built on a foundation of shit.

Re: PHP in 2022

#222

Earlier quoted context omitted.

> I'm curious what is the value proposition of the latest PHP version(s). I think more and more people have started to realise that typed languages make better, more reliable software. The incremental additions to PHP's type system are just a move towards this, I think and can be seen in other languages such as Typescript. I'm just not a fan of dynamically typed languages anymore, even for small scripts. > Why would…

I think that says more about your particular mental model of programming than about programming in general. In the couple of decades I’ve been coding, I’ve seen good use of both dynamically/weakly-typed and strongly typed languages. Sure— thinking you’re going to save time writing more complex applications by avoiding boilerplate is flatly wrong. However, if boilerplate would be a double-digit percentage of your code…

> I think that says more about your particular mental model of programming than about programming in general.

Well, I originally started programming only using dynamic types.

Then I moved to typed languages, and I could avoid whole categories of errors. I don't see it as dogma, I think typed languages are just qualitatively better at creating software. I also think this is starting to become industry experience, as efforts like Typescript, and the incremental additions to PHP's type-system show.

Re: PHP in 2022

#223
post #20

I'm a fan of PHP and have been for years for several reasons: 1. Low barrier to entry; 2. Hard to leak resources since the model is to tear down everything after a request finishes; 3. Stateless API core which means the efforts of creating an environment for a request for (2) is extremely low. Compare this to, say, the bootstrap time for Python or Java (which is why those generally don't follow the request teardown m…

I agree that PHP hate is pretty boring. Nothing beats being able to FTP a few files to deploy a simple dynamic webpage. I still use it for that. But when it comes to building large web apps, I moved on years ago. While I have seen there have been a ton of improvements with some really nice frameworks, there is nothing so crazy innovating about any of it that would make me care to switch back.

Re: PHP in 2022

#224
post #177
post #120

Earlier quoted context omitted.

Is it? Last time I used PHP (around 5.x-7.x) it was exactly the other way around. For production you needed php-fpm, nginx, opcode cache... it was a nightmare compared with go or even java. Is it better now?

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.

Re: PHP in 2022

#225

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…

I think unambiguously janky design choices like this[1] in PHP's early history is what's given it such a bad reputation, while it might be a decent language now such a reputation is hard to shake. I'll be honest the only time I'd reach for PHP over a comparable language with a less chequered history like Python is if I was dealing with a project that was already closely tied up in the PHP ecosystem. [1] https://www.i…

Yeah most of the PHP hate came from old school PHP 3 code co-mingled with HTML 2/3 that didn't take advantages of the simple OOP added. PHP 4 took decent steps but couldn't shake that stigmata. PHP 5 and some good MVC frameworks (written in 4 and 5) made great advances and 7/8 and the spinoffs make the language pretty good for any scripting or web job. These days I prefer JVM based languages but if I needed a quick web task with minimal overhead PHP would still be in the top 3 options.

But some old timers (genX) still today bemoan php as if it had no progress made.

Re: PHP in 2022

#226
post #190

Earlier quoted context omitted.

Packagist actually gets a lots of things right that NPM gets wrong: 1. NPM has a global namespace that was shoe-horned into an organization thing later. Packagist has been namespaced since day one. Using a namespace avoids almost all of typo-squatting issues etc. 2. NPM hosts the code at its end. This means you could review some code on GitHub and it might not match the code that you get. Packagist fetches the code f…

> The PHP community also prefers medium sized packages, so you don't get a thousand dependencies accidentally. I think it was Laravel or Lumen? I tried that one once and was kinda amazed it pulled like 100 packages. In PHP ecosystem, I think that's considered a lot (to be fair, this is few years back). I've worked on fairly large projects (mostly Symfony + Doctrine and PHPUnit) and don't recall seeing so many depende…

checked for a fresh laravel install: 110 packages, 40 of those are development dependencies. Of the 70, only 38 are non (symfony/laravel) dependencies.

The PHP ecosystem tends to use packages-for-interfaces, so that ups the count somewhat.

Re: PHP in 2022

#228
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…

yup, same. started at like 16 and just never found a replacement for writing web apps that was as easy to pick up with lots of built in power. the documentation has always been _extremely_ helpful too, shout outs to the php.net team for making it so easy to learn.

Re: PHP in 2022

#229

Earlier quoted context omitted.

Could you elaborate on the shared-nothing architecture?

I found this article a while ago > Every web request starts from a completely blank slate. Its namespace and globals are uninitialized, except for the standard globals, functions and classes that provide primitive functionality and life support. By starting each request from a known state, we get a kind of organic fault isolation; if request t encounters a software defect and fails, this bug does not directly interfe…

How does this differ from how other web frameworks work? I thought almost all of them are shared-nothing.

Re: PHP in 2022

#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.

No post body was provided.
Post reply on HN