When looking for a framework to build our codebase on, we came across GWT. Although we didn’t have any prior experience with GWT, we were a team of seasoned Java devs, so it seemed a natural fit for our skillset. Plus it offered the client-side UI building approach we still believed in. Still, a lot of base work was required to build out the basic infrastructure of our application. This is where the GWTP framework came in handy. It made our introduction to GWT much easier and gave us a headstart in development.
One of the major problems of our vanilla JS solution was that we had to take care of every single piece of application and UI logic ourselves. And, because Ruxit is a single-page application, there was a lot of logic to be tracked. GWTP provides lots of helpful boilerplate functionality like view lifecycles and connecting URLs to corresponding views. GWT is a great technology with a learning curve that’s not too steep. However it does take some time to adjust your mindset to the work approach that’s required for succeeding with GWTP.
As mentioned, GWTP made our start with GWT much easier but at the same time the framework it provides is not restrictive. Yet it covers most of the basics that are needed to successfully get your application up and running. Over the time that we’ve worked with GWTP—which is three years at this point—we’ve never felt that GWTP has constrained us, which is phenomenal. We’re convinced that it’s the balance between structure and freedom that makes GWTP so appealing.
One of our favorite features in GWTP is code-splitting. Sure, code-splitting is included with GWT, but you have to take special care to set the split points right. If you don’t get the split-points right from the beginning, it can be really hard (if not impossible) to introduce them later as the code is usually too tightly bound by then. GWTP’s Model-View-Presenter architecture offers an easy and efficient solution to this problem. By applying MVP, your code automatically comes in the right granularity for code-splitting. Without it, we would likely be in a very bad situation at this point, needing tens of megabytes of UI code to be loaded into the browser right from the start. Instead, when opening a Ruxit view for the first time, only the code required to render the current view is downloaded.
With GWTP your code is typically loosely coupled. The advantage to this becomes apparent once your team and code grow in size. Today we’re about three years into development with GWTP and we’ve grown into six teams spread across three countries with almost 230,000 lines of code checked into our repository. Thanks to GWTP our teams don’t step on each other’s toes; each team only runs the views that are relevant to their work. This makes GWT development much faster and less error-prone.
As we had a considerable amount of backend code running from the vanilla JS version we developed early on, we didn’t want to revise all of it just to match our new GWT frontend. That’s why we decided to stay with JSON for communication between our frontend and backend. With this approach, we were able to re-use nearly 100% of our backend functionality without losing anything. The web really is a great place to be a dev. 🙂
We believe that seeing is believing. So, want to see what can be achieved with GWT and GWTP? Have a look at the screenshots of Ruxit below, or better yet, sign up for a free trial of Ruxit.
We’re very proud of our results with GWTP. Having started several additional projects since then, no one was looking for a new development alternative when a new project came around.
Subscribe to our newsletter to be notified when the next post comes out!