Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A look at modern PHP

lwn.net

Post reply on HN
Print view View original

111–120 of 610 posts

Re: A look at modern PHP

#111

Post by creshal »

leeshire wrote: post #107

so is PHP worth learning right now? and what is the job prospect looking like? if I study the language for the next few months what is the lickely scenario I will find a career in it.. I actually enjoy and like PHP unlike other people idk what it is about the languauge it looks fun and enjoyable to play with . Plus it's simple and easy opens doors to more complex languages later on down the road

> what is the job prospect looking like?

I hope you like working on legacy projects full of spaghetti code.

Re: A look at modern PHP

#112

Post by s1k3s »

The amount of misinformation, false claims and unsupported statements in this thread is mindblowing for the quality that I've been used to see on HN.

Here are some facts:

- Symfony was the backend framework with the most contributors in 2019 [1] (yes, out of any backend framework written in any language)

- PHP has more active contributors than it ever had [2]

- Laravel is one of the most used frameworks in the world [3]

Then I see statements like "PHP only exists today because of legacies being maintained". Can't provide stats on this, but neither can the people who make these statements. Might be just because I'm a PHP dev myself but I see a lot of new projects started with the above frameworks.

And last, people compare it to languages like Rust or Go since they consider those are "innovative". I hope everyone understands that a language is fit for a certain type of task. PHP was created for website development, and in that area neither Go or Rust are even close to matching it in terms of maturity.

I may be biased but for me, choosing php for a new project is a no-brianer. The only other 2 stacks to which I can compare it are the Spring stack of Java or .NET core, and except for these two I wouldn't seriously consider any other competitor for starting a new project. Unless, of course, that project is "for fun" and you want to experiment with new technologies.

[1] https://symfony.com/blog/symfony-was-the-backend-framework-w...

[2] https://github.com/php/php-src/pulse

[3] https://trends.builtwith.com/framework/Laravel

Re: A look at modern PHP

#113

Post by giantDinosaur »

mxschumacher wrote: post #97
luckylion wrote: post #73

Earlier quoted context omitted.

Another big bonus for PHP to me is: there are plenty of people who are comfortable with it. Most things aren't genius-scientist-required kind of things where you lock some genius in a room for eighteen months and they revolutionize the industry. Most things are pretty average and you just need somebody with a good understanding of the problem and experience to do them. You'll want plenty of those people to get things…

From a business perspective this might also translate into lower development costs and easier access to talent.

Generally lower quality talent. That's half the reason PHP got its abysmal reputation. Brilliant programmers using PHP must be annoyed that they're thusly tarnished. I suppose that's not so different from JS. To the flames with both of them, though, I find them genuinely depressing languages to work with.

Re: A look at modern PHP

#114

Post by creshal »

zozbot234 wrote: post #72
Narann wrote: post #51

Depicts language feature, PHP ecosystem is dying. For me, an example is latest MediaWiki syntax highlight extension dropped GeSHi (PHP) which is not updated anymore, to pygments (Python) using a sub process. I realized I have to drop MediaWiki because my host didn't expose PHP proc_open() feature. I don't even know where to start. A natively written syntax highlighter can be considered as an important brick in an eco…

Would it be feasible to write a PHP equivalent to emscripten, so that one could export software compiled from any frontend language (including, e.g. the WASM representation) as a php object that can be run directly by mod_php?

It should be possible, but I'm not sure if PHP has the kind of community drive behind it to make it a realistic option.

Or a necessary one – emscripten's main use case is "everyone has a browser", but there's very few PHP hosting offerings where you can't shell out and just run straight native code (in your own little isolated sandbox).

Re: A look at modern PHP

#115

Post by hu3 »

creshal wrote: post #105
fetbaffe wrote: post #100

Earlier quoted context omitted.

Wait, Go hasn’t had any revolutionary change since it arrived 10 years ago. It is still basically the same language/package. I’m not saying that is bad, but why does a language need to be constantly revolutionary if it solves what it sets out to solve well? Catch up to other languages? You can easily argue the opposite, that other languages has finally catched up to PHP, ease of deployment, ease of horizontal scaling…

> why does a language need to be constantly revolutionary if it solves what it sets out to solve well? That's a very big If in PHP's case.

If anything PHP is THE language that solves what it sets out to solve.

It does a few things and does them well.

Re: A look at modern PHP

#116

Post by ctas »

My startups running on PHP and I definitely don't regret it. The language is simple, you have easy access to talent, knowledge, and thousands of mature libraries. Most of the times boring is better.

Re: A look at modern PHP

#117

Post by simion314 »

nsomaru wrote: post #110
simion314 wrote: post #93

Earlier quoted context omitted.

Just curious what problem are you trying to solve, I never had the need for different threads to communicate in PHP, most of the time in my work a user makes a request, and a PHp scripts does something like update the database or does some searching/working and returns a result.

What if that request was a document upload and your system is calling out some external api or processing for long enough such that you’d rather return now and update later when the job finishes. Maybe through Ajax or a redirect. The shenanigans that WP plugin devs go through to get around the lack of a queue is ridiculous (chunk the file and keep reloading the page until we’ve processed all the chunks or have an Aja…

For that kind of problem we create a database table. then you schedule there your work tasks and background scripts will fetch jobs from the database and run them. This also works great if the third party is busy or fails, the background jobs are set to attempt a few times before giving up.

What solution would you prefer for this kind of jobs? launching a new thread directly? or have a worker project always running and send to it the job directly?

Re: A look at modern PHP

#118

Post by zozbot234 »

creshal wrote: post #114
zozbot234 wrote: post #72

Earlier quoted context omitted.

Would it be feasible to write a PHP equivalent to emscripten, so that one could export software compiled from any frontend language (including, e.g. the WASM representation) as a php object that can be run directly by mod_php?

It should be possible, but I'm not sure if PHP has the kind of community drive behind it to make it a realistic option. Or a necessary one – emscripten's main use case is "everyone has a browser", but there's very few PHP hosting offerings where you can't shell out and just run straight native code (in your own little isolated sandbox).

> shell out and just run straight native code (in your own little isolated sandbox)

Parent poster said that they couldn't do that on their host, though. Which breaks a MediaWiki feature (syntax highlighting for code blocks).

Re: A look at modern PHP

#119

Post by onli »

Okawari wrote: post #95
onli wrote: post #61

Earlier quoted context omitted.

> But with fewer people self-hosting these days, that has become less an advantage. I don't think fewer people self-host. There are some going to big clouds, there are some using integrated offerings like squarespace, but there are still many hosting their website with a regular hoster. And probably in total many more than in the past. > And even for those who do self-host, the advantage is becoming narrower as other…

I'll concede that PHP focused hosting solutions such as your traditional shared webpage hosting environment is better at hosting PHP than any other language, and sure there are less services out there that lets you deploy code "as easy as PHP". I had to check and I'm paying about 4$ a month for a traditional PHP server host vs 5$ for a VPS which I can run whatever I want on. And if you want a barebones deployment for…

It's not really a question of money, the VPS where you can do what you want can even be cheaper.

> And if you want a barebones deployment for lets say rails, what is stopping you from just copying files over with scp and running bundle and rails s from the shell.

I mean, it's not like I'm not doing that for myself. Even my PHP blog is not with a traditional hoster. But there are many things that can go wrong there - for the ruby example starting with the ruby versions, additional system dependencies. And then you need something to make the app restart after a reboot (supervisor is thankfully excellent), and probably a nginx in front of the webapp, and letsencrypt, and does your VPS take care of backups? Each task not impossible, but in total vastly more complex. Some users can handle that, many don't.

I just did some freelance work on a wordpress site (and I'm involved with a different PHP blog engine, serendipity), and it's so nice when the setup that those PHP projects present you with is clear and straightforward, and on top of that everything that might be complicated even a mediocre hoster had years to solve now.

Re: A look at modern PHP

#120

Post by rob74 »

frenchman99 wrote: post #38
Svip wrote: post #14

Even with PHP7, PHP still feels like it is playing catch up. There is nothing new or revolutionary in PHP7, just adopting features present in other major languages. Adopting as other newer languages like Go and Rust seems to be moving beyond those features. A catch up into a world that's on its way out, if one will feel so blunt. PHP's raison d'être remains its ease of getting an instance running on a webserver. But…

I remember reading about Ghost.org team members saying that if they had chosen PHP instead of Node.js when they got started, they'd be much further along in their roadmap [0]. PHP has a reliable ecosystem of 3rd libraries with LTS releases. I am not aware of something like Symfony [1] for Rust or Go. [0] https://www.indiehackers.com/podcast/007-john-onolan-of-ghos... [1] https://symfony.com/

Well yeah, if you would pick one technology that even PHP would compare favourably too, it would be Node... my thoughts on Node were always: just because Google built V8, which makes it possible to run JS fast enough to use it in the backend, doesn't mean that you have to do it.

Regarding frameworks: of course PHP has an advantage there, because it's a more mature ecosystem. But frameworks written in PHP like Symfony or Laravel tend to forget that they are based on a scripting language (which years of optimization have made very fast for a scripting language, but still), so using their features extensively will slow down your application...

Post reply on HN