Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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 stuck with exactly, but it is weirdly dear to me. Nearly half my life I’ve never gone too far past being a lowly php coder, and not a great one at that, but I still like what I can make at the end of the day. It’s a side creative thing for me. Laravel was a revelation for me over the last few years, it just makes some things make sense that never did for me as a self-taught hobbyist.


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 it really sucked the soul out of you before typescript eventually made it nice to work with.

But being mad at any programming language is sort of silly isn’t it? If it works it works.


> 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't like it. They do tend to love things correlated with pointless complexity after all


People dislike PHP because its standard library had many inconsistencies and interesting design decision that no sane programmer would ever even think off, like all random numbers being odd (https://stackoverflow.com/questions/31612082/why-does-mt-ran...).

Many of these decisions revolve around the authors not wanting their functions to fail under any circumstances. This is nice for beginners but quickly hurts more than it helps in larger projects as it obfuscates bugs.


I hear that too, and frankly seems a dumb reason not to use a language. Does it get the job done, can you build value quickly, yes and yes


AFAICT, that behavior was fixed with the release of PHP 7.1 in 2016.


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. ;)


There’s a lot of debate about this kind of stuff on the internals mailing list. In fact, the array string to number thing was just recently discussed and why it is the way it is[0]. It would take an entirely new type to support keeping it as a string.

0: https://marc.info/?l=php-internals&m=164155164316739&w=2


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-programmer.info/news/98-languages/6758-the-rea...


Unfortunately the bad design choices from the past are mostly here to stay - I mean, when you have the thing you want to find (the "needle") as the first parameter in about half of your "find something in something else"-type functions and the "haystack" as the first parameter in the other half, are you really going to break backward compatibility just to make things consistent? Of course not! So PHP will never be my favourite language (although I work with it every day), but it gets the job done, so...

Since you mentioned Python: I would never think of using Python instead of PHP, at least not for a web-based project. Performance-wise PHP is (I think) better thanks to all the work Facebook sponsored, and it has all the "batteries" needed for web development included, so the only reason for choosing Python would be that it's maybe more "elegant".


Clarification: While Facebook sponsored a lot of work it was on their competing HHVM system, which spured other contributors that competed with HHVM (Zend mostly) to invest more in PHP and develop the performance improvements in PHP 7 and 8.

The performance improvements where not directly sponsored by Facebook.


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.


Yes, sorry, I don't mean to make out php as this scrappy underdog or that we are under constant attack or anything... I see it more like, ummm, a pumpkin spice latte of languages, something viewed as a lesser choice because or in spite of its popularity? There are all these other amazing options, why pick this? Of course, with programming languages, you have many objective criteria where a coffee drink is totally subjective. Languages are also a huge investment time-wise instead of being able to try different flavors each day. Not a perfect analogy, but maybe you still see a little what I was going for as far as lighthearted stigma. PHP is and has been doing so well for so long, but I couldn't argue a huge case for it personally besides... it was there. It clicked at the time. I grew up with it.

I am balancing my love for it with the public perception I have seen over the years (fortunately I think much of the vitriol has waned sorta), in terms of how bashful I feel whenever discussing anything coding-related as to not overstate what I know/do. Most people, I think, grow out of php, so I see myself as a bad stereotype in still using it. But it has done a lot for me in terms of confidence building, being able to make things, the creative process of turning nothing into something, even though admittedly if I'd picked a different language I could likely say the same. But as far as staying with it, I feel like I look lazy for it, it just does what I want it to do. I am grateful for it. I hope this made sense.


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


I think the criticism hurled at PHP is misplaced. It serves the niche it was designed for very well. As long as you have namespaces, the include files should not be a problem for you. You can design a class loader and use that. The only thing you need to tell php.ini is an include path and then rest of the configuration is app dependent, like it is for any platform. Where do you find VM config for modules?

Also, any language that is used in real life is built on a foundation of sh*t only. The component loading with python is so bad that I have programs keeping their own version of python and IDE suggesting I create VM for my project. The situation with C is so bad that no one can solve my linker problems unless I switch the toolchain version. For a long time Javascript was a (purpose built) toy language to sprinkle pixie dust on web pages. Any sufficiently complex problem requires either deep knowledge or following convention (tribal knowledge specific to the context)


well to be fair, any user is quite capable of building a pile of shit using any language, and if you were mucking with include statements manually it sounds like that's likely what was going on


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.


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 out of the box! no more "includes" if you don't want to) to the validations, to the queues system... everything is so well integrated and so easy to use.

For the last decade I've worked mostly with Django and SPAs, I'm not going back to that any time soon. Django templates are extremely limited for nowadays requirements, and SPAs are 1000x more complex to build and maintain so in my opinion they're not worth the price/effort. I think Livewire, Hotwire, Unpoly, Htmx, etc are what 90% of web apps need.


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.


== Everything else/HTMX. Well currently HTMX is still a "low level" clientside library, but in a similar vein to Ruby/Rails/Hotwire/Turbo.

Feels like BE-first dev and non-SPA/JS centric client webdev is slowly regaining ground. Exciting.


I've found Unpoly to be a nice middleground between those framework specific solutions and htmx


Or we're too busy using Phoenix LiveView ;P


One of the companies I worked for used Elixir/Phoenix. It is an extremely cool piece of tech but it is nowhere near as productive as Laravel, Rails, etc. Missing libraries, difficult to hire for, bad editor support, and overall feels very niche which such a small community. That company eventually moved out of it.


Hey, that's why we need more people! It's getting better and better all the time. And nothing really beats its ease at making conncurent web apps. But yes, if you're an IDE person, you're going to have a bad time and that is not likely to chnage any time soon (I don't think?)


Or Rails/Hotwire.


I like Laravel, but i don't like Livewire that much. Livewire is really neat when building simple interactive stuff, but when building larger more dynamic parts it gets pretty sluggish and the livewire component codebase starts to feel harder to maintain.

Last time I tried to use Livewire with Vue, it had some issues which caused Vue to lose reactivity. (Maybe Livewire removed the DOM where the Vue instance was rendered. There was some options that prevented livewire from replacing elements with given id/classname.) But if i remember correctly, you cant have livewire element which has vue components as child elements.

Maybe i was doing stuff wrong or the livewire<->Vue compatibility is a bit better nowadays. Or maybe its because I'm too used to Vue.

It felt like the Laravel community jumped to the Livewire hypetrain quite fast and it feels like the livewire recommendation to use alpinejs in someparts is required. And most of the examples for alpinejs requires you to write inline code. (It is possible to split the code to own js files, but then again you are building something that gets closer to Vuejs.)

It feels weird to recommend to write scripts using inline javascript. That requires more CSP modifications for security and also the scripts wont get cached and are loaded every time the page loads. (If I'm correct.)

TL;DR Livewire is great for small features.


I think livewire works better with Alpine. Also, I think Livewire is great for interactions that require a backend request (such as posting a comment, refreshing some data, etc). If an interaction can be performed without reaching for the server, then Alpine is a better option.

In my opinion, when everything breaks down (and not saying this is your case, just what I think) is if you try to do every interaction with Livewire (thus reaching for the server when you shouldn't) or when trying to mix in SPA tools (such as Vue, React, etc...) with it. I suppose you'll end up with the worst parts of every solution.


Did also plaid with Ruby on Rails, or even Sinatra, and how would your rank the dev XP compared to Laravel?


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 information than not having it

- PHP is way, way, way more used than Ruby

- Performance (just talking about development environment performance) is a lot better in PHP (no server restarts, etc)

- Availability of third party libraries is a lot stronger on the PHP side, probably due to it being more popular

- Tooling and editor support. This is a big one for me, and I've found out things to work a lot better with VSCode for PHP than for Ruby. Probably related to it being both, more popular and more explicit.

- Overall, Laravel feels even more complete than Rails and just fits better my brain.

But, I think Rails is still great, and I would use it over building a microservices mesh of Go servers on kubernetes with React frontends, etc, etc.


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.


I started at 16 and I'm 34. Went from working on gaming websites to running giant ERP backends for mobile apps, web apps, and api users in high throughput environments.

All I need to get to work is VSCode and some linux VM or container. PHP has an obnoxious amount of depth. You can become an expert on just ORMs or just SSO or just Collections or just routing and still be learning something new everyday. I am actually "self tought". Whatever that means.


> I am actually "self tought". Whatever that means.

What does that mean? I know what taught means, but tought? No idea.


A charitable interpretation would be that he meant "self-taught". It's not that difficult.


I started doing my first web development with PHP (4 & later 5) around the same time! Actually ended up learning a lot about how the entire LAMP stack worked + a lot of tricks and theory behind how to make things secure (PHP had very few safeguards back then). I'm still reaping the benefits of a lot of this knowledge to this day.

I have moved on to other languages like JS and Python since ~2012. Looking at the article, I feel like modern PHP is almost a completely different beast compared to when I used it back then >_<


PHP was my first love. It still is. Professionally I have moved on to other languages. But whenever I have an urge to create something for personal use, PHP is always the most productive way to get it done. With Laravel, I can even make it look polished and put it on the web.

PHP is such a joy that I am really thinking about switching back to it for my day job.


In my experience, a lot of the hate that PHP gets is unjustified. I can only speak from personal experience, but most people I know that complain about PHP were just burnt out from dealing with other developers' code. Having such a low barrier to entry created many novice and hobbyist PHP developers to hit the market, and start producing terrible code due to not fully understanding software development practices. I know I never had an issue with PHP, and could get work done very quickly, but once I had to start working through other's spaghetti code it burnt me out and I moved on to other languages with a bit higher barrier to entry.


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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: