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.

▲

Dylan16807 19 hours ago | parent [-]

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

▲

ExoticPearTree 12 hours ago | parent [-]

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.

▲

Dylan16807 9 hours ago | parent [-]

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?

▲

ExoticPearTree 6 hours ago | parent [-]

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.

	▲	Dylan16807 2 hours ago \| parent [-]
		> 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.