Why GWT?
- Mature technology stack backed by Java(OOP & strong typing is a huge win on large projects)
- Debugging tools
- By using Java, code maintenance & refactoring becomes really fun to do
- Comprehensive, easily restyled widget library + GWT designer to build complex GUI interfaces
- Security against JavaScript attacks
- Logging
- Accessibility
- Internationalization
- Data transport / management mechanisms
- Crossbrowser
- MVP framework
- Unit testing framework
- HTML5 support
- Open-source
- Tons of great libraries & frameworks (Mvp4g, GwtQuery)
- Strong and active community, supported by Google
- Deployment & optimization tools
- Scales well by increasing number of developers
And one of the major advantages of GWT is:
At the end, it’s still javascript, which means that you can leverage all existing javascript/HTML5 technologies either by using plugins or by writing native javascript through JSNI
Cons:
- Initial java-related overhead for setup/configuration (dev-mode, special plugins for modern browsers, etc.)
- Speed of development is highly affected, you need top-notch hardware to comfortably write code
- A lot of data abstraction layers are highly coupled with Java backends
- Relatively high entrance threshold for new developers
You might want to check out feature comparisons matrix for different javascript frameworks as well.
Spike scenarios to examine different technology stacks
- Data abstraction, packaging, event-binding spike. There should be a simple form with one textfield. As you type, 2 different widgets on the test page should update themselves with a data from textfield. Those 2 widgets should be controlled by independent business logic in separated packages(modules) of application.
- Form validation spike. This will examine how easy it is to validate user data, including validation made on server-side.
By implementing first spike & evaluating your solution, ask yourself about units of functionality that will make up your future application:
- How will those pieces be organized into units of code?
- How will those pieces communicate with each other?
- How will dependencies between components be expressed and managed while adhering to the principle of loose coupling?
- How will components manifest themselves in the DOM? Do they need to?
- How will we persist data across URL and page loads?
- How will we manage communication with the server?
- How will we make sure users only see the data they’re allowed to see?
There is no spike whatsoever which can show you strengths of GWT in managing large-scale apps right away. This is obvious — until you’re going to play with some trivial samples, it might look as an unnecessary technology overhead. But it greatly pays off in the long run. Our 2+ years of frontend development proved GWT to be the right choice.
You might be interested to investigate why others are using GWT & what are the type of projects being built.
Hidden cost of transition from GWT to javascript
What if, after huge investment in GWT you decided to switch back to Javascript?
That is a pretty serious question from the business perspective. Remember, that we’re talking about apps here, not web-pages. This means, that your existing GWT application already carries a lot of complex business logic, it’s not a simple presentation layer as one might think.
Keeping this in mind, you’ll probably end up with:
- Complete rewrite of application (you’d better want to spent this time for new valued features to compete in your market, don’t you?)
- Hiring pretty expensive javascript-gurus (you don’t want those numerous folks writing random jQuery snippets to develop your complex business-logic app, do you?)
Page 3 of 4 | Previous page | Next page