Hacker News new | ask | show | jobs
by tentacleuno 1670 days ago
> People seem to love to hate it because it's the "cool" thing to do.

While I agree with this, I think the tone is slightly dismissive. From what I have seen, older people in our trade seem to recommend against PHP due to it having a terrible relationship with consistency, functionality, performance, etc. in its history. Though I have (thankfully) seen that the language and its standard library has undergone several large improvements, which is great to hear.

> Yet PHP developers continue to ship things faster, while JS devs are probably still fiddling with their Node environment setup...

On your point of JavaScript, the build environment nonsense can definitely get hairy. It's why we get things like Deno, which attempt to throw all this cruft away and start again. And sometimes that's a good idea. If you're dedicated to Node, replacing Webpack with Rollup seems to be what is generally recommended. The only obvious disadvantage there is compatibility with Webpack plugins.

It would be nice to have a type-checked JavaScript variant with a practically non-existent build environment (no Webpack, Rollup, etc.) As much as I adore TypeScript, the compiler itself is massive and takes quite a long time to even start.

2 comments

> From what I have seen, older people in our trade seem to recommend against PHP due to it having a terrible relationship with consistency, functionality, performance,

As an older person in the trade, I don't agree with the other older persons. Only consistency is a problem with PHP code, and that is largely NOT caused by PHP. Inconsistency is the product of developers coding without any real thought about how to abstract things (ok, well, maybe not in the case of magic strings). You can do this with every language. Some languages do everything possible to force consistency, and developer still find a way to be delightfully inconsistent even with the syntactic equivilent of bowling gutter bumpers (see Cobol, Go, Java). Consistency is a developer problem. You can write great code in languages that are terrible.

PHP has never been slow (compared to other dynamic languages), or lacked functionality. If there is a rub on PHP it comes from no separation of code and presentation, which flew in the face of the MVC pattern which was THE WAY for a very long time. Now... well, JSX much? Anyhow, my team works with Go, JS, PHP and Python, and the code that takes the least effort to both extend and maintain is... the PHP.

I am honestly and truly trying my absolute best, but no matter how hard I try, I again and again completely fail to sufficiently and comprehensively put into meaningful words how the inconsistency of the PHP language doesn’t play a role AT ALL when building actual web applications for actual users.

It just. Doesn’t. Matter. Choose Symfony or Laravel, and you are in for a wonderful development experience, from setup to dependency management to architecture to implementation to testing to deployment – for certain kinds of projects it’s just perfect.

I agree with you, and it's super hard to explain. But if you have the right type of project requirements, Laravel is unbelievably great to work with. I love other languages more than PHP, but for a real world, client facing project that I want to be mostly hands off, Laravel would get my vote 9/10 times.
I think you've sufficiently and comprehensively put it into meaningful words above!

The truth is, those who care to use the language properly know this already. Those who wish to dismiss it always will, and this happens to be an easy angle of attack.

> It's why we get things like Deno, which attempt to throw all this cruft away and start again

Doubt. Your "something@v1.2.3" in Deno is no different than "something": "^1.2.3" in npm. The problems will appear when you update stuff.

The only thing benefiting deno currently is the clean slate and the lack of hacks (for now).

They are different, currently no Deno registries have dynamic version resolution (no greater than operator). Once you have locked in on a version you are in it for good unless you change it manually

However if the argument is: updating libraries break stuff, that is gonna happen every time in every language. There is no guarantee the next version will just work as the last one did