Evolution of the Third Platform

Evolution of the Third Platform

The development of mainframe computing in the 1950s came to be known as the First Platform. Its development revolved around the needs of the enterprise, with very little focus on the specialized needs of end-users.

Driven by the promise of lower cost of ownership and simplified deployment and use, the Second Platform emerged in the 1980s with a marked focus on developing Personal Computer (PC) technologies. Continuing evolution is causing a significant paradigm shift toward meeting the needs of end user in the IT landscape.

Today, the trend toward improving end-user experiences and IT efficiency has led to the development of the Third Platform. First identified and described by International Data Corporation (IDC) in 2007, the Third Platform is defined by the following four pillars:

  1. Support for a plethora of mobile devices
  2. Social networking
  3. Cloud computing
  4. Big Data and associated analytics, such as Search Engine Optimization (SEO)

The consumer with limited IT expertise is driving the evolution of the Third Platform and growing demand for simplified, automated solutions. For example, the ability to manage cloud computing solutions using terms they understand without requiring intervention by highly trained IT professionals. Until now, simplified solutions to meet these needs have not been available.

However when combining a responsive UX technology stack with machine-assisted learning & search engine technologies, it is possible for the IT professional to state a management goal in natural language, and the system will respond seamlessly with options that optimize performance and/or capacity.

This solution is ideally suited to address the needs of the consumer as well.  As hardware and software firms adjust their business models to align more closely with the needs and demands of consumers before those of the enterprise, the blending of responsive UX technologies with artificial intelligence is enabling Goal Oriented UX experiences.

AngularJS Directive Template vs TemplateUrl (synchronous vs asynchronous)

As one would hope the output of the template  and templateUrl is the same, its just that one has to be careful about when the controllers and link function are available.  Run this example JSFiddle and see.

template -synchronous lifecycle: Angular uses a depth first approach for DOM compilation and the compiler instantiates the each controller until the DOM is traversed. Then the link function of deepest directive is instantiated and angular traverses the DOM in reverse order instantiating each link function.

templateUrl -asynchronous lifecycle: Angular uses a depth first approach for DOM compilation and the compiler instantiates the first controller but then assumes an asynchronous response from the templateUrl and immediately instantiates the first directive’s Link function. The DOM is traversed where the compiler instantiates each directive’s controller and than it’s link function.
The example shown in JSFiddle  defines three directives using template option.  Each template loads in another directive. The output shows the order the compiler instantiates the controllers from the parent to the child  in a descending order and then instantiates the Link functions from the youngest child back to the parent.

Directive A Controller
Directive B Controller
Directive C Controller
Directive C LinkFn
Directive B LinkFn
Directive A LinkFn

The code then defines three directives using the templateUrl option to load the directives.  The output shows where each directive’s controller and link function are instantiated which is only in descending order.

Directive A URL Controller
Directive A URL LinkFn
Directive B URL Controller
Directive B URL LinkFn
Directive C URL Controller
Directive C URL LinkFn

Final thoughts

Angular best practices recommends using templateUrl and since angular will store the html in templateCache it makes sense to preload the html using something like grunt JavaScrip / HTML2JS. The design of the directives should assume:

  • Expect child directives to be complied at some unknown point in the future
  • When the template does arrive understand the scope could be very different
  • Do not assume variable bindings exist in the DOM at the time the controller or link Fn are executed.

If the templates are preloaded, all the child directive’s will be available by the end of the digest cycle.