A superheroic Javascript framework needs a good origin story. Let’s try to patch it together, while going over the use of Angular JS in the enterprise Java world and the Angular take on MVC.
This post will go over the following topics, and end with an example:
- The Java Origins of Angular JS
- Angular vs JSF
- Angular vs GWT
- Angular vs jQuery
- The Angular take on MVC (or MVW)
- The M in MVC – Scopes
- The V in MVC – Directives
- The C in MVC – Controllers
The Origins of Angular JS
Angular is becoming a framework of choice for developing web applications in enterprise settings, where traditionally the backend is built in Java and the frontend is built in a Java/XML based framework such as JSF or GWT.
As Java developers often living in the Spring/Hibernate world, we might wonder how a dependency-injection, dirty checking based MVC framework ever managed to jump from the server and into our browsers, and find that to be an interesting coincidence.
The Story Behind Angular
It turns out that the similarities are likelly not a coincidence, because at it’s roots Angular was built by Java Developers at Google, that felt that they where not being productive building frontend applications using Java, specifically GWT.
These are some important quotes from the Angular developers about the origins of Angular, recently on the Javascript Jabber Podcast (transcript link here):
we were building something in GWT and was getting really frustrated just how unproductive I was being.
we could build the application (Google Feedback) much faster than we could build it in GWT.
So this means Angular was effectively created by full-time Java GWT developers, as a response to how they felt that Java frameworks limited their frontend development productivity.
Is JSF or GWT still the way to go?
Although with two very different approaches, one of the main goals of both JSF and GWT is to abstract at least part of the web away, by allowing web development to be done in the Java/XML world.
But it seems that in this day and age of HTML5 browsers, frameworks like JSF/GWT are much more complex than the underlying platform that they are trying to abstract away in the first place.
Although they can be made to work fine, the question is: at what cost?
Often the underlying browser technologies leak through to the developer, which ends up having to know HTML, CSS and Javascript anyway in order to be able to implement many real world requirements.
This leaves the developer wondering why can’t browser technologies be used directly without so many constraints and intermediate layers of abstraction, because in the end there is really no escape from them.
Browser technologies are actually simpler, more widespread and far better documented than any Java framework could ever be.
Historical context of JSF and GWT
It’s important to realize how JSF/GWT came to be in the first place: they where created to be used in scenarios where an enterprise backend already existed built in Java/XML, and a need existed to reuse that same team of enterprise developers to build also the frontend.
From a project management point of view, on a first look and still today this makes a lot of sense.
Also from an historical point of view, JSF/GWT where created in a context where the browser was a much more quirkier platform than it is today, and with a lot less developer tools available.
So the goal of the framework was to abstract at least some of the browser technologies away, enabling it to be used by a wider developer base.
Angular vs JSF
JSF came more or less at the same time as Ajax exploded in the web development scene a decade ago. The initial version of JSF was not designed with Ajax in mind, but was instead meant as a full page request/response model.
In this model, a DOM-like tree of components representing the user interface exists in memory, but this tree exists only on the server side.
The server View then gets converted back and forth to HTML, CSS and Javascript, treating the browser mostly as a rendering platform with no state and limited control over what is going on.
Pages are generated by converting the server View representation to HTML, CSS and Javascript via a set of special classes called Renderers, before sending the page to the user.
How does JSF work?
The user will then interact with the page and send back an action typically via an HTTP POST, and then a server side lifecycle is triggered via the JSF Controller, that restores the view tree, applies the new values to the view and validates them, updates the domain model, invokes the business logic and renders back a new view.
The framework was then evolved in JSF 2 for native Ajax support and stateless web development, but the main approach of generating the HTML in the browser from a server side model remained.
How does Angular compare to JSF
The main design difference is that in Angular the Model, the View and the Controller where moved from the server and into the browser itself.
In Angular, the browser technologies are not seen as something to be avoided or hidden, but something to be used to the full extent of it’s capabilities, to build something that is much more similar to a Swing fat client rather than a web page.
Angular does not mandate this, but the server typically has very little to no state and serves mostly JSON via REST services.
How important is Javascript in JSF?
The take of JSF towards Javascript seems to be that the language is something that JSF library developers need to know, but usually not the application developers.
The most widespread JSF library Primefaces contains internally thousands of lines of Javascript code for it’s jQuery based frontend widgets, but Primefaces based projects have often very little to no Javascript on the application code base itself.
Still, in order to do custom component development in Primefaces, it’s important to know Javascript and jQuery, but usually only a small part of the application team needs to know it.
Angular vs GWT
A second generation take on Java web development on the browser came with the arrival of GWT. In the GWT take, the Model, View and Controller are also moved to the browser, just like in Angular.
The main difference is the the way that Javascript is handled: GWT provides a Java to Javascript compiler that treats Javascript as a client side bytecode execution engine.
In this model the development is made entirely in Java, and with a build process the code gets compiled down to Javascript and executed in the browser.
The GWT take on HTML and CSS
In GWT, HTML and CSS are not meant to be completely hidden from the developer, although XML namespaces are provided to the user to layout at least some of the page major blocks.
When getting to the level of forms, an HtmlPanel is provided to allow to build pages in HTML and CSS directly. This is by the way also possible in JSF, although in the case of both frameworks typically developers try to avoid as much as possible HTML and CSS, by trying to use the XML namespaces to their maximum possible extent.
Why the Javascript transpilation aproach ?
GWT is not so different from Angular in a certain way: it’s MVC in the browser, with Javascript being a transpilation target rather than the application development language.
The main goal of that transpilation is again reusing the same developer team that builds the backend as well, and abstracting away browser quirks.
Does the GWT object oriented approach help ?
The GWT programming model means that the web page is viewed from an object oriented point of view: the page is seen in the program as a network of interconnected objects instead of a document.
The notion of document and elements are hidden away by the framework, but it turns out that this extra level of indirection altough familiar, ends up not being that helpful and often gets in the way of the developer more than anything else.
Is the extra layer of abstraction needed?
The fact is that the notion of page and elements are already simple and powerful enough so that they don’t need an extra layer of abstraction around it.
With the object oriented abstraction of the page, the developer often ends up having to debug it’s way through a myriad of classes for simple things like finding where to add a or remove a simple CSS class or wrap an element in a div.
Super Dev Mode helps, but it feels like the whole GWT hierarchy of objects, the Java to Javascript compiler and the several debug modes and browser and IDE plugins ecosystem are all together far more complex that what they are trying to hide away in the first place: the web.
Angular vs jQuery
Meanwhile and in parallel in the Javascript world, a new approach came along for tackling browser differences: the idea that a Javascript library can be created that provides a common API that works well in all browsers.
The library would detect the browser at runtime and adapt internally the code used so that the same results occur in all browsers.
Such library would be much simpler to use as it did not require browser quirk knowledge, and could appeal to a wider development base.
The most successful of those libraries is jQuery, which is mostly a page manipulation library, but it’s not meant to be an MVC framework.
jQuery in the Java World
Still jQuery is the client side basis of the most popular JSF framework: Primefaces. The main difference between Angular and jQuery is that in jQuery there is no notion of Model or Controller, the document is instead directly manipulated.
A lot of code like this is written if using jQuery (example from the Primefaces Javascript autocomplete widget):
this.itemtip = $('<div id="' + this.id +
'_itemtip" class="ui-autocomplete-itemtip
ui-state-highlight ui-widget
ui-corner-all ui-shadow"></div>')
.appendTo(document.body);As we can see, the Primefaces developers themselves need to know about HTML, CSS and Javascript, altough many of the application developers use the provided XML tags that wrap the frontend widgets, and treat them as a black box.
This type of code reminds of the code initially written in Java development, when the Servlet API came along but there weren’t yet any JSP’s:
out.println(" " + message + "");What Angular allows is to decouple the Model from the View, and loosely glue the two together with a Controller.
The Angular JS take on MVC (or MVW)
Angular positions itself as MVW framework – Model, View, Whatever. This means that it acknowledges the clear separation of a Model, that can be a View specific model and not necessarily a domain model.
In Angular the Model is just a POJO – Plain Old Javascript Object.
Angular acknowledges also the existence of a View, that is binded declaratively to the Model. The view is just HTML with some special expression language for Model and user interaction binding, and a reusable component building mechanism known as Directives.
It also acknowledges the need to something to glue the Model and the View together, but it does name this element hence the “Wathever”. In MVC this element is the Controller, in MVP it’s the Presenter, etc.
Minimal Angular Example
Let’s go over the three elements of MVC and see what do they correspond in Angular by using a minimal interactive multiplication example, here it is working in a jsFiddle.
As you can see, the result is updated immediately once the two factors change. Doing this in something like JSF or GWT would be a far larger amount of work.
What would this look like in JSF and GWT?
In JSF, for example in Primefaces this would mean having to write a small jQuery plugin or routine to add the interactive multiplication feature, create a facelet template, declare a facelet tag and add it to the tag library, etc.
In GWT this would mean bootstraping a sample app, creating a UI binder template, add listeners to the two fields or setting up the editor framework, etc.
Enhanced Developer Productivity
We can see what the Angular JS developers meant with enhanced productivity, as the complete Angular version is the following, written in a few minutes:
<div ng-app="Calculator" ng-controller="CalculatorCtrl">
<input type="text" ng-model="model.left"> *
<input type="text" ng-model="model.right"> =
<span>{{multiply()}}</span>
</div>
angular.module('Calculator', [])
.controller('CalculatorCtrl', function($scope) {
$scope.model = {
left: 10,
right: 10
};
$scope.multiply = function() {
return $scope.model.left *
$scope.model.right;
}
});So let’s go over the MVC setup of this sample code, starting with the M.
The M in MVC – Angular Scopes
The Model in Angular is just a simple Javascript object. This is the model object, being injected into the scope:
$scope.model = {
left: 10,
right: 10
};Injecting the model into the scope makes it dirty checked, so that any changes in the model are reflected immediately back to the view. In the case of the example above, editing the factor input boxes triggers dirty checking which triggers the recalculation of the multiplication, which gets instantly reflected in the result.
The V in MVC – Enhanced HTML
The view in Angular is just HTML annotated with a special expression language, such as the definition of the multiply() field. The HTML is really acting in this case as client side template, that could be split into reusable HTML components called Directives.
The C in MVC – Angular Controllers
The CalculatorCtrl is the controller of the example application. It initializes the model before the view gets rendered, and act’s as the glue between the view and the model by defining the multiply function.
The controller typically defines observers on the model that trigger event driven code.
Conclusions
It seems that polyglot development in both Java and Javascript is a viable option for the future of enterprise development, and that Angular is a major part of that view on how to build enterprise apps.
The simplicity and speed of development that it brings is attractive to frontend Java developers, which to one degree or another already need to deal with HTML, CSS and often Javascript anyway.
So an attractive option seems to be that a portion of enterprise application code will start being written in Javascript using Angular instead of Java, but only the next few years will tell.
An alternative way of using Angular
Another possibility is that Angular is used internally by frameworks such as JSF as an internal implementation mechanism.
See for example this post from the lead of the Primefaces project:
I have plans to add built-in js mvc framework support, probably it will be angular.
So it’s possible that Angular will be used as an implementation mechanism for technologies that will follow the aproach of keeping the application developer experience to be Java and XML based as much as possible.
One thing seems sure, Angular either as an application MVC framework or as an internal detail of a Java/XML based framework seems slowly but surely making it’s way into the enterprise Java world.
Related Links:
A great online resource for Angular: The egghead.io Angular lessons, a series of minimal 5 minutes video lectures by John Lindquist (@johnlindquist).
| Reference: | The Java Origins of Angular JS: Angular vs JSF vs GWT from our JCG partner Aleksey Novik at the The JHades Blog blog. |
