I haven't written PHP in over a decade.

The frankenPHP thread and then this: https://news.ycombinator.com/item?id=40543438 popped up in the last week. Now your here pitching this...

A lot of the old guard of PHP left it behind for a few reasons...

PHP 6: A lot of php devs in the frankenPHP thread took issue with me mentioning this because it never launched. A lot of devs shook their head and moved on after 6 got shit canned. After having gone through PHP 3-4-5 change where we got all the juicy OOP features, while watching python 2-3 flail we realized that we had been sold a future that did not exist. Python 2-3 took the UTF8 hit, the fact that PHP wasnt going to was a sign that we were going to be stuck with MB string bs for a long time if not forever. There's a lot of folks that went to python when 6 got canceled and didn't look back.

Reuse of code: in this regard python and ruby were in a much better place for web code to be reused in CLI scripts, Workers, jobs... hell python ended up in a million other places cementing its win over ruby. This same "one language everywhere" mentality is why you see a lot of server side JS on the web.

While most of the PHP devs who were my peers at the time went to python or node I ended up picking a very young Golang. It has been a decision that not only did I not regret but a lot of those python/node devs are asking me how to bootstrap their golang experience.

Go, brings me the joy that early PHP4 did. When you just shoved a .php file onto a server. I get that same feeling when I ship out a product that was just the standard lib in go, or where I add in a bit of Postgres... That can be the whole stack for a working API... Mix in hmtx, maybe you want to use fancier templates (templ is one people like). I dont need a stack to do a project, my project dictates what I use, and candidly its very little.

I've seen working with Laravel for years. I recently (Friday) released a Django version for my AI CRM builder (provide a few words and use ChatGPT to build a CRM)

I used packages with similiar functionality to Laravel (orator, Django Breeze)

Everything translated well. The choice of backend didn't matter as much as I thought it would.

Using VS Code compared to PHPStorm was the only part of the experience that felt degrading. Using PyCharm might have changed that.

I don't think it matters as much as it once did.

Laravel: https://github.com/iceburgcrm/iceburgcrm

Django: https://github.com/iceburgcrm/iceburgcrmpython

That's surprising. Nothing in PHP would attract me to use it again. JS in the backend and in the frontend is a nobrainer.

No JavaScript framework matches the productivity of Rails or Laravel.

  > is a nobrainer.

Out of curiosity, why?

I have heard dreaded comments from *JS ecosystem users that the packages go to unmaintained state and there is just too much noise in the ecosystem. Very few packages thrive and live for longer periods... and eventually results in a lot of rewrites for newer engine support.

Also, does it add to a non-maintainable code (or result in a complete rewrite) in a period of six months to one year?

I don't code much of web apps as I'm a system's guy who still code in C where the created programs are running fine across OS versions without dependencies and many have crossed decades of use without resulting in any security issues.

Most of them are for security and system's utility purposes and does some complex work on media and security pipelines.

Also, many hours have gone into making them secure from the general RUST / GoLang fortification offering perspective as I am against using RUST or GoLang as I have got some experiences with them on the long term maintainability and support.

Some of the created programs run fine with OSes older since the early day's of SUSE to the modern rolling versions of Linux (and almost all versions of Windows since Windows NT till date) without any modifications. It cannot be guaranteed with RUST or GoLang or with any other stack other than C...

Sorry for the deviation though!

> I have heard dreaded comments from *JS ecosystem users that the packages go to unmaintained state and there is just too much noise in the ecosystem. Very few packages thrive and live for longer periods... and eventually results in a lot of rewrites for newer engine support.

I would say most packages are somewhat maintained. But there are definitely a lot that don’t. Just last week I tried to install a few web worker packages and I couldn’t make any of them work.

I get these arguments, and I still wouldn’t say it’s a “no brainer”. (_Node-brainer?_ :V) Having mostly worked in PHP, I’m certainly biased, and also I’ve been heavily working in Node for the past year.

Node does seem to have better performance - I’d be curious to see some comparisons with some of the newer (PHP 8 I think) performance enhancements that probably aren’t used in benchmarks, like JIT. That said, in my experience, both perform well enough for the majority of what you’re going to do on a day-to-day basis. If you really need to crunch lots of concurrent connections and heavy data loads, maybe you’d go with Node? Although there’s probably something better than either of those for that job.

PHP’s package ecosystem is certainly high quality, again from my anecdotal experience. Composer et al have done a lot of really good things where PEAR fell far short.

I also know that this is mostly a “me” issue with not being a Node backend person from the start, but my goodness there’s a lot to do to dive into an imported method and actually figure out what’s happening. Having to sift through bundled JS to trace back to the root of something is a lot more difficult than just seeing the raw PHP of a Composer package.

To each their own, and the right tool for the job - to say one tech is always better or preferred over another seems a little narrow for my personal taste.

I just use node and webpack.