Live data from Hacker News

PHP in 2022

stitcher.io

241–250 of 318 posts

Re: PHP in 2022

#241
post #109
post #63

Earlier quoted context omitted.

A language that uses archaic syntax with dollar vars, semicolons, is pretty verbose itself may die before it evolves into something sensible. Not that I believe PHP will die any time soon, but just replying to your "slow is good".

There is no real producticity gain through not having semicolons and somewhat leaner syntax. That was never the bottleneck: ecosystem, libraries are.

There is a real productivity gain when you remove all things that cause a mental tax on reading. After Swift I don't want to look back at the C-like syntax languages any more (just that occasionally I have to).

Re: PHP in 2022

#242

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…

php is my language of choice, I love modern php, but I struggle with the same question. As a language, I think php is great, and for a solo project it is an obvious choice for me because of my proficiency and the quality of the language... but would I start a greenfield project with php? No. I've worked across a variety of different companies and a consistent theme is the existence of "php developers" in these compan…

I completely agree with this but I avoided mentioning it as I wanted to get some objective technical answers, decoupled from any of the usual operational concerns: number of people, mindset of people, seniority, etc.

I think the main cause is the low barrier for entry. It's great that anyone can get started quickly and be successful but it also means that the resulting mess can be at a level that you rarely see in other stacks where the barrier for entry is a bit higher.

I can clearly see that the PHP ecosystem is there (mature libraries for mocks, tests, etc) but like you said, there are people that just don't care. The language and ecosystem evolved faster than a big chunk of the developer community and I don't think everybody will catch-up anytime soon, as old PHP code bases can still generate a nice revenue doing maintenance.

Re: PHP in 2022

#243

A lot of people here have mentioned Laravel. I think one of the key things about Laravel is that the creator, Taylor Otwell, is only focused on Laravel. Imagine if DHH didn't ever have Basecamp (or 37 Signals) and only focused on Rails and the Rails ecosystem. The Laravel team now has several full time employees working on making the entire Laravel experience as painless as it can be. Of course Taylor and the Laravel…

Yeah, curiously, I think Laravel is just getting started in a way. Taylor seems to have a superb vision about what it is that he wants to achieve with it and in what way, and I don't think the 'rest of us' have fully grasped the 'end-game', and what the implications will be.

I mean, he took the most popular, but somewhat 'not cool anymore' backend programming language with a huge pool of developers, and proceeded to build _the_ way to build server applications with it. If that's not strategic brilliance, I don't know what is.

EDIT: For context. My exposure to Laravel is jumping into some projects and becoming productive in a day without prior exposure to PHP. Largely due to superb documentation and the batteries included approach.

Re: PHP in 2022

#244

Hating on PHP almost feels like racism. All the arguments are biased or false. I always get sad after clicking on PHP articles on HN.

You're perhaps joking, but victims of actual racism might not think that's funny.

I'm not joking and it's not supposed to bu funny. It's supposed to be confrontating.

Example: Someone saw some bad PHP code once in their lives and think all PHP code is bad. They saw someone say bad things about PHP so they think all PHP is bad. Or they think PHP is bad because they don't like how it looks.

Re: PHP in 2022

#245

Earlier quoted context omitted.

I've wondered why there's no JSON-based equivalent of SQLite, like "MongoDB but it's just a file and a library."

But ... SQLite is "just a file and a library".

Yes, but it's SQL. Some people want a "document database" that looks more like JSON. (Yes, I know you can store JSON in SQLite.)

Re: PHP in 2022

#246
post #66

Earlier quoted context omitted.

Wordpress is a complex project, but its backend does not require any background processing.

It does, even Wordpress has a cronjob - scheduled publishes, UGC postprocessing, IP ban expirations, there's a lot going on behind the scene.

Don’t they trigger when a user opens a page?

Re: PHP in 2022

#247
post #70
post #9

Is it just me or PHP's evolution is a bit "too little, too late" for an almost 30-years old language? PHP is not a likable language but it's probably not going away any time soon. Its concept of "one endpoint is one script" is one of its biggest killer features that no other language has been able to deploy in such an accessible manner. Well, Perl and old-style CGI aside, of course. That, and also the fact that it ma…

Its concept of "one endpoint is one script" is one of its biggest killer features Is that still a thing in PHP world? I recently ended up working on a 'modern' PHP project using Laravel and it was all routers and views and models and auto-generated scaffolding code, just like Rails and Django. There was no sign left of that 'old' approach.

There's a lot of popular examples of more or less abandoning the old ways, but the old ways still work.

I'm of the strong opinion that modern PHP with frameworks and auto-include and a ton of modelling is the wrong way to do it, but everyone else can do it that way, and I can still do things the old way and I can be happy.

PHP has this amazingly zen model of computing. At the end of the request, everything is thrown away to start fresh. This means anything you don't output is garbage. I don't think it makes a lot of sense to make sculptural models of your data and page structure only to throw them away. It's best to keep things simple.

There's some times and places where it makes sense to use more features, but starting with a kitchen sink framework makes it very hard to get simple where it's needed, but you can always pull in a little bit of something more complex into a simple thing.

Re: PHP in 2022

#248

A lot of people here have mentioned Laravel. I think one of the key things about Laravel is that the creator, Taylor Otwell, is only focused on Laravel. Imagine if DHH didn't ever have Basecamp (or 37 Signals) and only focused on Rails and the Rails ecosystem. The Laravel team now has several full time employees working on making the entire Laravel experience as painless as it can be. Of course Taylor and the Laravel…

What somewhat more interesting is the marketplaces surrounding some of these. There's a marketplace of nova add-ons, some free, some paid.

Some of these are definitely given more love than others, of course. I'd probably pay for some extended 'dusk' package to provide a better experience overall, but... unsure there's enough of a market to justify that?

I recently learned that the 'envoy' stuff is already free in Laravel - envoyer seems to be a hosted SaaS built with it, but you can define your own 'envoy' stuff to run however you want. https://laravel.com/docs/8.x/envoy

Re: PHP in 2022

#249
As long as wordpress still holds 40% of the sites PHP will be a major language.

In my opinion, all the modern 'script' languages are now adding static-typing one way or another, to make they much robust(python's mypy, typescript,PHP, etc).

I will pick PHP for backend website development, I just want to avoid the async-node-js as much as I can as it's much worse than other options I feel.

Re: PHP in 2022

#250
post #205

Earlier quoted context omitted.

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 inf…

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