TL;DR
- GWT is now actively costing enterprise teams. Compile times, a shrinking talent pool, and CSP-incompatible inline code are showing up as hiring failures and audit findings.
- React is the settled destination. The open question is decoupling GWT-RPC into a REST API the frontend can call.
- JSNI blocks and GWT-RPC call sites are mechanical but numerous. That volume, more than the underlying complexity, is what turns a manual migration into a multi-month project.
- An AI modernization platform compresses the mechanical share of this work. Agents convert RPC calls and isolate JSNI blocks directly, with a human reviewing every change before it merges.
- A phased, module-by-module rollout avoids a big-bang rewrite. GWT and React can run side by side against the same REST API until every module is converted.
Google Web Toolkit let Java teams write browser applications entirely in Java, which GWT then compiled to JavaScript. It was the default choice for enterprise Java shops building internal tools, admin consoles, and back-office systems from roughly 2006 through the mid-2010s. GWT is now governed by a volunteer Steering Committee rather than run by Google directly, and the project still ships releases, most recently GWT 2.13.1 in June 2026 [1].
A GWT to React migration is what most of those applications now need. This piece covers what has to happen first, where the manual work balloons, and how much of it an AI modernization platform can compress.
GWT Has Become a Liability
Four costs recur once a GWT application has been in production for a decade or more. None of them are abstract. Each one already shows up in build logs, hiring pipelines, or audit findings.
- Compile times run 15 to 45 minutes on medium-to-large codebases, with no modern hot reload. Every UI change means a full recompile before a developer can see it.
- The talent pool has dried up. GWT does not appear among the 28 frameworks tracked in the 2025 Stack Overflow Developer Survey. React usage among professional developers sits at 46.9 percent [2]. New hires know React and TypeScript instead of GWT.
- GWT-RPC ties the frontend to the backend through a proprietary binary protocol. A backend change forces a full frontend recompile and redeploy, even when the UI itself did not change.
- JSNI embeds raw JavaScript inside Java method comments. This bypasses Java’s type system and blocks static analysis tools from understanding what the code does.
- Inline script execution conflicts with the Content Security Policy baselines most security audits now require. A strict CSP disallows the unsafe-inline behavior JSNI depends on [3].
If a GWT application in your estate has never been mapped end to end, a $0 Modernization Assessment returns a dependency map and a migration plan in 2 to 5 days, at no cost.
React Is GWT’s Migration Target
Search queries comparing GWT vs React usually come from teams that have already ruled out staying on GWT. The remaining question is whether React holds up as the landing spot, and on the fundamentals it does.
React’s ecosystem and hiring pool are an order of magnitude larger than GWT’s ever was. The 2025 Stack Overflow Developer Survey put React usage among professional developers at 46.9 percent [2]. That adoption base makes staffing a migration, or an ongoing maintenance team, straightforward in a way GWT hiring no longer is.
GWT is not the only Java-era UI framework making this move. JSP-based frontends face a similar JSP to React migration calculus for many of the same reasons.
React alone does not fix GWT-RPC’s tight coupling between frontend and backend. That requires replacing GWT-RPC with a REST or JSON API first, covered next. Once that decoupling is in place, React becomes a straightforward, well-supported client for it.
React’s component model also maps cleanly onto how a GWT UI is already structured. GWT applications are typically built from composable widgets and UiBinder templates, which is closer to React’s component tree than it is to a page-based framework. That structural similarity is part of why a phased, module-by-module rollout is realistic here rather than theoretical, a pattern covered later in this piece.
| GWT | React | |
| Build and compile | 15-45 min full recompiles, no hot reload | Sub-second hot reload in development |
| Frontend/backend coupling | GWT-RPC binary protocol, tightly coupled | REST/JSON API, frontend and backend deploy independently |
| Type safety at the JS boundary | JSNI bypasses it | TypeScript enforces it |
| Hiring pool | Not tracked in major developer surveys | 46.9% of professional developers, per Stack Overflow’s 2025 survey [2] |
| CSP compatibility | JSNI relies on inline script execution | Compatible with a strict CSP by default |
GWT-RPC Must Become a REST API First
Every credible migration path agrees on one prerequisite. GWT-RPC has to be replaced with a REST or JSON API before a single React component gets written.
Skipping this step and calling GWT-RPC services directly from React does not work. GWT-RPC depends on GWT’s own client-side proxy generation and serialization format, and neither exists outside a GWT application.
In practice, decoupling means exposing each existing RPC service as a REST endpoint, translating GWT’s serialized DTOs into JSON, and giving the new API its own versioning and authentication rather than inheriting GWT’s session model. None of this touches the UI. It is backend work, and it has to happen whether the eventual frontend is React, Angular, or something else.
The upside is that this work pays for itself independent of the frontend timeline. Once a REST or JSON API exists in front of the old RPC services, it can be tested, versioned, and load-tested on its own, before a single screen has been touched. That gives a team a clean rollback point if the frontend migration needs to pause partway through, since the backend contract does not depend on which frontend is currently calling it.
Manual JSNI and RPC Conversion Takes Months
A GWT application of any real size has hundreds or thousands of JSNI methods and RPC service calls scattered across the codebase. Each one is individually simple to convert. A JSNI method that wraps a browser API call becomes a typed function call. An RPC service method becomes a REST endpoint and a matching client call. Neither conversion requires architectural judgment.
The problem is the volume. A team converting these by hand, one JSNI method and one RPC call at a time, spends months on repetitive translation work. Very little of that time goes to the handful of decisions that require real engineering judgment, such as target architecture or UX changes.
This is exactly the kind of work that services engagements bill by the hour for, because it cannot be skipped and it does not compress on its own. A team doing this manually, module by module, is why migration timelines quoted for GWT applications tend to run six months to two years. Most of that time is spent on mechanical translation rather than on decisions that need a person.
Legacyleap Automates JSNI and RPC Conversion
Legacyleap is a Gen AI-powered legacy application modernization platform built on multi-agent orchestration, and the mechanical half of a GWT migration described above is close to what that architecture is built for.
Before any conversion starts, the Documentation Agent maps the application’s actual dependency graph: which JSNI methods exist, which RPC services they call, and which UI modules depend on which backend calls. A decade-old GWT application rarely has this documented anywhere.
From that map, the Modernization Agent converts JSNI blocks into typed function calls and translates each RPC service and its DTOs into a REST endpoint with matching client code. Every change is generated as a pull request, never written directly into the codebase. Roughly 70% of this conversion work is automated. The remainder, mostly UX decisions and target architecture calls, stays with the engineering team, and every change is reviewed before it merges.
The QA Agent then validates that the converted React components and REST endpoints behave the way the original GWT screens and RPC calls did, generating test cases and running parity checks before release.
This covers the Modernize and Validate stages of a five-stage lifecycle that starts with the Assessment Agent scoping the migration and ends with a phased Deploy. None of it runs unsupervised.
Whether this work is worth buying as a platform or contracting out as services is its own platform vs. services modernization decision. The mechanical volume above is a large part of what tips that calculus toward automation. It is also a different proposition than pointing a general-purpose coding assistant at an undocumented codebase, for the reasons Gen AI coding tools fail at modernization generally.
A $0 Modernization Assessment produces the dependency map and migration plan first, at no cost, entirely inside the client’s own environment.
See how the Modernization and QA Agents handle JSNI and RPC conversion on a real codebase.
A Phased Rollout Avoids a Big-Bang Rewrite
A GWT to React migration does not have to ship as one release. The two frameworks can run side by side in production for the length of the migration, with GWT handling modules that have not been converted yet and React handling the ones that have.
The practical pattern is to convert one module or user flow at a time, starting with whichever screens change most often or carry the most maintenance risk. Routing between the GWT and React versions happens at the navigation layer, rather than inside a single page. Each converted module gets its own parity check before the next one starts, so a regression in module three does not block module four.
This sequencing is also why the earlier backend decoupling pays off from the first converted module to the last. GWT and React can both call the same REST endpoints once GWT-RPC is retired, which is what makes running both frontends at once possible in the first place.
Conclusion
The GWT to React decision is largely made already. What remains is how much of the conversion happens by hand, and how long that takes.
GWT’s community keeps the project alive at a maintenance pace. The market keeps adding React developers rather than GWT developers every year, and that gap only grows. The backend decoupling work, replacing GWT-RPC with a REST API, has to happen regardless of which frontend framework replaces GWT.
The manual version of this work is mechanical rather than conceptually difficult, and mechanical work at this volume is exactly what compresses under an AI modernization platform instead of a team billing by the hour. A phased rollout, module by module, keeps the risk contained either way.
Start with a $0 Modernization Assessment. It maps every JSNI method, RPC call, and UI dependency in your GWT application and returns a migration plan in 2 to 5 days, at no cost, entirely inside your own environment.
FAQs
Yes. A common pattern mounts a React root into a DOM element inside a GWT Widget, then bridges props and events with JsInterop. The GWT panel keeps its place in the page. What renders inside it is already React.
No. Most are thin wrappers around a browser API and convert into a typed function with little judgment involved. The harder minority touches GWT’s own runtime internals, such as its exception mapping or DOM element handles, and those get a closer human look before merging.
Yes, by a volunteer steering committee rather than by Google [1]. Those releases are compatibility and bug-fix work rather than new investment. The proposed GWT 3.0 rewrite on J2CL has stalled for years with no committed finish date.
The range depends more on how much JSNI and RPC logic an application carries than on its raw line count. Scoping that number is its own short step, typically 2 to 5 days for a dependency map and an estimate, before a migration timeline gets committed to.
No. Only the GWT-RPC service layer needs a REST wrapper. The business logic and data access underneath it are usually untouched, since only the transport and serialization layer changes.
Not necessarily. Both frontends call the same REST API. The same engineers can maintain remaining GWT modules and build new React modules in one sprint, rather than splitting into a dedicated migration team and a product team.
References
[1] GWT Project. Release Notes
[2] Stack Overflow. 2025 Stack Overflow Developer Survey, Technology
[3] OWASP. Content Security Policy Cheat Sheet
