You can get a working prototype up quickly, and recent versions of Perl along with OO libraries like Moo/Moose allow you to quickly create well-written code.

There's also a lot of mature testing libraries.

The problem with PHP is that it's too easy to use and apps built with it have low maintenance costs. Which means that your ownership over a code base can easily be transferred to someone else.

If you want the best tech stack that will prevent you from killing the job, then I'd say Typescript or Java based API and a front-end framework like React. The more complex the code, the harder it will be to replace you and your team.

or https://news.ycombinator.com/item?id=12371463 (about AsmBB)

- advance web applications (electron, NodeJS)

- ETL on the go (i.e. fetch, JSON, DOM, SVG)

- data visualization (i.e. d3, three.js, etc.)

- dependency management (i.e. NPM, CDN, ESM like in Deno)

- learning resources in general (extremely abundant and comprehensive on various sources)

It is hard not to learn JavaScript, it is almost everywhere. Also having to learn the 2nd or the 3rd programming language should also fill-in those gaps, even those huge gaps.

I do understand that it's not entirely fair to criticize it for being sloppy, since it was supposed to only be a stopgap to be used for a few years in the 1990s until the hypothetical better language came along. Perhaps WASM means this long wait is finally over, but I don't want to get my hopes up.

The difference I see is that it will not likely die as quickly and quietly due to how distributed the code is.

For example, with most Python-based projects I have tried, I have run into some kind of version incompatibility, and often have not been able to get them to run at all.

This is an experience I wanted to avoid for those who try my software.

Aha, there's your problem.

In the real world, Elixir. On the frontend, the choice is just one, making it the worst and the best.

Ultimately it doesn't matter what internet commenters think, the best language is always going to be the one you are most comfortable and productive using. PHP, Python, Ruby, Elixir, .NET/C#, Java, Perl, JavaScript, etc. - all of them can accomplish the task of a running web application. I would lean towards an ecosystem that has lots of libraries to pick from and good documentation.

It's fine to use a programming language not normally known for web programming. Just remember if web-related libraries and documentation doesn't exist, you will need to write them yourself.

There's a reason it's the biggest upward-trending lang:

https://insights.stackoverflow.com/trends?tags=typescript%2C...

Scala as a close second!

Often times that's more about a framework than a language, or about the level of abstraction you want to deal with on the backend, or how you intend to scale, and what sort of shop you're at and what kind of devs you have. More often than not, unless you're a greenfield project or a startup, some or all of those decisions have already been made.

Compare two different approaches...

One, a traditional LEMP stack with server side interactivity and rendering. You define every layer of the stack, managing everything from the database to the CDN yourself. You deliver HTML to browsers with a sprinkling of Javascript for pagination or whatever.

Two, a Jamstack running on something like Next and hosted on Vercel, using some sort of headless CMS maintained by another vendor.

(You can substitut LEMP with any similar stack, or Next with any other Jamstack framework in any language).

But the levels of abstraction there are very different, as are your dev and infrastructure costs, as is the user and developer experience. And ecosystem support, everything from third-party packages to Stack answers. Everything gets compiled down to shades of HTML and Javascript anyway, it doesn't really matter what you start out with. The stack and its ecosystem will have way more impact on your final experience.

Most web apps are light on fancy algorithms and heavy on presentation. You're usually building documents more than apps. The tradeoffs you encounter are often between interactivity and infrastructure. Whatever stack you choose that lets you focus on that, without sacrificing business needs, is a good choice.