The Java Origins of Angular JS: Angular vs. JSF vs. GWT
blog.jhades.org
blog.jhades.org
That said, modern web apps are all about fat JavaScript clients, enabled by much better frameworks, GWT being one of them.
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.
http://www.youtube.com/watch?v=HCR7i5F5L8c
Jokes in there about how one of the first things he did after learning js was make a framework (super early version of angular)
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.
Just saying that GWT might not a have good future.
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...
Admitted that I'm coming to this with biases.
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.
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.
To be clear, does that include SuperDevMode, or are you referring only to the classic DevMode?
DevMode is still around since it still works on IE. The next release will be GWT 2.7, not 3.0 which is a bit more aspirational.
The project needs more users to try it out, report reproducible issues, and drive its development.
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.
However, we would like to have more modern alternatives available for building a UI, as Ray has been talking about.
The projects I'm familar with use GWT-RPC more than RequestFactory, but otherwise your impression matches mine.
Compilation time is an issue because Super Dev Mode runs the compiler (in draft mode).
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.
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.
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.
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.
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.
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.
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.
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?
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.
When is that not the case?
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.
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
See, for example:
http://misko.hevery.com/2010/08/10/what-flex-thought-me-abou...
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.
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.
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.
I routinely deploy a new version while hundreds of users are online and nobody is the wiser.
But this can be tricky for large, distributed projects, where the author of a class might not even be aware that it's used with GWT.
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.
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.
[1] https://developers.google.com/closure/
[2] http://google-styleguide.googlecode.com/svn/trunk/javascript...
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.)
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.