31–40 of 337 posts
I have a question to the PHP-in-production crowd: how long do you wait before migrating to higher version of PHP? Is the first release usually already fine, or is it better to wait for a few months and let someone else catch the early errors?
These days, I am super torn about what language to use for new web projects. PHP: - Easy to deploy: Upload files, done. - Easy to develop: Reload page, see changes. - Lots of HTTP tooling built in. - Fast. Python: - Great language. - Great code reuse system: Modules. - Nice framework: Django. - Less breaking changes in recent years.
Don't forget Laravel for PHP.
These days, I am super torn about what language to use for new web projects. PHP: - Easy to deploy: Upload files, done. - Easy to develop: Reload page, see changes. - Lots of HTTP tooling built in. - Fast. Python: - Great language. - Great code reuse system: Modules. - Nice framework: Django. - Less breaking changes in recent years.
PHP fast? Compared to all popular web frameworks it's quite low in the pecking order when it comes to performance.
But who cares, we are literally talking millisecond differences between them all. Throw a reverse proxy, DB into the mix and a few packages and they are all slow.
I have a question to the PHP-in-production crowd: how long do you wait before migrating to higher version of PHP? Is the first release usually already fine, or is it better to wait for a few months and let someone else catch the early errors?
I'm just a PHP programmer for work, but I worry about the orientation PHP has chosen. As French people say: better is the enemy of good (Le mieux est l'ennemi du bien). The two new language features bring a higher language complexity for dubious gains. I hope I won't have to work with these. Property hooks mean that some language magic will turn a property access into a call to methods. It implies that `$this->x` has…
None of this is required. You can still write spaghetti code perfectly fine.
These days, I am super torn about what language to use for new web projects. PHP: - Easy to deploy: Upload files, done. - Easy to develop: Reload page, see changes. - Lots of HTTP tooling built in. - Fast. Python: - Great language. - Great code reuse system: Modules. - Nice framework: Django. - Less breaking changes in recent years.
> - Easy to deploy: Upload files, done. Sure, it works for simple/less important cases. But it also means that your application code is inconsistent while the files are uploading. Stop your service, upload the files, start the service: safer. For a Django app you would upload files and ask Gunicorn to graceful reload... similar, just cleaner.
In practice, any serious project is likely to be version-controlled. Git pull is generally fast enough that it behaves like an atomic change. (By default, opcache will not reload a file that's less than 2 seconds old.)
Earlier quoted context omitted.
> Reload page, see changes. This should work in Python, too. With Django, I think you need to use https://pypi.org/project/django-browser-reload/ , and rith most other frameworks / WSGI servers just try adding --reload flag. Edit: Django should wor out of rhe box actually – that package is for refreshing the page in browser. > Easy to deploy. Upload files, done. I can see the appeal, but generally you’d want to avoid…
There are of course ways to get "reload page, see results" to work even with Python. After all, computers are touring complete. But in PHP you have it out of the box. Faster, with less complexity and less resource consumption. And you can use the same setup in development as you can use in production.
When you load a Python page, it is served by an in-memory process. If code is updated, the process is restarted, parsing the code and initialising the application, but it is done only once.
When you load a PHP page, it parses the code and initializes the app for each request. It then tears everything down after the request. There are less wasteful ways (most recent are app servers, just like in Python or other langs), but I'm not sure if those are widely used in local development. Even then, it’s same as Python, Node or pretty much anything else.
And of course, I’m not trying to diss on PHP here – it’s gotten pretty good recently. But reload on change is built in pretty much every app framework nowadays. It works out of the box and is negligibly fast. It’s not a good point to compare.
Oftentimes many of the significant new PHP features are to fix the shortsighted implementation in the previous ones - for example this method chaining with `new` - there was precedent already, C++ got it right well before PHP even existed and with the very same arrow operator that PHP borrowed (and so did Java and JavaScript with .), so the question is why did PHP have to get it wrong at first and for so long. Anothe…
The global namespace change would break everything. It’s unlikely they would ever do something like that. It’s hard to build on a language used by so many, when you can’t modify the base. Python decided to do 2.7 vs 3 and fragmented the eco system terribly.
Adding any globals should be a carefully-considered change. User-defined functions are global by default, and although there are (now) much better ways to write PHP libraries, I can absolutely see some old library defining array_find (one of the new global functions in 8.4) in an incompatible way and breaking new code that attempts to use the built-in function.
Sure, you can’t touch the existing pile of globals, but at least stop pouring fuel on that particular fire…
[flagged]