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

PHP – The Right Way

phptherightway.com

Post reply on HN
Print view View original

271–280 of 349 posts

Re: PHP – The Right Way

#271

Post by throwtcp5327 »

Just wanna dump a bunch of similar PHP sites you might find useful:

(The only proper) PDO tutorial: https://phpdelusions.net/pdo/

Organize a php project according to industry best practice: https://github.com/thephpleague/skeleton

PHP Best Practices - A short, practical guide for common and confusing PHP tasks: https://phpbestpractices.org/

Modern PHP Cheat Sheet - A to-the-point summary of all awesome PHP features: https://front-line-php.com/cheat-sheet

Laravel, PHP, JavaScript: https://freek.dev/

PHP security: https://paragonie.com/blog

Re: PHP – The Right Way

#272

Post by haolez »

Slightly of topic, but is Hack a thing outside of Facebook? I'm a little thrown off by the confusing standard library of PHP, but I don't know if using Hack instead would solve more problems than it creates.

Re: PHP – The Right Way

#273

Post by heurisko »

sshine wrote: post #75
sdze wrote: post #15

Earlier quoted context omitted.

PHP still has a vibrant ecosystem. 1) cost 2) simplicity 3) scalability With the advent of Chinese frameworks that solve C1000K problems like swoole, workerman and so on it even found its place as high performance interactive backend server.

I spent the better part of 2021 porting a PHP app to Kubernetes. If there’s one thing PHP is not, it is performant.

PHP is performant compared to other similar scripting languages, and in any case, the database is usually the bottleneck.

If you look at the "multiple queries" results of the web framework benchmarks, you'll notice that the frameworks that use blocking database drivers have similar numbers e.g. raw Symfony is 13,543, whilst Spring is 15,979, despite the JRE being much, much faster.

https://www.techempower.com/benchmarks/#section=data-r20&hw=...

Re: PHP – The Right Way

#274

Post by 9dev »

inoop wrote: post #262
9dev wrote: post #252

Earlier quoted context omitted.

But in fact the semantics did not change within the minor revision boundary. This was an ordinary deprecation process, as it should be. Emitting a warning is not breaking anything!

> did not change within the minor revision boundary I'm confused, are you saying it's fine to change core language semantics as long as it's across major version boundaries? How the hell is that better? No other reasonable language does this.

That's precisely what I'm saying: The whole purpose of a major version is to indicate breaking changes. That applies to Go too, for example (talking of reasonable languages...). That PHP ever allowed count()-ing uncountable things is effectively a bug in the standard library.

What happened is that a depreciation was put into place, and in the next major version that depreciation was converted to an error. Just how it should have happened.

On the one hand, people complain about PHP having weird standard library functions and lots of cruft, on the other they complain once things are changed slowly. I don't get it.

Re: PHP – The Right Way

#275

Post by inoop »

dotancohen wrote: post #270
inoop wrote: post #254

Earlier quoted context omitted.

> Downside JVM is a Resource hog The fuck are you smoking? The JVM is one of the most mature, resource efficient, and fast language runtimes out there. See, this is why nobody can take you people seriously.

If you're conversing with someone who believes that the JVM is a resource hog, then you are likely conversing with someone with decades of experience. I would phrase my opposing viewpoint in a more respectable manner, as you might have a lot to learn from someone like that.

> If you're conversing with someone who believes that the JVM is a resource hog, then you are likely conversing with someone with decades of experience

As someone who has actually read the JVM specifications many times, has actively worked on a JVM implementation, and has a pretty good grasp on virtual machine design, I beg to differ.

But hey, I'll take the bait, what makes you think the JVM is a 'resource hog'?

Re: PHP – The Right Way

#276

Post by inoop »

dotancohen wrote: post #267
inoop wrote: post #262

Earlier quoted context omitted.

> did not change within the minor revision boundary I'm confused, are you saying it's fine to change core language semantics as long as it's across major version boundaries? How the hell is that better? No other reasonable language does this.

Just wait until you upgrade to Python 3!

The Python 3.x change was a disaster, and perfectly illustrates the point I'm making here.

PHP should learn from that, instead of trying to repeat it (in slow motion)

Re: PHP – The Right Way

#277

Post by osrec »

berkes wrote: post #149
osrec wrote: post #137

Earlier quoted context omitted.

It looks like your projects employed PHP poorly. PHP has been great for my company and my developers. We have never had to face such grave consequences because of it, and we've employed it in companies generating millions of $ of revenue. I will pick it over any other interpreted language.

Certainly. One mistake was that PHP was chosen, when it really was unfit for the task at hand. Another one was that CMSes like WP or Drupal were shoehorned into projects that were really unfit for them. etc. But also being unable to upgrade underlying PHP versions due to breaking changes, or just p*ss-poor, bug-ridden PEAR packages. As well as the language design prohibiting proper TDD, isolation, etc. I explicitly s…

I would imagine that your team picking WP or Drupal and attempting to shoehorn in your use case had more to do with your projects failing than PHP itself.

I see that happen a lot in the wild, and not just with PHP.

I bet you could have picked a python/node/c#/go CMS with a similar outcome.

Re: PHP – The Right Way

#278

Post by aarondf »

cies wrote: post #186
jonwinstanley wrote: post #161

Earlier quoted context omitted.

The main comparisons I have are building sites with Ruby/Rails and doing JS front ends attached to REST APIs. All three types of project have their own pros and cons.

The fair comparison: PHP/Laravel to Ruby/Rails... How is PHP/Laravel better? I'm of the opinion it loses hard in every aspect.

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 team have paid products, but they are all 100% focused on the Laravel ecosystem and developer experience!

Some of the things that the Laravel ecosystem has as first party packages / services:

Paid:

• Vapor - Serverless Platform. Run your vanilla Laravel apps on Lambda.

• Forge - Server Management. Builds Laravel ready servers on any cloud.

• Envoyer - Zero Downtime Deployment. Deploy your apps with push-to-deploy.

• Nova - Administration Panel. Completely code-driven admin panels.

• Spark - SaaS App Scaffolding. Basically a SaaS starter kit.

Free:

• Horizon - Queue Monitoring. Like Sidekiq

• Jetstream - App Scaffolding. SaaS starter kit with teams, invitations, api, etc.

• Echo - Realtime Events. Think Pusher, Socket.io, etc.

• Sail - Local Docker environment.

• Valet - Dev Environment for Macs.

• Mix - Webpack Asset Compilation. A sane wrapper around webpack.

• Cashier - Subscription Billing Integration. Stripe + Paddle.

• Dusk - Browser Testing and Automation. First party browser automation for tests.

• Sanctum - API / Mobile Authentication.

• Laravel Scout - Full-Text Search. Wrapper around Algolia, Melisearch, or full-text database searching

• Socialite - OAuth Authentication. Log in with GitHub, Google, etc. Dozens of community packages as well.

• Telescope - Debug Assistant.

That's all first party. It's unbelievable to me how many batteries are included. Then you start looking at the surrounding ecosystem beyond that and it gets even crazier.

Laravel as a community is an extremely welcoming place, and I have found that most people care deeply about their code and architecture, but don't pick each other to death on details that don't matter. I think all in all it's a pretty pragmatic group.

Re: PHP – The Right Way

#279

Post by mkdirp »

thinkindie wrote: post #218
cies wrote: post #184

Earlier quoted context omitted.

So compared to JS and $DYNAMICALLY_TYPED_LANG, PHP is "decent these days". These languages all suffer from very similar problems. Compare to C#/MVC.net, Kotlin/whatever, Go, Rust to get something noteworthy.

At least for Go and Rust, they have a much steeper learning curve. If you are a startup with limited funds you are not able to target engineers workings with those languages. If it's just a matter of speed, PHP already is good enough for the great majority of cases. The bottleneck is the data layer, usually. If your problem is being faster than the latest versions of PHP can achieve, you can certainly look for Go/Kot…

> At least for Go and Rust, they have a much steeper learning curve.

Yes for rust, not really for Go. I was able to pick up the basics of Go in less than a day, and the more advanced topics I was able to pick up not long after. OTOH I've tried to pick up Rust several times, and every time I just sit back in defeat.

> should we talk about how dependencies are managed in Go?

I'm curious what you're referring to here. Go's package management works, and is decent enough. No centralisation, and can work with just about any git repo.

Re: PHP – The Right Way

#280

Post by pak9rabid »

hooby wrote: post #258

It's a decent website - a useful collection of information and links to additional information, that can serve as a starting point to learn more. For those who use PHP, or for those who'd like to learn to use it, this might be useful resource. The same thing can't really be said of the comments in here though. I don't see how emotionally charged debates over what is the "best" or "worst" language, help anyone. It's a…

In its early days (version 4 and below) PHP was a bit of a mess. However it got its act together with version 5, as it implemented an object model almost on par with Java's, which I thought kind of set the standard for how OOP should be done. It's just unfortunate that much of the mistakes with version 4 and below had to be kept in order to preserve backwards compatibility.
Post reply on HN