151–160 of 188 posts
Earlier quoted context omitted.
I'd love to see a modern PHP without all the warts but with the ease of use.
I think you are in for a treat, then, because PHP 8 is way different from PHP 5.
I think people are now ready for php. I bet it will be reinvented on top of nodejs.
Earlier quoted context omitted.
I think you are in for a treat, then, because PHP 8 is way different from PHP 5.
Unless they have abandoned backwards compatibility then I don't think that is what I meant.
PHP 8 uses exceptions with a unified Error hierarchy, there are type errors, division by zero, certain parse errors and so on.
PHP 8 has strong support for static typing now, thank goodness.
PHP 8 introduces union types (int|float|null).
PHP 8.1 introduces intersection types (A&B).
PHP 8.1 added the "never" return type.
PHP 8 has less repetitive boilerplate.
PHP 8 has consistent function signatures now.
PHP 8 has consistent object/array syntax now (to be honest, some asymmetries remain).
PHP 8 has named arguments for clarity and flexibility.
PHP 8 has the nullsafe operator which simplifies deeply nested null checks.
PHP 8 has arrow functions which makes closures concise and easier to use.
PHP 8 has attributes, e.g. "#[Route("/users")]".
PHP 8 has "match" expressions which is a more predictable, type-safe, and expression-oriented alternative to "switch".
PHP 8 has many more tools for testing and debugging (incl. static analyzers).
PHP 8 has many new functions (incl. utility functions).
PHP 8.1 introduces native enums.
PHP 8.1 has "readonly" properties for enforcing immutability.
PHP 8.1 has cleaner syntax for referencing callables.
PHP 8.1 has "fibers" which enables cooperative multitasking and is a foundational building block for upcoming async/await features.
Global namespace pollution has been pretty much resolved (Composer autoloading[1]).
There are other ecosystem-level improvements such as PSR standards[1], better async story, etc.
This list is non-exhaustive. These are just the improvements that come to mind off the top of my head so I probably missed a lot of other major improvements. PHP 8+ is definitely much easier to use and they greatly reduced PHP's warts. There may be some inconsistencies left here and there, but they are not a deal-breaker IMO, if you even run into them.
[1] https://www.phptutorial.net/php-oop/php-composer-autoload/ (I do not use "dump-autoload"), https://github.com/php-fig/fig-standards/blob/master/accepte..., https://www.php-fig.org/psr/psr-4/ (https://www.php-fig.org/psr/)
---
I strongly recommend taking a fresh look at PHP 8+. It is very different from the PHP you have once known. It is "modern" now. There are lots of deprecations and removal of old warts. I did not like PHP as much ages ago, but it was a pleasure to use PHP 8+.
If you are looking to (re)learn PHP, the book “PHP & MySQL: Novice to Ninja” is a good starting point[1]. There are many other, high-quality books and resources as well.
[1] Available on libgen. The source code examples from the book are available on GitHub: https://github.com/spbooks/phpmysql7.
---
If you have any specific warts or whatnot, or if you want more resources, please do feel free to let me know.
---
I wrote this comment on my phone, so it is not as detailed and it is not structured as well, but I hope that it will still provide some insight into the differences between legacy PHP and modern PHP.
Happy to answer any questions!
Earlier quoted context omitted.
Yeah, solving this edge case properly can add a lot of complexity (your solution has the same problem, no? deletes would mess it up as would updates, technically). I've seen people using long-lived "idempotency tokens" point to an event log for this but it's a bit nuts. Definitely worth considering not solving it, which might be a more intuitive UX anyway (e.g. for leaderboards).
It doesn't have the problem if a timestamp or similar is used.
Earlier quoted context omitted.
The browser gives you a full-blown programming language with a rich API, but it seems a lot of people avoid that in favor of smushing together a static view on the server side with little more than string interpolation.
I'd prefer not to download 2MB of JavaScript and feel my phone get uncomfortably hot just to fill out your online form.
Earlier quoted context omitted.
Have you looked into the string interpolation & verbatim operators as a templating alternative? These can be combined to create complex, nested strings: var reportPartial = @$" {report.Name} {string.Join('\n', report.Items.Select(reportItem => @$" {reportItem.Col1} {reportItem.Col2} "))} "; In more complex views or reuse scenarios, I'd push the inner interpolation loop to a method. This is how I've been building my .…
Some dangers with injection attacks if you don't santitize inputs correctly, but this is probably faster than most templating languages like razor.
> When you move from React to HTMX, you trade complex state management for server-side simplicity. Managing the same state will have the same complexity on the server as it does on the client. HTMX's smugness is a huge turnoff.
https://htmx.org/essays/a-real-world-react-to-htmx-port/
while I certainly try to be funny online, I hope I'm reasonably even handed about the tradeoffs associated with the hypermedia approach:
Earlier quoted context omitted.
At some point I hope it becomes obvious that well-engineered SSR webapps on a modern internet connection are indistinguishable from a purely client side experience. We used this exact same technology over dialup modems and it worked well enough to get us to this point. Being able to click a button and experience 0ms navigation is not something any customer has ever brought to my attention. It also doesn't help much i…
Yes, a well-engineered SSR webapp could be indistinguishable from an SPA. However, it is much harder to build a well engineered SSR with the tools we have. I haven't seen someone solve errors with form submissions and the back button well at the framework level. Post-Redirect-Get was awful. Trying to solve back buttons and wizards. Trying to solve modals. Is a modal a separate page with the rest in the back? What doe…
Like, the back button: there is no logic because this isn't react. It's just the browser back button. You don't have to do anything if you're using SSR. Back button problems only apply to SPAs or hybrids.
Earlier quoted context omitted.
As a long time PHP developer, it never fails to amuse (amaze?) me the lengths people go to in order to get the things the browser will give you for free.
The browser gives you a full-blown programming language with a rich API, but it seems a lot of people avoid that in favor of smushing together a static view on the server side with little more than string interpolation.
Plus, you have to convert data to HTML somewhere. If you're using react you do this typically on the front end. You traverse and read JSON and convert it to HTML... Just like you would in PHP. Just, on the front end.
Earlier quoted context omitted.
Have you looked into the string interpolation & verbatim operators as a templating alternative? These can be combined to create complex, nested strings: var reportPartial = @$" {report.Name} {string.Join('\n', report.Items.Select(reportItem => @$" {reportItem.Col1} {reportItem.Col2} "))} "; In more complex views or reuse scenarios, I'd push the inner interpolation loop to a method. This is how I've been building my .…
Some dangers with injection attacks if you don't santitize inputs correctly, but this is probably faster than most templating languages like razor.
In terms of performance, it is definitely faster. The amount of time it takes to render these partials is negligible. You'd have to switch up your tooling to measure things in microseconds instead of milliseconds if you wanted any meaningful signal.