My company has a pretty large and old PHP application based on the Yii framework, which allows extending itself by installing modules at runtime (zip files containing own PHP code). Kind of like an admin panel for managing stuff by a limited number of users, not open to the world.

Adding new functionalities, even large ones is easy as you work on modules. However the whole project is old and heavily outdated, insecure and badly written in many places with many performance bottlenecks. Which makes us want to rewrite it completely in a different, more modern technology.

There were ideas of going into a NodeJS backend (postgres, redis) with SPA frontend in JS (Vue/React), even some attempts. But it just seems like it’s impossible to create such an application in this stack. Everything you want to do in JS needs to have a build step, it’s all good when the app is simple and “static” but you can’t just hardcode everything into a single application project and hide/turn off parts of the app based on client’s license. It’s just too much, and too many unknowns that will appear in the future. Microfrontends were/are a thing, but the more I read about them, the more I start believing they are useless and no one really uses them in the real world. It makes things even more complicated.

SSR is a thing, but it’s basically the same thing still requiring a build step and having performance problems, while SEO is not considered at all in this project so it wasn’t even taken into account.

So another idea is to just rewrite that in PHP again, on new framework & with more attention to make things right. But it just feels like doing the same ugly thing again, in an ages old technology that we wanted to get rid of in the first place. But it seems as the only way in order to keep real runtime modularity.

What do you think, should PHP still be used for such applications that require modularity?

New contributor

veodko is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.

Rewriting is always a major pain. Whatever you do, it often amounts to doing most of it from scratch. Hopefully you have well-maintained requirements documents that correspond to the current status of the software, so you at least can assume that they match users’ expectations.

That said, change of programming language coupled with an architectural redesign means much more effort and higher risk, as you don’t have experience with the approaches and tools to be used. Rewriting in a known language with the opportunity to fix old systemic issues while keeping good solutions may have a much lower risk of failure.

PHP has a number of warts and issues, though, and although modern PHP certainly encourages cleaner style and better security, newer languages may have clean solutions to common issues that an old language with mostly backward compatible changes cannot offer.

Ultimately it all depends on the costs and risks linked to a rewrite versus costs and risks of evolutionary fixing of the old code. If you make a detailed list of the issues with the old system, you may be better able to judge which ones will potentially break your neck someday, and which are merely nuisances. You may also be able to see whether they can be fixed (not patched) in an incremental way or are too deeply intertwined with everything else.

If you decide on incremental fixing, you should also consider moving to the latest versions of the language and libraries used (or to new libraries when old ones are not supported anymore). This likely improves your security as well as enables your developers to look at how things are done in the PHP community today, possibly learning new tricks and skills.