8 ms·

The Java Origins of Angular JS: Angular vs. JSF vs. GWT

66 points by tilt 12y ago

taeric 12y ago
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.
mc 12y ago
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.
- sehr 12y ago
  Cant comment on the rest of it, but angular's creator was definitely a Java guy before getting into JavaScript. http://www.youtube.com/watch?v=HCR7i5F5L8c 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)
- suyash 12y ago
  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 12y ago
    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 .
catwork 12y ago
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 12y ago
  >Both require a fairly high level of understanding discipline, and organization to produce high quality large-scale products. When is that not the case?
  - jackweirdy 12y ago
    Bouncy Castles. You just plug the air in and they get really big on their own
  - catwork 12y ago
    - 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 12y ago
      >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
cromwellian 12y ago
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
nailer 12y ago
Angular was not created at Google. It was created at BRAT Tech.
waps 12y ago
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.
- 12y ago
johnyzee 12y ago
> 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.
manishsharan 12y ago
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 12y ago
  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.
- pjmlp 12y ago
  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.
derengel 12y ago
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 12y ago
  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 12y ago
    Dart compiles to JS
_random_ 12y ago
It was actually very much inspired by WPF and it's relatively innovative MVVM pattern.
- georgemcbay 12y ago
  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-about-data-binding/ http://misko.hevery.com/2010/08/10/what-flex-thought-me-abou...

66 points by tilt 12y ago

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.

mc 12y ago

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.

sehr 12y ago
Cant comment on the rest of it, but angular's creator was definitely a Java guy before getting into JavaScript. http://www.youtube.com/watch?v=HCR7i5F5L8c 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)
suyash 12y ago
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 12y ago
  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 .

catwork 12y ago

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 12y ago
>Both require a fairly high level of understanding discipline, and organization to produce high quality large-scale products. When is that not the case?
- jackweirdy 12y ago
  Bouncy Castles. You just plug the air in and they get really big on their own
- catwork 12y ago
  - 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 12y ago
    >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

cromwellian 12y ago

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

nailer 12y ago

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

waps 12y ago

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.

12y ago

johnyzee 12y ago

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

manishsharan 12y ago

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 12y ago
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.
pjmlp 12y ago
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.

derengel 12y ago

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 12y ago
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 12y ago
  Dart compiles to JS

_random_ 12y ago

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

georgemcbay 12y ago
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-about-data-binding/ http://misko.hevery.com/2010/08/10/what-flex-thought-me-abou...