Why and how I moved from PHP + HTML to React + Express
My PHP and HTML service grew until state management, component reuse and async UI became a struggle. Why I moved to React and Express, and the practical reasons for Express.
#PHP #HTML #React #Express
When I first started building web projects, I put the whole thing together with PHP and HTML. The server hands over the data and it gets rendered straight into HTML. For both the admin pages and the user-facing screens, I just tied .php files together with include and, where needed, bolted on behavior with jQuery, and that was enough. As I kept adding features one at a time, the service got bigger and the pages multiplied. And at some point it started getting harder and harder to work with. In this post I'll write down what the pain points were and why I chose React and Express. The limits of the old PHP + HTML structure It was fast and easy at first, but as the project grew, these limits started to show. 1. There's no state management Every page move triggers a full reload, so to keep things like user state or values selected on screen, I had to touch session or localStorage every time. Set one filter, move to the next page, and the filter is gone, so every page ended up with its own code to keep it alive. 2. Components can't be reused To reuse UI like buttons or cards, I either copied and pasted or handled it with include, and as that piled up it became really hard to manage. If I changed the look of one card, I had to open every file that included that card and check it. 3. Building async UI got more and more painful At first I only used jQuery for simple Ajax calls or opening a modal, but as features grew, the UI state got tangled and debugging got harder. Features like infinite scroll, conditional filtering and sorting, for example, quickly turned messy as scripts clashed with each other or the same DOM was manipulated from several places. It got harder and harder to follow which script was changing which element. 4. There's no boundary between backend and frontend In PHP the template and the logic are mixed in one file, so even to change only the design I had to read PHP code. With the roles mixed together, maintenance was hard, and even when I had someone to work with, it was awkward to split the work. What led me to switch to React + Express So I decided this structure couldn't be maintained much longer, and chose to move the whole thing onto React and Express. The plan had two parts. Rewrite the entire frontend in React, built on components Pull the API server out separately with Express and manage it RESTfully That way the frontend and backend are cleanly separated, and with the roles clear, it's also easier to add features later. Why I chose React 1. A component-based structure is good for maintenance Buttons, modals, lists and the like can all be separated and reused, and when I change one, I can manage it without affecting anything else. What I had been imitating with include in PHP, I could now do properly. 2. State management is easy With things like useState, useEffect, useQuery and zustand, I can handle screen state, server state and user state separately. State stays alive across pages, so I no longer need the code that used to stash things temporarily in session. 3. It runs smoothly without full reloads Because it's CSR, moving between pages happens without a flicker, and the user experience itself got much better. This was the first thing I noticed after building it. So why Express for the backend? To be honest, the practical reasons outweighed the technical ones. It's quick to build with With Express you can make an API in just a few lines. app.get('/api/users', (req, res) = { res.json([{ id: 1, name: 'Hong Gildong' }]); }); The company was small and we had to get an MVP running quickly, so I needed a structure I could build fast and deploy fast. JavaScript covers everything The frontend was React, so I was already writing JavaScript, and being able to write the server in the same language was a big deal. Not having to go back and forth between languages made it quicker to understand and quicker to implement. Extending it is easier than I expected With just npm, it's easy to add things like cors, jwt and multer, and the routing and middleware structure is flexible enough that I could use it in real production without trouble. Later, when I needed file uploads or login, adding one package was all it took. It wasn't finished yet when I wrote this Looking at it again now, the switch was about half done at the time I wrote this post. I had moved only a few screens to React and the rest was still PHP. Moving everything took another half a year after that, and the process was a completely different problem from tearing it all down and rebuilding in one go. The most annoying part was getting the existing PHP screens and the new React screens to share the same session. For several months, PHP handled login while React rendered the screens. I wrote about that in the next post.