When discussing programming languages, you need to take into consideration how easy it is to find developers with experience on a certain language.

Sure, you can do web apps in Perl with Catalyst or other frameworks, but the PHP developers are easier to find.

And then, after you develop entire GUIs in a language, it is a herculean effort to port that to another.

And lastly, JavaScript has its own issues too.

We're talking about an html GUI right? That's not herculean to port between languages.

The difficult part isn't rendering the UI, it's the work that's done between the UI and the back end components/services that's difficult. PHP is used for more than just web pages.

But that glue is pretty straightforward and you only have to convert one page at a time.

I don’t think you ever went through something like this ever.

It is a huge effort even migrating from one PHP framework to another.

Coming back to your point, there is no single “page” to be migrated one at a time.

It's just the configuration pages. It's not the core of the product and doesn't need to be a perfect clone.

Is there a reason one URL at a time wouldn't work?

My last comment on this: it is not "one URL" or "just configuration pages", it is an entire application, it does not have distinct "pages" that can be replaced with something written in a different programming language.

You can always take a look at the UI of a PAN device and use your browser in developer mode to see how it works and understand the concept of a web application.

> You can always take a look at the UI of a PAN device

I do not have a PAN device.

> it is not "one URL"

I never implied it was.

> it is an entire application, it does not have distinct "pages"

> the concept of a web application

Those are usually written in javascript and the client part could stay the same. If anything that kind of design makes it easier to replace the backend one URL at a time becasue the responses from the backend are simpler.

If they have something where the UI state is kept on the server and is relayed to the browser, that would be difficult to do anything with. But that's an especially terrible design that causes other problems, so if you're accusing them of having a design that bad please be explicit.

We were talking about early 2000s.

Perl 5 was the language of choice for CGI in that era, but PHP borrowed some of perl syntax and quickly displaced Perl in web usage.

Some perl programmers migrated to Embperl, but it didn't gain much momentum.