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

Moving from Go to PHP Again

dannyvankooten.com

Post reply on HN
Print view View original

161–170 of 371 posts

Re: Moving from Go to PHP Again

#161

Post by kalmi10 »

realharo wrote: post #148
trixie_ wrote: post #13

Each PHP file is an endpoint. As opposed to having routers in code or client side SPA routing. PHP files can be deployed independently, swapped out or updated live. No building/compiling of the php files needed. A single layer as opposed to 'modern architecture' where there's client side back/front end layers, api layer, logic, validator, data access, and ORM layers. Can extend itself as it runs. For example Wordpres…

>Each PHP file is an endpoint. As opposed to having routers in code or client side SPA routing. The vast majority of PHP frameworks, even micro-frameworks, don't work that way. They route all traffic (except static assets) to an `index.php`, which then forwards it to a regular router.

.. so you can live swap routes and endpoints even with dynamic routing (without performing any hot-reload dance in your own code), which actually sounds like a neat feature at first.

Re: Moving from Go to PHP Again

#162

Post by esistgut »

pasta wrote: post #68

I agree with the author. Symfony 4 is the best PHP framework at the moment. Trying both Laravel and Symfony I think there is no need for Laravel (anymore). Laravel just has too much magic that will bite you later on. The only thing you should skip in both frameworks are 'annotations'. But this is easy to do.

> The only thing you should skip in both frameworks are 'annotations'. But this is easy to do.

If you are using Doctrine the only alternative to docblock annotations is XML because they are deprecating YAML support. I really hope they build support in the language itself. I can't understand their fierce opposition to a feature every other major object oriented language has. They are only forcing a large part of the ecosystem, everything that is Symfony or Doctrine based, to use the horrible docblock work around.

Re: Moving from Go to PHP Again

#163

Post by DCoder »

Aeolun wrote: post #138
pasta wrote: post #109

Earlier quoted context omitted.

Even if this will be integrated I still think it might be a bad idea for some things because it goes into the separation of concerns principle. A controller should not know about routes. A model should not know about database design.

Unless you want to write a ton of transformers, your models will likely know about your database design. If only by virtue of having the same properties.

I think the parent is objecting to the fact that annotations spray this "external" information right in the middle of the controller/model. FWIW, decent tools let you put this info in separate configuration files instead of code annotations, "decoupling" it from the code.

Re: Moving from Go to PHP Again

#164

Post by mnutt »

viraptor wrote: post #60
trixie_ wrote: post #13

Each PHP file is an endpoint. As opposed to having routers in code or client side SPA routing. PHP files can be deployed independently, swapped out or updated live. No building/compiling of the php files needed. A single layer as opposed to 'modern architecture' where there's client side back/front end layers, api layer, logic, validator, data access, and ORM layers. Can extend itself as it runs. For example Wordpres…

> Each PHP file is an endpoint. As opposed to having routers in code or client side SPA routing. Which becomes a security issue due to accidental endpoints or uploads becoming endpoints. Or becomes a mess of imports. Either way, PHP frameworks often end up with a central router anyway. > PHP files can be deployed independently, swapped out or updated live. Which means some people try to do that the naive way and end…

Even worse, Tumblr had an incident where they accidentally changed https://news.ycombinator.com/item?id=2343351

It would have been possible for tumblr to avoid this with good development practices (don’t edit code live, don’t bake credentials into code, etc) but I imagine there was a culture of doing it at the time.

I don’t think it’s fair to tell developers “use our language, it’s super easy!” and then expect them to discard all of those bad habits as they start putting things in production.

Re: Moving from Go to PHP Again

#165

Post by DCoder »

bunnybender wrote: post #88
n1c wrote: post #42

Earlier quoted context omitted.

PHP Static Analysis Tool ( https://github.com/phpstan/phpstan ) is pretty good at surfacing that kind of thing.

Phan ( https://github.com/phan/phan ) is another one. Other potentially useful tools: - PHP_CodeSniffer ( https://github.com/squizlabs/PHP_CodeSniffer ) - GrumPHP ( https://github.com/phpro/grumphp ) - PHP Mess Detector ( https://phpmd.org/ )

There's also Vimeo's Psalm [0].

[0]: https://github.com/vimeo/psalm

Re: Moving from Go to PHP Again

#166

Post by 1_player »

elcomet wrote: post #116
sfteus wrote: post #43

Earlier quoted context omitted.

To keep it simple, it was originally created as sort of a helper instead of a full-fledged language, and just kind of grew into that. As such, its early years were plagued with architecture, security and performance issues, as well as many "gotchas" that could wreak havoc on amateur programmers that tended to gravitate to the language. Couple that with the fact that the maintainers drug their feet in implementing mod…

This sounds a lot like JavaScript

Gotchas in Javascript are syntactic/semantic, because there's no standard library worth its name bundled with it.

PHP's gotchas are syntactic/semantic but mostly on its huge standard library, which is an haphazard collection of functions from sending emails to parsing ID3 tags from MP3 files.

EDIT: JS, as the legend says, was written in 10 days, while PHP grew without much long term vision for years.

Re: Moving from Go to PHP Again

#167

Post by _0w8t »

combatentropy wrote: post #36
trixie_ wrote: post #13

Each PHP file is an endpoint. As opposed to having routers in code or client side SPA routing. PHP files can be deployed independently, swapped out or updated live. No building/compiling of the php files needed. A single layer as opposed to 'modern architecture' where there's client side back/front end layers, api layer, logic, validator, data access, and ORM layers. Can extend itself as it runs. For example Wordpres…

Apache MultiViews makes pretty URLs easy. www.example.com/widgets.php can be reached at: www.example.com/widgets But here's the kicker: www.examples.com/widgets/123 will also route to widgets.php, with "/123" in the $_SERVER['PATH_INFO']. No mod_rewrite needed. www.example.com/widgets/you/can/have/multi-segment/paths goes to widgets.php too, with its PATH_INFO set to "/you/can/have/multi-segment/paths", but I don't u…

nginx can also do it for any FCGI script.

Re: Moving from Go to PHP Again

#169

Post by sandreas »

ddtaylor wrote: post #107
sandreas wrote: post #105

Well comparing Go and PHP is kind of difficult, because they are targeting completely different goals. After some years of development, both languages have evolved a lot and they both can be used for many other things, that they haven't been designed for. PHP was a dynamically typed scripting language to build personal homepages (Personal Home Page Tools). Today it is an object oriented, type hinted language that sup…

> - the "callable" concept - call_user_func_array(["object", "method"]) For at nearly 10 years now PHP has had support for lambdas, meaning for most uses `$foo()` can be used instead and with the inclusion of the spread operator it's seldom used.

With the "callable" concept i meant, that many things are seen as callable:

[$obj, "methodName"] => callable for $obj->methodName()

"str_replace" => callable for function "str_replace"

["ClassName", "staticMethod"] => callable for ClassName::staticMethod()

"ClassName::staticMethod" => callable for ClassName::staticMethod()

function() {} => callable for a lambda

I would prefer a "ClassMethod" and a "Function" type, instead of using strings.

$x = phpinfo; $x();

$y = $obj->method; $y();

But i don't think, this is possible, because PHP supports global constants and function names cannot be distinguished from constants, especially because PHP is not case sensitive regarding functions and classnames.

But I see, that my karma has decreased with this post, so it seems, that not many are in my opinion...

Re: Moving from Go to PHP Again

#170

Post by weberc2 »

vhakulinen wrote: post #82
trixie_ wrote: post #13

Each PHP file is an endpoint. As opposed to having routers in code or client side SPA routing. PHP files can be deployed independently, swapped out or updated live. No building/compiling of the php files needed. A single layer as opposed to 'modern architecture' where there's client side back/front end layers, api layer, logic, validator, data access, and ORM layers. Can extend itself as it runs. For example Wordpres…

> For example Wordpress, running off of php files can download plugins to its own server (which are just more php files) to instantly extend itself. Without restarting or redeployment. (What other web platforms can do this?) I'm quite sure you can achieve this in golang with plugins[1]. That not as flexable as PHP, mainly because it involves a static type system and a compile phase (and more work in general). 1: http…

Yeah, running plugins is not a difficult problem in most languages; it isn’t widely practiced outside of the PHP community because most folks don’t want to be the reason their users were hacked.
Post reply on HN