It depends on your environment and usecase.

For me Node is actually a curious case. Node itself and its APIs are very stable and the stability of each API is clearly marked in the docs.

But the NPM based ecosystem is almost the exact opposite. Using it for anything else than quick experiments or throw-away prototypes is a maintenance nightmare for people like me. Maybe you can amortize that in larger companies with an operations department but from what I heard and observed over the years admins and programmers don't tend to talk much with each other and most programmers have no idea what it takes to keep their code running. And I can deeply emphasize with every admin who has to keep a node project with hundreds of dependencies running for more than a few months. Lets not even talk about security.

Nodes core APIs are pretty network centric (that's where it came from) and it was a good fit for a HTTP based Matroska video streaming server project (among other things). But as it turns out JavaScript is a pretty bad language if you need bit manipulation with 64 bits. I'm still curious why they made BigInt signed one's-complement… Writing that stuff in C was a lot simpler.

As for websites with node but without NPM... I did that a few times but for the last two years I tend to use Python aiohttp instead. They have well maintained Debian packages and builtin websocket support. And very complex client-server interactions are often the threshold where I switch from webservers like Apache or Nginx to an application server.

As for using PHP for new code bases: I think a lot of programmers underestimate the flexibility and simplicity of file based webservers like Apache with PHP. If you keep it simple they allow projects to grow organically. Need a new backend for something? Just put a few lines of code into a new PHP file. No update to a centralized application server or routes required. Want to have a search-engine friendly dynamic website? Just write a basic HTML page with a few lines of PHP in it to insert the actual data (the alternate control structure syntax basically gives you a builtin template system). Want to generate static pages instead? Use output redirection. Want to add simple user authentication? Add a password protection in the webserver. Or tell it to get the user data from LDAP if you're in a company. It plays well with source control, there are a lot of dirt cheap webhosters for small customers, the list goes on and on. All of that makes PHP a pretty good tool that can solve a lot of problems in very simple ways.

A lot of that are just small projects, small customers or the inglorious everyday work that nobody likes but someone has to do. So it doesn't get talked about much. Big companies and teams on the other hand spend a lot of time talking about what they do and then there are also consultants that preach whatever sells today. Most tend to talk about what everyone else is doing and this doesn't necessarily has anything to do with a simple solution for your specific problem at hand.

Of course all of that can flip on a dime depending on your environment: Part of a team where everyone has decades of Java experience? You're not using PHP, or node for that matter. Doing a project with a lot of rookies that only know stuff like express and react? Guess what you'll be using. Part of a team where everyone has their dedicated non-overlapping area of responsibility and authority (content, design, programming, etc.)? Now there is potential to use the right tool for the job. And PHP can be just that in a lot of situations.

Happy programming
Stephan



On 08.04.23 22:47, Dan Liebner wrote:
I agree with the OP's sentiment here. If I was starting a codebase from
scratch today, I'd probably go with Node. I find that writing modern
JavaScript is way easier than writing PHP these days, and the breaking
changes in newer PHP versions make writing code harder rather than easier.
PHP is the foundation for many legacy codebases, and breaking old projects
isn't really a great selling point of new PHP versions.

Hopefully this scenario will affect enough people that 7.4 will continue to
be maintained by some group of people into the foreseeable future.

Best,
Dan

On Sat, Apr 8, 2023 at 4:28 PM Kamil Tekiela <tekiela...@gmail.com> wrote:

Hi Stephan,

Generally, PHP tries to keep as much backwards compatibility as possible.
Breaking changes are limited to minimum and done in the least obstructive
way possible. When a deprecation is introduced, you have at least 3 years
to update your code.
But PHP also tries to move forward and the language improves each year. We
certainly got many more features than breaking changes. Just think of match
expression, enums, attributes, constructor property promotion, new Random
API, readonly properties/classes, first-class callable, consistent errors
and many more.
The biggest improvement in PHP 7 and 8 was a comprehensive type system.
It's something that you don't have to use, therefore doesn't affect
existing code much, but makes development so much more enjoyable and less
bug-prone. I know I have discovered many bugs because of migration to PHP 8
and introduction of proper types.
And this is the direction PHP is going in. The language is still dynamic
and allows for taking the easy route, but new features focus on reducing
bugs by making the code's behaviour less surprising.

If you try to adhere to clean code principles, upgrades should not be a
huge problem. Use static analysis and good tests. Learn and follow clean
code practices, e.g. SOLID. Use abstraction in your code; it's better to
change code only in one place than change it across hundreds of files. Some
tools help you during migrations, such as Rector and phpcbf, but to use
them proficiently, your code needs to be free from surprises. Dynamic
properties are a very good example of surprising behaviour. By looking at
the definition of the class, you don't know what properties it has. If any
of the methods use undefined properties, both you and static analysers will
be surprised by this.

There are certain things you should avoid in your code like fire. Not
because they might be removed from the language, but because they make your
code unclean and cause bugs. Here is my list:
- Arrays. Yes, they are a major feature of the language but also a major
pain in the... Use proper data structures, which may use arrays internally,
but don't use bare arrays in your code. Value objects and DTOs are
invaluable.
- Isset and empty. They are sometimes necessary and sometimes they are the
easiest choice, but they hide so many bugs. Every time you use any of them,
it should raise an immediate red flag.
- References. I don't understand why the language still has this feature.
Hack got rid of it and that was a very smart decision. You don't need
references. Use them almost never.
- Globals and superglobals. This should not need explaining. Pretty much in
every language, these are pure evil. They make changes to the code an
experience similar to disarming a bomb. It's tempting to use $_GET, $_POST,
$_REQUEST anywhere in your code, but if you want to avoid bugs and
surprises, you'd better stay away from it. There should probably be at most
one place in every project where these are used.
- extract() and compact(), and variable variables. These should only be
used in a very tightly controlled scope, and even then, their usage can be
contested. Ideally, variable variables should not exist in the language; we
have arrays after all.
- Sanitizing filters. Sanitization is too ambiguous term to be useful. What
you should be using is validation and formatting. Validate your inputs to
make sure they are the type/value you expect. Format the output so that it
can't break the context it is in.
- Loose comparison. I have liked that about PHP in the past, but in recent
years I became a strong supporter of strict comparison. Why? Because "0" ==
false. Forbid using loose comparison in your coding standard and forget
that it exists. Don't let the language make a fool out of you. You are the
developer and you know what type you expect.

Following these guidelines will not only help you avoid bugs in your code
but also will make the upgrade process much less cumbersome. This and
adhering to the strictest level of the static analysis tool of your choice
is the recipe for success.

Try to stay up to date with the changes. Every year when PHP releases a new
version, go over the changelog and make an effort to learn and use new
features. Even if your production is 3 years behind, you can try these out
in your development environment.

PHP will move forward and add new features, but sometimes it must also
break some things to move forward.

Kind Regards,
Kamil Tekiela



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Reply via email to