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

Go with PHP

gowithphp.com

Post reply on HN
Print view View original

261–270 of 532 posts

Re: Go with PHP

#261

Post by gumballindie »

systemtest wrote: post #250
gumballindie wrote: post #155

Earlier quoted context omitted.

PHP has matured and has been a nice language for a decade now. But PHP developers havent. Cargo culting “good practice” and lack of creativity plagues the community. Frameworks have become so heavy that you spend more time configuring them than actually adding value. Oh and some still argue over setters and getters.

My experience is that if I join a team of PHP developers, there is a 40% chance of the team being professionals and writing good maintainable code. With Java, .NET and Python I would say 80%. C and C++ around 90%. This also reflects in their salaries.

That is my experience as well. A competent PHP developer can earn as much as developers for the languages you listed, but they are less frequent.

Re: Go with PHP

#262

Post by jjice »

keyle wrote: post #17

As a fullstack developer who has worked many, many years in the javascript hellhole, I mean ecosystem, as well as the python ecosystem and .NET; coming back to PHP the last 2 years, working essentially in Laravel and the like - I couldn't approve more of this message. Seriously, PHP is the grand father that will drive you to class and you'll never be late, the car will never smell and everything will always just be f…

I agree that PHP is a fine language these days, if using modern features and techniques. I've seen plenty of recently written PHP that looks like it was written in 1997.

That said, PHP does have complexity to running like node does with pm2, Apache or Nginx in front. Is it as bad, depends on the person, but it does suck IMO.

Re: Go with PHP

#263

Post by ki_ »

berkle4455 wrote: post #83
kgeist wrote: post #57

Earlier quoted context omitted.

I agree, the main problem with PHP in my experience so far has been that it's very memory-hungry and slow (even PHP7/8), especially when coupled with frameworks/ORM magic. I remember after spending some time with Go, I got used to being able to process tens of thousands objects in memory in milliseconds. When I proposed to do the same in PHP, during architecture review, PHP devs thought I'm out of my mind because tha…

You're doing something terribly wrong. Sounds like caching isn't setup and your http -> php handler is cold booting the interpreter for every single request. Check these Go vs. PHP benchmarks. PHP is quite fast and stands up nicely to the performance you get out of Go. https://www.techempower.com/benchmarks/#section=data-r21&l=z...

All i see is that the php fpm based frameworks (e.g. laravel) are 100x - 300x slower. And this is the best case scenario. When projects grow, php-fpm gets slower and slower. Which is not the case for go. Im not a go-fanboy, my entire carreer has been in PHP. Im just saying, PHP is one of the most terrible languages for web servers. And it's all php-fpm's fault. On top of that, the PHP community seems to promote OOP and SOLID which are the last design patterns you want to combine with php-fpm. There's a reason why facebook created their own PHP transpiler.

Re: Go with PHP

#264

Post by minusf »

BulgarianIdiot wrote: post #197
simonhamp wrote: post #176

Earlier quoted context omitted.

Making "complex tasks seem readable and intuitive to the layman" is no bad thing - besides other engineers, future you could become a 'layman' easily. Readable, expressive code is something I've come to value highly after almost 20 years And from first-hand experience, while the specific code sample shown on this page shouldn't be treated as a practical example of how to architect a larger application, there's nothin…

I guess I wasn't clear enough? I said "it makes complex tasks SEEM". My point being, they SEEM SIMPLE in a DEMO. But in real application it quickly turns into a quagmire, due to the problems I already listed. Oh look, you even say so in your own comment: "the specific code sample shown on this page shouldn't be treated as a practical example". So... you're saying the page makes it SEEM simpler than IT IS, hmm? Is thi…

    5 + 5 =
why use echo? php _is_ html :D

Re: Go with PHP

#265

Post by simonhamp »

omnimus wrote: post #190
simonhamp wrote: post #142

If you're looking for a great CMS and were bitten by WordPress back in the day, you should take a look at Statamic ( https://statamic.com ) It's a Laravel package and it's the best CMS I've ever used (from a dev perspective). v4 just dropped the other day

PHP has a lot of top tier CMSes. IMHO bunch of them are even better than Statamic. Craft CMS ( https://craftcms.com/ ) is a lot more mature database based CMS. Kirby ( https://getkirby.com/ ) is better at flat-file and has a lot better admin interface. Twill ( https://twillcms.com/ ) is better integrated in Laravel and is fully open-source. Statamic mostly feels like it's sitting besides Laravel and they call themsel…

You're absolutely right! PHP is blessed (or maybe cursed, depeding on your perspective) for that.

I believe Craft and Statamic share a root in ExpressionEngine, which I loved also. I've only used Craft a little bit, for me the biggest issue is that it is (or was when I last looked) built on Yii, which isn't my go-to framework in PHP.

This is in no way a showstopper.

I haven't used Kirby, but it looks like a completely stand-alone application so I'm going to miss being able to co-locate the rest of my application there with the full toolset of the framework behind, which for small sites I really appreciate about Laravel+Statamic having right out of the gate.

I've also not used Twill, but it looks to be similar to Statamic (as it's also a package). Not sure how this can be more open source than Statamic tho... if you mean free as in price, I'm all for paying for great products to make sure the teams behind them can keep on churning out great work. I'm sure AREA 17 will keep supporting Twill for a long time to come, but it doesn't look to be the focus of their business.

I'm also intrigued to know what you mean by "better at flat-file".

UX of the admin interfaces is kinda subjective and less of a concern from a dev perspective (though it's still an important consideration if you're trying to pick the right tool for a client or another team!)

> they call themselves Laravel based for marketing

Same goes for Twill :) nothing wrong with hanging onto the coattails of a popular piece of tech

AFAIK Statamic wasn't built on Laravel at all in the beginning. I believe Jack adopted it because it was clearly a great stack to build on top of. I think he made a great choice and I'm glad of it.

Re: Go with PHP

#266

Post by gumballindie »

matheusmoreira wrote: post #255
gumballindie wrote: post #155

Earlier quoted context omitted.

PHP has matured and has been a nice language for a decade now. But PHP developers havent. Cargo culting “good practice” and lack of creativity plagues the community. Frameworks have become so heavy that you spend more time configuring them than actually adding value. Oh and some still argue over setters and getters.

> PHP has matured and has been a nice language for a decade now. And how did it manage that? Python forced people to deal with encodings properly and the result was a lot of pain. You're claiming PHP somehow invisibly fixed the numerous problems of the language without anybody noticing? That "fractal of bad design" blog post, everything described in it has been fixed? If so I want to learn how they did it. That's som…

Encodings are a non issue in PHP and the availability of web tools is much wider in php than for python. PHP matured in the sense that it from a wordpress type of hacky language to an almost decent language. It can be used properly if you know what you are doing (ie can scale really well for the web, can be secure, allows for good oop design, can be fast _for the web_, and has a wide range of supported packages, separation of concerns and so on).

Re: Go with PHP

#267

Post by dgb23 »

muglug wrote: post #58
makeitdouble wrote: post #40

Earlier quoted context omitted.

> it's typed (now) To note, you'll need strict mode for type hints to be useful. https://www.php.net/manual/en/language.types.declarations.ph... The fun part is, instead of going for a generic strict mode system we would have expected, PHP went pragmatic: as most application won't be 100% strict typed, you need to declare it file by file, the icing on the cake being that the restriction applies on the caller of the f…

> To note, you'll need strict mode for type hints to be useful This is not really true — those type hints can be read by static analysis tools, preventing you from many of the issues that would also be caught in strict mode at runtime.

The type system isn’t expressive enough for these tools to catch anything but the most basic errors.

In PHP, typing is for function signature documentation.

Re: Go with PHP

#268

Post by ptx »

deanc wrote: post #198
Flimm wrote: post #188

Earlier quoted context omitted.

You do get XSS protection out of the box in most templating languages, though, and PHP is also a templating language. Take this template: {{ title }} In most templating languages, for a title of " alert(); ", the result will end up being: <script>alert();</script> In PHP, which is a templating language, the equivalent seems to be: But this will print the title unescaped, which is a security vulnerability,…

Templating languages are abstractions on top of other technologies. I don't see how PHP is a templating language. I could write that exact same code above in NodeJS and I'd need to use mustache to escape the output. So you can make the same mistakes in Node, Python. Nobody writes PHP mixing HTML and PHP anymore, and if you do you should run. Shit code is not unique to PHP and I've seen more than my life's share in JS…

> I don't see how PHP is a templating language [...] Nobody writes PHP mixing HTML and PHP anymore

PHP is designed to be a template language, but it's a terrible template language, so nobody (it is claimed) uses it as it was originally designed to be used anymore.

So "use PHP" is not good advice if what you mean is "use a web framework and a separate third-party template language", which works just as well in any language and doesn't give PHP any particular advantage.

Re: Go with PHP

#270

Post by languagehacker »

I am an erstwhile PHP apologist. Having come back to PHP after a long time away (not really by choice), I can confirm that the language has improved significantly since PHP5. PSR was a huge success in a lot of ways. However there are still a few things that prevent it from being my language of choice.

First off, there is a surprising number of core behaviors you'd expect from a modern web application that there isn't a clear go-to for in the PHP world. Does anyone know of a well maintained library for publishing and consuming AMQP messages asynchronously?

PHP is still limited by living inside of the context of the request. This has an effect on certain types of application-layer caching, and makes for a poor model for backend scripting.

You also still need to interact with multiple layers of dependency management -- from os packages to pear packages to composer libraries. Configuration can be messy, and many projects still aren't containerized.

Finally, while the language has evolved, many of the projects that use it have not. The longer lived the PHP project, the more likely you are to encounter the exact paradigms that make it so hard to work with. Other languages have benefitted from a much greater percentage of their lifespan being supported by ecosystems that encouraged keeping your dependencies and the parts of your code that exercise them up to date.

That being said, it's great to see that there is a path for starting new projects with a modern framework. But I would have said the same thing about Zend or Symfony, and those seem to have fallen off for reasons I don't know.

Post reply on HN