Why I Switched from JSP to React (And What I Learned)

I used to think JSP was "fine." It rendered HTML, it talked to servlets, it got the job done. Then I spent six months migrating over fifty JSP pages to a React frontend at Dedalus, and I came out the other side with an entirely different understanding of what frontend architecture actually means.

The problem with "it works"

Our HCIS codebase had JSP pages that were part UI, part Java, part business logic, and part prayer. A single page could contain JSTL expressions, embedded scriptlets, inline SQL calls (yes, really), and three different ways of doing the same date formatting. Nobody planned it that way - it just accumulated over years.

The symptom wasn't that it was broken. It worked. Clinicians used it every day. The symptom was that every change, no matter how small, required you to hold the entire system in your head before touching anything. Change a field label and you might break a validation. Adjust a layout and a conditional rendering somewhere else goes wrong. That's not a JSP problem specifically - that's what happens when there's no separation of concerns.

What React forced me to do

When I started rewriting these pages in React, I couldn't just transliterate the JSP. The component model forced me to ask questions I'd never asked before. What does this page actually own? Where does the data come from? What happens when it changes?

These questions sound obvious in 2026. But when you've been working in server-rendered templates where the "state" is just whatever the servlet put in the request scope, they're genuinely disorienting. I had to learn to think about data flow before writing a single line of JSX.

The first few components I wrote were a mess - I was essentially writing JSP in JavaScript. Global variables disguised as module exports, side effects in render, business logic tangled with display logic. The pattern looked different but the disease was the same.

The lesson that actually stuck

The migration got cleaner once I stopped thinking about it as "converting JSP to React" and started thinking about it as "redesigning the data layer with a UI attached."

I had a clinical assessment page with nine different scoring scales rendered on one screen. In JSP, all nine scales were tangled together - shared state, shared form submission, one giant servlet backing it. When I pulled it apart, I realised the nine scales were actually independent. Each had its own data, its own validation, its own save lifecycle. They just happened to live on the same page.

Once I modelled them as independent components with clean props boundaries, the complexity dropped by half. Not because React is magic, but because the component model made the bad coupling visible. JSP had been hiding it.

What I'd tell someone starting this kind of migration

Don't start with the UI. Start with the data. Before you write a single component, map out every piece of data the page needs, where it comes from, and when it changes. The JSP doesn't tell you this directly - you have to excavate it. But once you have that map, the component structure almost writes itself.

Also: not every JSP page deserves a careful React rewrite. Some of them are simple enough that the migration is purely mechanical. Save your design energy for the ones with real complexity. You'll know them when you see them - they're the ones where the original author left no comments because they assumed nobody else would ever touch it.

The technology switched. The discipline required to write maintainable frontend code did not. That was the actual lesson.

Fifty pages in, I'm a better frontend engineer than I was going in - not because I learned React, but because the migration forced me to confront every shortcut I'd been taking for granted.