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

PHP in 2022

stitcher.io

Post reply on HN
Print view View original

271–280 of 318 posts

Re: PHP in 2022

#271

Post by mountainriver »

m4l3x wrote: 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.

Yeah not sure why anyone would use PHP nowadays, you can be as productive and more efficient in Go.

Plus you can build just about anything with Go! Whereas PHP is pretty strictly for web development.

Re: PHP in 2022

#272

Post by captn3m0 »

fart32 wrote: post #265
captn3m0 wrote: post #226

Earlier quoted context omitted.

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.

Yes, I saw similar numbers (just not in empty projects, but I'm not familiar with Laravel/Lumen - there might have been a good reason for it). The point is that Composer packages are far from being that granular, we have less dependencies by literally order of magnitude.

I think a better measure really is lines of code. A comparison with react is _very unfair to laravel/rails_, with laravel being a full-featured framework, and yet react is still much worse:

laravel/framework:

  no-dev-deps: 307,405 lines of PHP (36MB)

  all-deps: 535,383 lines of PHP (58MB)
react (stock create-react-app)[1]

  all-deps: 1,570,720 lines of Javascript + 96417 lines of typescript (348MB)
rails (rails new app):

  (no-dev-deps): 264123 lines of Ruby + 23614 lines of C + 17009 lines of JS (55MB)

  (all-deps): 332083 lines of Ruby + 23614 lines of C + 18055 lines of JS (54MB)
Here's the raw results: https://www.toptal.com/developers/hastebin/osujizeraw.txt

[1]: create-react-app doesn't split out dev/prod dependencies https://stackoverflow.com/a/44872787/368328

Re: PHP in 2022

#273

Post by sodapopcan »

midrus wrote: post #238
sodapopcan wrote: post #220

Earlier quoted context omitted.

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?)

Re: PHP in 2022

#274

Post by Spivak »

lghh wrote: post #258
dncornholio wrote: post #233

Earlier quoted context omitted.

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.

Setting up a database takes way longer than 10 minutes. Data can be teeny tiny. Data can not be performance critical. You literally know nothing about the commenter’s application.

"I just want to serve five kilobytes of data."

Re: PHP in 2022

#275

Post by [deleted] »

lghh wrote: post #258
dncornholio wrote: post #233

Earlier quoted context omitted.

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.

Setting up a database takes way longer than 10 minutes. Data can be teeny tiny. Data can not be performance critical. You literally know nothing about the commenter’s application.

[deleted]

Re: PHP in 2022

#276

Post by chefandy »

heurisko wrote: post #222
chefandy wrote: post #157

Earlier quoted context omitted.

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

Categorically better for everything and not categorically better for everything you write?

How about for the type of task PHP is often used for? A nearly default CRUD web app w/loads of fields and tables? Rapid prototyping? How about a bunch of simple, standalone interface interactions in JS? The extra grammar won't provide much architectural or conceptual clarity in those super common coding tasks because they're already dead simple, or in the case of the rapid prototype, don't need to be durable. Most data transformation— e.g. from the database into hashes— is taken care of by worn-smooth libraries that won't likely cock things up. For these tasks, front-loading complexity for little subsequent benefit is a questionable choice. Maybe you're so used to working with types that you're just as fast,time isn't a factor? Great. If you're not, or another developer you're working with isn't, and time is tight, it's probably a bad choice.

What many of these systems are starting to offer is the option of adding type hinting which is exactly what they should be doing. Python's type hints have been great in a new nontrivial project I'm putting together with multiple developers. If I had to use them for every bit of disposable utility script I write and every little prototype proof-of-concept I stand up then I'd be much less productive.

I reckon skipping situation-specific cost/benefit analysis before asserting something is always better is definitely dogma. ¯\_(ツ)_/¯

Re: PHP in 2022

#277

Post by dehrmann »

hmottestad wrote: post #11

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. If you depend on any third-party APIs, this can be a big deal for performance.

Re: PHP in 2022

#278

Post by rejn »

dncornholio wrote: post #81

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.

Wait, what, really? PHP has come a long way, but is still littered with bad design, weird syntax and trying to be a bad Java with no threads and worse scalability.

Re: PHP in 2022

#279

Post by cutler »

heurisko wrote: post #45
cntainer wrote: post #21

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…

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

This static-for-everything trend is absurd. Compiling one-off scripts? Give me a break - they're not called scripting languages for nothing.

Re: PHP in 2022

#280

Post by jbboehr »

xgb84j wrote: post #240
y4mi wrote: post #159

Earlier quoted context omitted.

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

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…

AFAICT, that behavior was fixed with the release of PHP 7.1 in 2016.
Post reply on HN