A superheroic Javascript framework needs a good origin story. Let’s attempt to spot it together, while going over the use of Angular JS in the enterprise Java world and the Angular take on MVC.
Angular is ending up being a framework of option for developing web applications in enterprise settings, where traditionally the backend is integrateded Java and the frontend is constructed 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, filthy checking based MVC framework ever handled to jump from the server and into our browsers, and find that to be a fascinating coincidence.
The Story Behind Angular
It ends up that the resemblances are likelly not a coincidence, because at it’s roots Angular was constructed by Java Developers at Google, that felt that they where not being productive building frontend applications using Java, particularly GWT.
Angular was successfully produced by full-time Java GWT developers, as a reaction to how they felt that Java frameworks restricted their frontend development productivity.
Is JSF or GWT still the method to go?
Although with 2 extremely various approaches, one of the primary goals of both JSF and GWT is to abstract a minimum of part of the web away, by allowing web development to be carried out in the Java/XML world.
But it appears that in this day and age of HTML5 internet browsers, frameworks like JSF/GWT are much more complex than the underlying platform that they are attempting to abstract away in the first location.
Although they can be made to work great, the question is: at what cost?
Commonly the underlying web browser technologies leak through to the developer, which winds up needing to know HTML, CSS and Javascript anyway in order to have the ability to implement lots of real life requirements.
This leaves the developer questioning why cannot browser technologies be made use of straight without many restrictions and intermediate layers of abstraction, due to the fact that in the end there is truly no escape from them.
Browser technologies are actually simpler, more extensive and far better recorded than any Java framework could ever be.
Historical context of JSF and GWT
It is very important to recognize how JSF/GWT became in the very first location: they where produced to be used in circumstances where an enterprise backend already existed developed in Java/XML, and a requirement existed to reuse that same group of enterprise developers to build also the frontend.
From a project management perspective, on a very first look and still today this makes a great deal of sense.
Also from a historical viewpoint, JSF/GWT where developed in a context where the web browser was a a lot more quirkier platform than it is today, and with a lot less developer tools available.
So the objective of the framework was to abstract a minimum of some of the browser technologies away, allowing it to be used by a broader developer base.
Angular vs JSF
JSF came basically at the very same time as Ajax blew up in the web development scene a decade back. The preliminary version of JSF was not created with Ajax in mind, however was instead meant as a full page request/response model.
In this model, a DOM-like tree of elements representing the user interface exists in memory, but this tree exists only on the server side.
The server View then gets converted backward and forward to HTML, CSS and Javascript, dealing with the web browser mostly as a rendering platform without any state and restricted control over what is going on.
Pages are produced by transforming the server View representation to HTML, CSS and Javascript by means of a set of special classes called Renderers, before writing the page to the user.
How does JSF work?
The user will then interact with the page and return an action usually via an HTTP POST, and after that a server side lifecycle is activated by means of the JSF Controller, that restores the view tree, applies the new values to the view and verifies them, updates the domain model, invokes business logic and renders back a new view.
The framework was then progressed in JSF 2 for native Ajax support and stateless web development, however the main approach of creating the HTML in the browser from a server side model continued to be.
How does Angular compare with JSF
The main design distinction is that in Angular the Model, the View and the Controller where moved from the server and into the browser itself.
In Angular, the internet browser technologies are not viewed as something to be prevented or hidden, however something to be made use of to the full extent of it’s abilities, to build something that is far more comparable to a Swing fat their client rather than a web page.
Angular does not mandate this, but the server normally has hardly any to no state and serves primarily JSON through REST services.
How vital is Javascript in JSF?
The take of JSF towards Javascript appears to be that the language is something that JSF library developers require to understand, but generally not the application developers.
The most widespread JSF library Primefaces includes internally countless lines of Javascript code for it’s jQuery based frontend widgets, however Primefaces based projects have commonly extremely little to no Javascript on the application code base itself.
Still, in order to do custom component development in Primefaces, it’s crucial to understand Javascript and jQuery, but usually only a small part of the application group 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 relocated to the internet browser, much like in Angular.
The primary distinction is the the manner in which Javascript is managed: GWT provides a Java to Javascript compiler that treats Javascript as a customer side bytecode execution engine.
The GWT handle HTML and CSS
In GWT, HTML and CSS are not implied to be totally hidden from the developer, although XML namespaces are offered to the user to design at least some of the page major blocks.
When getting to the level of forms, an HtmlPanel is offered to allow to build pages in HTML and CSS straight. This is by the way also possible in JSF, although in the case of both frameworks generally developers try to avoid as much as possible HTML and CSS, by attempting to use the XML namespaces to their optimum possible level.
Why the Javascript transpilation aproach?
GWT is not so different from Angular in a specific method: it’s MVC in the browser, with Javascript being a transpilation target instead of the application development language.
The primary objective of that transpilation is once more reusing the same developer team that constructs the backend too, and abstracting away browser quirks.
Does the GWT object oriented approach help?
The GWT programming model suggests that the web page is viewed from an object oriented perspective: the page is seen in the program as a network of interconnected objects instead of a document.
The notion of document and aspects are hidden away by the framework, but it ends up that this additional level of indirection altough familiar, winds up not being that valuable and often gets in the method of the developer more than anything else.
Is the extra layer of abstraction needed?
The fact is that the idea of page and elements are already basic and powerful enough so that they don’t require an extra layer of abstraction around it.
With the object oriented abstraction of the page, the developer typically winds up having to debug it’s method through a myriad of classes for basic things like finding where to include a or remove an easy CSS class or cover an aspect in a div.
Super Dev Mode assists, but it feels like the whole GWT hierarchy of things, the Java to Javascript compiler and the a number of debug modes and internet browser and IDE plugins environment are completely far more complex that what they are attempting to hide away in the first place: the web.
Angular vs jQuery
On the other hand and in parallel in the Javascript world, a new technique came along for taking on web browser differences: the concept that a Javascript library can be created that supplies a common API that works well in all web browsers.
The library would discover the web browser at runtime and adapt internally the code utilized so that the same outcomes happen in all browsers.
Such library would be much simpler to use as it did not need internet browser peculiarity understanding, and might appeal to a broader development base.
The most effective of those libraries is jQuery, which is primarily a page adjustment library, but it’s not suggested 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 primary distinction in between Angular and jQuery is that in jQuery there is no notion of Model or Controller, the document is instead straight manipulated.
As we can see, the Primefaces developers themselves require to understand about HTML, CSS and Javascript, altough numerous of the application developers use the provided XML tags that wrap the frontend widgets, and treat them as a black box.
What Angular permits is to decouple the Model from the View, and loosely glue the 2 together with a Controller.
The Angular JS take on MVC (or MVW)
Angular positions itself as MVW framework – Model, View, Whatever. This implies that it acknowledges the clear separation of a Model, that can be a View particular model and not necessarily a domain model.
In Angular the Model is just a POJO – Plain Old Javascript Object.
Angular acknowledges also the presence of a View, that is binded declaratively to the Model. The view is simply HTML with some special expression language for Model and user interaction binding, and a reusable part building mechanism called Directives.
It also acknowledges the have to something to glue the Model and the View together, however it does call this element for this reason the “Wathever”. In MVC this component is the Controller, in MVP it’s the Presenter, and so on
Minimal Angular Example
Let’s review the 3 components of MVC and see what do they correspond in Angular using a very little interactive multiplication example, here it is operating in a jsFiddle.
As you can see, the result is upgraded immediately as soon as the two factors modification. Doing this in something like JSF or GWT would be a far bigger amount of work.
What would this look like in JSF and GWT?
In JSF, for example in Primefaces this would indicate needing to compose a small jQuery plugin or regular to include the interactive reproduction feature, produce a facelet design template, proclaim a facelet tag and add it to the tag library, and so on
In GWT this would imply bootstraping a sample app, developing a UI binder template, add listeners to the 2 fields or setting up the editor framework, etc
The V in MVC – Enhanced HTML
The view in Angular is simply HTML annotated with a special expression language, such as the meaning of the multiply() field. The HTML is truly acting in this case as client side design template, that might be split into recyclable HTML parts 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 increase function.
The controller normally defines viewers on the model that set off occasion 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 bulk of that view on ways to build enterprise apps.
The simpleness and speed of development that it brings is attractive to frontend Java developers, which to one degree or another currently need to handle HTML, CSS and typically Javascript anyhow.
So an attractive alternative seems to be that a portion of enterprise application code will start being composed in Javascript using Angular rather of Java, but just the next few years will tell. Another possibility is that Angular is made use of internally by frameworks such as JSF as an internal execution mechanism.
