Stay the fuck away from JSF . I have had to deal with this piece of shit since version 1.0. It is because the J2EE enterprise App Servers and tooling vendors have managed to convince big corporate CIOs that JSF equals programmer productivity.It is such a lie but who's gonna tell the emperor he is naked ? JSF still has issues with concurrency and memory usage. And forget about adding new ajax widgets to your page without tearing out what is left of your hair. You will write 50 lines of javascript widgets code and then a million lines of wrappers for your widget. You can't even see what your UI looks like without writing a ton of stubbing code. I could go on but my hair is on fire just thinking about all the shit I have had too deal with when using JSF.
Have to agree, JSF is the worst kind of J2EE committee-designed, overengineered nonsense. It is the EJB of web frameworks. The component-based philosophy behind it is sound, but is much better executed by frameworks like Tapestry and Wicket.
That said, modern web apps are all about fat JavaScript clients, enabled by much better frameworks, GWT being one of them.
Having been part of a team developing JSF components in the 1.x days, couldn't agree more.
A few hacks enabling us to use it alongside Facelets, made the whole experience better, but it still left much to be desired. Specially when tracking down bugs related to components misbehaving.
I did revisit the JSF world a couple of months ago and am quite happy that it only lasted a few weeks.
Nowadays I will advise anyone against it. Just use pure JSP with taglibs or any other Java web stack that embraces the HTTP way of working.
This isn't accurate at all. 1) AngularJS was not built by Java developers at Google. Further, it's not clear if the original authors were Java developers. 2) JSF was built by the guy who created Struts, which he did to because he was unhappy with how Struts worked. 3) I wouldn't describe JSF as a Java/XML framework, it's intended to be a component framework.
1. You're wrong on the 1st point again. Misko is a Java developer and he created Angular JS - also the way Angular supports Dependency Injection, was inspired by the way it's done in Java land. https://docs.angularjs.org/guide/di
2. No one said he wasn't that guy so this point is moot.
3. You're wrong there too, If you've done any JSF programing you would know that Facelets tags/components need valid XML elements when the UI is declared. So basically there are 2 things that you need to know to use JSF - Java and XML which makes is a Java/XML based Web development framework.
It looks like Google doesn't want to push more developers to GWT, instead they want devs to use Dart and Polymer, if you check the bottom of this link https://developer.chrome.com/home GWT is no where to be seen.
Just saying that GWT might not a have good future.
Google is a big place; Dart and Polymer are funded as products under the Chrome division (that has budget to spend on big teams and marketing and developer advocates like Seth Ladd).
GWT is under the platform/languages team, e.g. the same org structure that manages Google's contributions to, say, GCC.
So, right, it's not surprising that there is not a lot of marketing pizzazz around GWT, but I don't think that fundamentally affects it's future viability.
Frankly, I'd be much more surprised to see Dart go away than GWT: a) GWT translates to JS, which will be here forever, and b) there are literally 1000+ projects (both public apps and LOB-type stuff) inside of Google that use GWT.
If Dart can't get over the hump and truly become a first-class citizen, eh...
> The GWT programming model means that the web page is viewed from an object oriented point of view [...] this [...] ends up not being that helpful and often gets in the way of the developer more than anything else.
Maybe true in terms of UI building, but for modelling large (web) applications, I have found having a mature and full-featured object oriented language at my disposal tremendously helpful. Of course when refactoring the static typing is very useful, too.
GWT doesn't mandate MVC, and it is not meant to "hide the Web", it states as such in the original mission statement. GWT is three things: a cross compiler to Javascript, a development environment, and a bunch of libraries that are layered. GWT != HTML Panel. The naming is unfortunate, GWT really should have been called 'j2js' or some such, to emphasize the fact that its most important function is an optimizing compiler (it is not a transpiler)
You can build GWT applications that use nothing but HTML templates, low level jquery-like operations, and avoid all of the high level MVC cruft, in fact, many GWT applications, like Google Flights or Google Shopping Express are built exactly this way. I wish the Widget system had never been layered on top (along with MVP) because it gave people a false sense that it was the only way to use GWT, and it was primarily useful for supporting older browser like IE6. There was a justification of 'hiding' some of the Web when you had to bridge IE6 to modern, and many third party JS libraries took similar approaches at the time. The days of IE6 support were painful and once of the reasons for the success of GWT in enterprise is all of those WinXP IE6 desktops.
The primary pain of using GWT these days is the compile times, and the overhead of interacting with Javascript (JSNI). Both of these are being solved in GWT 3.0 along with language boilerplate complaints thanks to Java 8. For example, here is an example of GWT using Polymer components effortlessly https://www.youtube.com/watch?v=wFMD1GXR2Tg
GWT 3.0 deprecates the old DevMode and replaces it with a fast incremental compiler. It replaces JSNI with a new @JsType interface. It boils away asynchronous callback boilerplate with auto-conversion of Java8 lambdas to JS functions and vice versa. The new DOM apis will be auto-generated as @JsType interfaces by directly reading W3C IDL specs, not hand-written as they are today. And it will be possible to read JsDoc and TypeScript interfaces and extract API interfaces from them.
GWT 3.0 will be about lowering the barriers, the friction, between the Web, JS, Native, and GWT code bases, to make polyglot programming as easy as possible. It will also be about hybrid apps, that are part native, part web. See the new Google Sheets 2.0 as an example, it's Java code cross-compiled via j2objc and married with a native UI on iOS, and cross-compiled with GWT and married to Closure UIs on the Web.
I'm endeavoring to make things "and" not "either-or", to give developers as much choice to use as little or as much of GWT as they want. As an example, see AngularGWT, which uses AngularJS 'as is' but lets you write Angular controllers, directives, etc in Java, including using JSR303 BeanValidation to do form validation in Angular.
Once again GWT is rebooting and has a whole new way of doing things as an effort to take over the world, at the expense of people who bought into one of the previous visions and have large legacy code bases.
Every release since 1.5 (which is as long as I've been paying attention) has come with an entirely new best practices paradigm and neglect for keeping the penultimate new shiny working. Remember deRPC? Integration with Spring? LayoutPanels? Activities and Places? Is RequestFactory even part of this brave new 3.0 world, or is it all supposed to be JSON now?
There's a severe mismatch between the people that develop GWT, who seem to wish they were working on a bleeding edge library in a trendy language and be popular among social start-ups, and the people that use GWT, largely enterprise programmers working on LOB applications. That doesn't seem to have changed any with the new council model.
It doesn't matter how many times the project pivots, the hipsters are never going to use java. Much better to care about the users that have actually adopted GWT -- people that want backwards compatibility, stability, and bug fixes.
A project that closes the majority of longstanding bugs with status ASSUMEDSTALE rather than fixing them really doesn't care much about its existing users. Or new ones really, since many of those old bugged classes don't have formal deprecation notices on them.
> Once again GWT is rebooting and has a whole new way of doing things as an effort to take over the world, at the expense of people who bought into one of the previous visions and have large legacy code bases.
Same could be said for new-again JS frameworks popping up every year or so. If your legacy code is in any previous JS framework it's not going to magically update itself to the latest hotness.
> It doesn't matter how many times the project pivots, the hipsters are never going to use java
GWT isn't aimed at hipsters. The changes are for the people using it already, who want to build things and would like improvements. Not to convince the cool kids that they need to replace their 1-line monkey-patching nirvana with objects and static typing.
It's not about building something in less time or abstracting away the document model because we don't understand it. It's about not losing your mind a year later when you need to make a change. It's about refactoring cleanly and knowing that when something has compiled, a whole class of problems is off the table.
You are right that GWT has been a lot of things over the years, but, to be fair, it's been around since 2006. E.g. you mentioned the GWT 1.5 release, that was in 2008.
What other web (or client-side JS) frameworks that were released in 2008 look today at all like they did back then? Or how many of them even still exist/are actively maintained?
GWT's biggest obstacle is it's continuity.
Take the circa-2010 MVC/RequestFactory push; in retrospect, that (and LayoutPanel, and Spring Roo integration, and...) should have been completely separate "webapp frameworks for GWT", not "in GWT".
Then they could have gotten some users, e.g. picked up by that era's greenfield LOB apps, and then quietly aged away. Just like the normal life cycle for any other legacy webapp framework.
But because it's under the "GWT" roof, it lives on, and people have expectations that it'll supported by the GWT team just as much as the core "Java to JS" translation engine.
So, yes, all of your criticisms are valid.
But I assert GWT has learned its lesson: the language (GWT's j2js compiler) should be divorced from frameworks (GWT widgets, userland, etc.), because they really are separate things, and can better evolve on their own. Unfortunately it'll be a hard transition process.
GWT hasn't ever rebooted, unless you count HostedMode -> DevMode. It has removed hardly any of the old APIs going back to 2006, which is part of the problem. Everything you refer to was an add-on layer of functionality that did not remove the old. Every single platform adds new layers. Windows, Android, iOS, J2EE. Each release brings new and better ways to do things.
We have paid the price of actually supporting the old APIs for too long.
1) GWT widgets were designed to overcome IE6 memory leaks and layout deficiencies. IE6 is gone, not even Microsoft supports it any more.
2) deRPC was an experiment and marked as such. It did not change the API calling surface or semantics, and apps could switch between the two very easy. The theory of deRPC was that it would be faster than deserialization code, that turned out to be wrong for most browsers. To make deRPC work required all kinds of hacks in the compiler, in DevMode, and yet another symbol map format. Removing it makes GWT better. It's also incompatible with CSP and introduces yet more security surface area to worry about.
3) Google applications like Adwords continue to rely on old GWT APIs, and we have been fixing serious core bugs as we find them, but we are not a large team and we have to support over 3,000 internal engineers. Part of the reason GWT is now controlled by an external committee is because the focus of Googlers is to prioritize and fix bugs for internal applications, that's how we continue to keep our jobs. GWT is an open source project, and if a particular bug is not getting a lot of love, we invite either the contribution of a patch, or to talk to ArcBees, Vaadin, or RedHat who are providing commercial support.
4) Issue Tracker, I talked about this in my Google I/O announcement of the steering committee: The reality is, around 2009, as GWT got more internal popularity at Google, engineers paid more attention to the internal Google issue tracker rather than the external one, and the external one became unreliable as a source of truth. This was a bad situation caused by the mostly exclusive control of GWT by Google, which is why I advocated turning over control to external users, and moving the entire GWT development process back to non-Google infrastructure (until the recent change, our internal source repository was the real source of truth). Ideally, we'll eventually move everything to GitHub.
So yes, from about 2009-2012, honestly, we didn't pay attention to external users bugs, we prioritized internal bugs. We're trying to rectify that now, but we can't tell which of the thousands of issues in the issue tracker dating back to 2006 are still unfixed and how many got fixed and no one ever marked them closed. The 'ASSUMEDSTALE' status is an attempt to crowdsource the fixing of the issue tracker, since we assume if someone had starred a bug, and it got closed, they will complain it's not fixed, which gives us valuable feedback. Once he issue tracker is triaged back a usable state, we'll be in a better place.
It's not like other projects don't aggressively close bugs, many use robots which auto-close bugs are a few months.
5) We are not just trying to get "the cool kids". The world has changed since 2006. The modern browser environment is substantially different. Javascript VMs have evolved a lot. Mobile browsers are now a substantial force. The world is changing, Google, who is the biggest backer, writes bleeding edge web apps, and so changes with it. We don't get paid if we can't support the kinds of apps Google wants to write, and that's increasingly a modern Web world. If someone else things this is a bad idea, they can fork GWT, freeze it in time so support the Windows XP/IE6 legacy, that's the power of open source.
The steering committee is already planning to keep the 2.7.x line updated with bug fixes from the 3.x line.
Did you ever saw a GWT application that was not done using the GWT hierarchy of widgets, apart from Google Flights or Google Shopping Express?
Because I have seen many GWT apps and I never saw GWT being used that way, I can't see how a very large portion of developers completely misunderstood the right way of using a framework.
Usually the full GWT ecosystem is used in order to build enterprise apps: templates in UIBinder, GWT widget hierarchy, MVP frequently not always, Editor often, Request Factory often, etc.
You mention that the problem is compilation times, but this is not a problem. In Dev mode there is no need for compilation, the compilation happens in the background in the build server whenever a release is needed.
What you describe for GWT 3 seems way more complex that just using plain Html, CSS and Javascript with some framework on top.
I don't see how all that complexity of compilers and plugins and dev modes can pull it's weight compared to one 100k js file.
>Did you ever saw a GWT application that was not done using the GWT hierarchy of widgets, apart from Google Flights or Google Shopping Express?
Fights, Hotels, Shopping Express, Wallet, Google Sheets, Collide, Animatron AFAIK, Angry Birds and most PlayN games, I'm on vacation now, but if I was at my desk could probably did up a lot more Google internal ones. Also look for projects using GwtQuery.
>You mention that the problem is compilation times, but this is not a problem. In Dev mode there is no need for compilation, the compilation happens in the background in the build server whenever a release is needed
DevMode is going away. The NPAPI APIs we used have been taken from us by the browser vendors. Neither Chrome nor Firefox support the ability of DevMode to run anymore. IE will probably continue to work because of how slow they retire older browser versions and APIs. No mobile browser engine not Mobile IE, not iOS Safari, nor Android browsers, supports DevMode.
That is, the very majority of the market has locked down plugin APIs (for good security reasons), which unfortunately means the way GWT was inserting the JVM as a JS bridge during development will no longer work. The new path forward is SourceMaps + Fast incremental draft compilation.
As for complexity in GWT 3.0, the idea is you just use HTML and CSS, and any JS you want, and SuperDevMode for any Java.
As for how the compiler can justify it's existence, that's primary a question of aesthetics for Java developers who prefer their existing tools, and for people who prefer optimized code.
And the SuperDevMode in GWT 3.0, will it be browser-only debugging like the current experimental SuperDevMode?
Because if it's browser only, then it would pose a problem for most Java developers, that like you mentioned prefer their existing tools, in this case the IDE-based debugger.
Note that GWT 3 will see the birth of incremental compiler plus super dev mode, which will actually be FASTER than Dev Mode.
I don't know about you, but the dev-mode lag of jumping back and forth between browser and jvm actually makes dev mode painful to use, especially on very large projects that can take many seconds to reload fresh code.
As someone who does work a lot on raw js projects using GWT (including Collide, as mentioned by Ray), I can say I'm very happy to see widgets de-emphasized in favor of using html5 features, like web components.
When I'm building a view, I rarely care about a widget hierarchy; rather, I just want to construct some html, inject some css, and attach some event listeners.
Writing my business logic in java means I can share it with web, android and ios (via j2objc); for that web view, I'm building html, and rarely need the abstractions provided by widgets. If I do need widgets, I usually use a composite with ui binder so I can control the html myself anyway.
Wow, this is fantastic. After a couple years of heavy use, I abandoned GWT during the lost-its-marbles insanity of MVP and and what appeared to be a concerted effort to give GWT all the grace of EJB2.0. I still miss GWT-RPC, dead code detection, static typing, and the sane deployment model. GWT3 could bring me back.
One thing that always bugged me though is the mismatch between Long and JS numbers. GWT is trying to be pedantically accurate with numbers, which is great from a "compile Quake and see it run on the client" perspective but incredibly annoying when trying to interop with native JS code. Many of my ids are numbers; I need these numbers to easily convert to JS numbers - and yes, I do actually know that they will fit within JS precision. Does GWT3 fix interoperability between Java Long and JS Number?
If you want IDE based debugging for sourcemaps, please see http://github.com/sdbg/sdbg which is a sourcemap (super dev mode / draft compile) based eclipse plugin, for making java debugger speak chrome debugging protocol.
The project needs more users to try it out, report reproducible issues, and drive its development.
I was expecting a lot more direct comparisons based on the link name. Would probably have been nice to see some of the numbers around the origin, specifically. "we could build the application (Google Feedback) much faster than we could build it in GWT" only goes so far to say that Angular can be faster to develop in.
Kind of thought that Angular is a bit like VB <cue shrieks and screams>.
Both allow relative novices to produce sophisticated GUIs rather quickly. Both require a fairly high level of understanding discipline, and organization to produce high quality large-scale products. Frankly, GWT sort of fits that description as well.
- Both Angular and VB make it easy to get a "pretty" GUI up and running quickly.
- Both Angular and VB require quite a bit more knowledge to make a more sophisticated application beyond a simple interface.
- There are plenty of other languages that are difficult to get even a simple example up and running, but tend to force certain organization and partitioning from the start.
So it is always necessary to have "high level of understanding discipline, and organization to produce high quality large-scale products." It just seems to me that Angular (like VB) is extra easy for simple things and extra hard for sophisticated things.
A specific example - Angular directives. You can happily code for quite awhile without defining your own. Until one day you decide to integrate another library and then need to "wrap" all of your code.
Another example, Angular is described as working with jQuery (which it does). However, if you don't understand Angular's event loop and start doing jQuery stuff outside of it, mayhem ensues.
>A specific example - Angular directives. You can happily code for quite awhile without defining your own. Until one day you decide to integrate another library and then need to "wrap" all of your code.
which you can define a directive for, and thus an interface. This is probably the safest way to use external libraries.
>Another example, Angular is described as working with jQuery (which it does). However, if you don't understand Angular's event loop and start doing jQuery stuff outside of it, mayhem ensues.
I admit if you don't understand how angular really works (and most who use them probably don't, including me) it is hard to get this. But, if you restrict UI manipulations to directives (as suggested by angular), you can probably avoid mayhem
AFAIK it was more inspired by Adobe Flex (though like WPF and other frameworks, Angular took the data binding idea further with full two-way binding), which predated WPF (at least in terms of public releases) by a couple of years.
But the big thing missing is the old javascript pain point : if your frontend is in javascript, and your backend in C++ or java or php or python, you will have translation issues between the two. Things will go wrong. Server and client don't handle the "RPC" quite the same way. This will bite you again and again.
If you have a real one-page (the only way to go responsive) web-app, once you hit a certain level of complexity GWT is the only way to go. Javascript <> Frontend <> middleware <> backend <> database (using the right framework), all statically typechecked. You NEVER get a fieldname wrong. Checking if a call works ? You don't write tests for that, because static typing means it works. Need the same RPC calls to work for an iOS app, an android app, a desktop app, ... ? They can share all the model code (literally, the same lines of code, same bugs, same everything) and only need custom views and controllers (which you'd have to do differently in any language). Backend is simply identical, and java supports secure RPC to all these platforms, all of whom process data in exactly the same way.
Plus : GWT makes dynamically creating user interfaces tolerable, something I still have nightmares of doing in javascript.
But my main complaint is controlling complexity : in javascript, you can forget about it. 500-1k lines of javascript nicely working together really does mean you have a good programmer. You can effectively not load more than 1 javascript library without unwanted interactions (exception being the many Google libraries that do seem to work together, but combine them with jquery and you'll already see surprises). The point where complexity starts exploding is very low. PHP/Perl/Python/C is a little better : you can generally expect a good programmer to be able to get ~10000 lines to work together nicely without very serious problems. Java/C#/C++ allow you to control complexity on a large scale. 100k, 1 mil, 10 million line codebases are possible and (can be) maintainable in those languages. Now keep in mind that sucky programmers suck in any language, I'm talking about good programmers
Yes, angular is really fast to make a tiny form with "standard" functionality. If you think that's going to do anything more than get you a standard app without armies of programmers (like Google has), you're deluding yourself.
Plus let's state the obvious here : people hate javascript for good reason. Good language, considering it was a weekend hack, but horrible language compared to anything else out there. Java, flawed as it is, is massively better than javascript. Also : once GWT frees you from frontend/backend integration and ridiculous testing you won't want to go back, and of course there's the java library ecosystem that is very extensive indeed.
Considering that most Google Apps (GMail, G+, Docs, Calendar, etc.) are single-page webapps with over a million lines of JS, I'd hardly say "GWT is the only way to go". The programmers I know at Google who worked on complex GWT apps (notably Google Base and Adwords 3) didn't have very many nice things to say about it, besides the Eclipse integration.
The Java/JS integration is handled the same way it's handled in any large distributed system: define a protocol for the server and client to communicate. Only evolve the protocol in backwards-compatible ways. You need to do this anyway if you expect user sessions to survive server upgrades, because you may have an old client talking to a new server. I'm curious how GWT handles this case - if it's autogenerating communication responses, it needs to be aware of both old and new versions to safely upgrade them.
I'm most familiar with GWT-RPC and it doesn't have any backward compatibility built in, so most deploys are a protocol change. (It does at least give you a clear error when there's a protocol mismatch.)
So if you want old user sessions to survive, you'll need to keep the old service available until they reload the page.
There are protobuf/JSON-based alternatives with a better compatibility story.
It's not true that most deploys are a protocol change - only changes that would also change Java serialization's serial UID will cause GWT-RPC clients to become incompatible.
I routinely deploy a new version while hundreds of users are online and nobody is the wiser.
Actually there is backwards compatibility in the same sense as there is binary compatibility. Have a mechanism to force upgrades, ideally conserving state. Leave the old call in place for 1 version.
This is not difficult.
Protobuf/JSON alternatives don't even have frontend-backend compatibility in the same version. Protobuf in java has completely different encoding to normal protobuf, meaning you need TWO protobuf libraries in your backend, and of course javascript protobuf messages don't actually support anywhere near the language set that protobuf itself supports. Those are reasons why calling it protobuf is misleading. The data structures don't mean the same thing in the frontend and the backend.
Funny you mention docs... The new Google Sheets (y'know, that awesome spreadsheet app that lets you write javascript macros with a full in-browser debugger), is written in GWT.
As I understand it, Google does not write apps in javascript, at all. The language closest to javascript that they do use is closure [1]. Closure is technically a javascript to javascript compiler but it makes the language
1) compiled, not interpreted
2) strongly typed (not optional typing according to the google style guide [2])
So yes, there are large javascript applications. In the same sense that KDE is an extremely large C application, or that the linux kernel is written in assembly. Only not really written in javascript.
(I worked at Google, with Closure, on some of these large JS apps. The Closure tech lead responsible for open-sourcing it is a friend of mine.)
It's true that all of Google's major customer-facing apps use Closure. However, I would not consider it to be a separate language, but rather a large component library and toolchain for developing JS apps at scale. The language is identical to Javascript, and Closure apps can be run uncompiled, they just take up more bytes on the wire and give the programmer weaker error-checking.
It is also very possible to write Closure without the type declarations - I've done it, frequently, for various doodles & easter eggs. They are non-optional according to the styleguide, but that's a style choice mandated for large teams. Typically, type annotations make working with large multi-developer JS apps much easier, but they're unnecessary for smaller one-off projects.
Also, any JS developer off the street can download Closure and use it to write JS apps, since it's open-source. If they want to use Closure Compiler they will probably have to forgo certain language features; I once tried to get JQuery to compile with it and it was basically a total loss. But the language should be completely familiar to anyone accustomed to working with Javascript. (You probably don't want to do this if you just have a small startup, since both the compiler and class library are designed for working with very large-scale apps and pay a large verbosity penalty for keeping things manageable, but it's possible.)
And you can implement C as a set of assembler macros and a preprocessor step (which can be part of any C compiler). That does NOT make C and assembly the same language. The same is true for large C++ codebases. Nobody claims they're valid C, even though they're one preprocessing step away from being one.
Specifically C is "smaller". Everything in C can be expressed in assembly, but not every piece of assembly code has a matching C code. One hopes that it's mostly the more insane parts of assembly code that can't be translated.
Nobody will argue that C and "text" assembly are the same language. In the same way, I argue that javascript and closure are very, very different. Generally, assuming google actually demands closure apps compile with the toolchain (I'd be astonished if they didn't), these languages are not the same, despite one being valid in the other.
Javascript further clouds this issue by allowing preprocessing steps in the language itself. If you don't take that into account, you could say python is valid javascript. That's not a reasonable claim.
