
The Java Origins of Angular JS: Angular vs. JSF vs. GWT - tilt
http://blog.jhades.org/the-java-origins-of-angular-js-angular-vs-jsf-vs-gwt/
======
manishsharan
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.

~~~
johnyzee
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.

------
mc
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.

~~~
suyash
Check the facts before your blurt it out!

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](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.

~~~
nailer
1\. He's right - if by 'built' you mean 'designed and created at' rather than
just 'worked on'. See
[http://en.m.wikipedia.org/wiki/AngularJS#Development_history](http://en.m.wikipedia.org/wiki/AngularJS#Development_history)
.

------
derengel
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](https://developer.chrome.com/home) GWT is
no where to be seen.

Just saying that GWT might not a have good future.

~~~
stephen
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...

Admitted that I'm coming to this with biases.

~~~
spankalee
Dart compiles to JS

------
johnyzee
> 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.

------
cromwellian
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](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.

[https://github.com/cromwellian/angulargwt](https://github.com/cromwellian/angulargwt)

~~~
bradleyjg
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.

~~~
cromwellian
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.

------
taeric
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.

------
catwork
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.

~~~
JonnieCache
_> Both require a fairly high level of understanding discipline, and
organization to produce high quality large-scale products._

When is that not the case?

~~~
catwork
\- 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.

~~~
pm90
>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

------
_random_
It was actually very much inspired by WPF and it's relatively innovative MVVM
pattern.

~~~
georgemcbay
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.

See, for example:

[http://misko.hevery.com/2010/08/10/what-flex-thought-me-
abou...](http://misko.hevery.com/2010/08/10/what-flex-thought-me-about-data-
binding/)

------
nailer
Angular was not created at Google. It was created at BRAT Tech.

------
waps
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.

~~~
nostrademons
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.

~~~
skybrian
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.

~~~
johnyzee
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.

~~~
skybrian
Well, that's true; it depends on how complex your protocol is and how often
you change it. Simplicity is good!

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.

