Angularjs framework

Infrastructure concerns

Every application has various concerns. One classification of these concerns is application infrastructure concerns and business concerns. The business concerns are specific to an application and differ with each one of them. On the other hand infrastructure concerns are somewhat similar and with right parameterization we can reuse them across applications.

Various libraries and frameworks exist in any technology space to help us with the infrastructure concerns. Writing infrastructure code is (when it is solved by someone else already) is stealing from your employer / client (http://codebetter.com/jeremymiller/2008/11/07/how-to-design-your-data-connectivity-strategy/)

A sample list of such infrastructure concerns in a modern JavaScript application

• Routing, Navigation & History
• Template Engines
• Data-binding
• Communicate with the server to read / update the model
• Responsive Web-design
• DOM manipulation
• Asynchronous Programming
• UI Widgets
• Feature detection
• AJAX

Code Organization

Another level of reuse is the reuse at the conceptual level / design level / idea level. Frameworks excel in this form of reuse. Frameworks are opinionated. They enforce or provide some default architecture / structure to your application. Frameworks have inversion of control. That means frameworks may enforce a life-cycle and typically the framework calls your application code and not vice versa.

UI Architectural patterns are all about Separation of Concerns and having more maintainable code – Divide and Conquer. Frameworks may typically follow (an) UI Architectural pattern(s)

Let us now see how angularjs helps in Code Organization and Infrastructure concerns

What is AngularJS?

I will use and elaborate a slightly modified version of  Amit’s answer to What is AngularJS? When is it needed? on Quora http://www.quora.com/What-is-AngularJS-When-is-it-needed/answer/Amit-Asthana

AngularJS is a JavaScript MVW (Model View Whatever – A term from http://coding.smashingmagazine.com/2012/07/27/journey-through-the-javascript-mvc-jungle/) framework developed by Google that lets you build well structured, easily testable, declarative and maintainable front-end applications which provides solutions to standard infrastructure concerns.

Let us see each one of these

Structure

Angularjs code you write typically falls into one of these buckets

Services –

If you are talking to the outside world, this is a perfect use case for a service – from (http://nathanleclaire.com/blog/2014/03/15/angularjs-isnt-mvc-its-sdc/)

Directives –

Directives are a declarative (Some call this functional, but i believe this is declarative) way of manipulating / working with the DOM. The Web standards too are polarizing in this direction – Example: Web Components. Directives are one of the key aspects of angular (often misunderstood and under used)

Directives are either completely new HTML elements, or attributes that you can throw on existing elements, to perform some kind of DOM manipulation. They can have their own scope and they can be reused, which is one of their most useful properties. – from http://nathanleclaire.com/blog/2014/03/15/angularjs-isnt-mvc-its-sdc/

Views –

The html templates written using angularjs directives and standard html elements

Model –

Angular lets you write non intrusive POJO model objects. Angularjs implements its own dirty checking http://stackoverflow.com/questions/9682092/databinding-in-angularjs/9693933#9693933 which means you can write your models as POJO objects, but it does come with a performance hit.

Controllers –

“glue” of your application. Controllers use model (methods and data) provided by the services and provide them to the directives. – adapted from http://nathanleclaire.com/blog/2014/03/15/angularjs-isnt-mvc-its-sdc/

Testable

Angularjs is designed for ease of unit testing. It is made easier by

• Dependency Injection
• Standard Mock Service Providers

The whole of Angular is linked together by Dependency Injection (DI). It’s what it uses to manage your controllers and scopes. Because all your controllers depend on DI to pass it information, Angular’s unit tests are able to usurp DI to perform unit testing by injecting mock data into your controller and measuring the output and behavior. In fact, Angular already has a mock HTTP provider to inject fake server responses into controllers. – from http://www.sitepoint.com/10-reasons-use-angularjs/

Declarative

See the discussion on directives above.

Infrastructure Concerns

In addition to these angular provides solutions to these infrastructure concerns

• Template Engine – Angular provides a DOM based template engine.
• Data-binding – Bidirectional reactive data-binding
• Routing
• A context aware pub-sub system
• GUI widgets

It will be interesting to see Polymer custom elements and angularjs directives against each other.

References:

http://martinfowler.com/eaaDev/uiArchs.html

http://www.quora.com/What-is-AngularJS-When-is-it-needed/answer/Amit-Asthana

http://nathanleclaire.com/blog/2014/03/15/angularjs-isnt-mvc-its-sdc/

http://www.sitepoint.com/10-reasons-use-angularjs/

http://stackoverflow.com/questions/9682092/databinding-in-angularjs/9693933#9693933

The importance of learning JavaScript

This post is part of a series of posts on Client-Side Web Application Development using JavaScript.

Available on every device

It is time that we start taking JavaScript seriously. Well may it is already late . JavaScript is virtually present on a wide range of devices from your smartphone’s mobile browser to your tablet’s browser to your desktop PC’s browser.

JavaScript is not just about User Interface validations / enabling – disabling alone anymore

Given the speed of the modern JavaScript engines in the browser, it is today possible to share some of the server load with the capable clients. The server needs to cater to a number of clients, whereas the client has all the processing prowess available to itself. If we do everything on the server, the server will soon become a bottleneck. Instead why not make use of the processing prowess on the client machines when feasible. Ironically, in some of the cases your client desktop may be more powerful than the virtual machine serving the web site / web application.

This thought process of leveraging the

• Efficient JavaScript implementations on the modern browsers
• Unshared processing prowess available to the client (as opposed to it being shared in the server for serving each client’s request)

has lead to people offloading a lot of tasks that a traditional web server used to perform to the clients. These include but not limited to

• View Template Selection or Routing
• Template Rendering using template engines
• Entire MV* implementations running inside the browser instead of your traditional web server frameworks like Rails, Django / ASP.NET MVC.

Breaking out of the browser

JavaScript is not just limited to the browser, in the recent (well not so recent past) JavaScript has broken out of the browser. It is now possible to create with JavaScript (,HTML5 and CSS)

• Desktop apps
  • Chrome Packaged Apps
  • Windows 8 Metro Store Apps
• Hybrid apps on the mobile devices (Smartphone / Tablet)
  • Using UIWebView on iOS
  • Using WebView on Android
  • Using a cross-platform toolkit like Appcelerator’s Titanium

JavaScript is not just about User Interface anymore

Native OS API access

JavaScript is also not limited to User Interface anymore. Chrome packaged apps for example enable OS level integration to accomplish low level tasks like Serial port access, Socket programming etc.

Look at this talk from Google I/O conference 2012 edition, The Next Evolution of Chrome Apps. The Google Chrome Apps team demonstrates controlling an cardboard chrome icon connected to a stepper motor via an Arduino board from JavaScript. For the impatient, here is a direct link to the demo location in the video.

Google in fact looks serious about this as they have started working towards making this a standard. The System Applications Working Group will work towards standardizing a

“runtime environment, security model, and associated APIs for building Web applications with comparable capabilities to native applications.”

On the Web / App Server

Needless to say much here since the node.js community has gained a lot of traction. The following factors have lead to the rise of JavaScript usage on the server-side.

• Availability of faster JavaScript execution engines (Google’s V8 especially)
• Code reuse between browser and server implementations
  • Model
  • Validation
  • Routes
  • Template Engine & Templates
  • Persistence (offline on client-side and master database on server-side)
• JavaScript Object Notation (JSON) as our default serialization everywhere.
• We need to learn one language.

On the database server

Some of the NO-SQL / Not Only SQL databases use JavaScript Object Notation (JSON) or variants of JSON as the format to expose from the API / Storage format. Some of them support writing Map Reduce jobs using a JavaScript based Domain-Specific Language.

Automation Scripting

You can use JavaScript today an automation scripting language for shell scripting or build scripts etc.

Summary

To conclude “The JavaScript God is Omnipresent” and the time is now ripe to learn JavaScript and the innumerable frameworks / libraries written by the JavaScript community. In a recent “TechDays the Netherlands 2012” presentation HTML5 QuickStart Jeff Prosise used this quote

There are two kinds of developers: those who know HTML5, and those who will be learning HTML5.

I will say that applies to JavaScript as well.

There are two kinds of developers: those who know JavaScript and those who will be learning JavaScript

James Governor tweeted this

It used to be that learning JavaScript meant you weren’t a serious software developer. Today the opposite is true.

So learn JavaScript.

Mobile: Cross-Platform toolkits

Yesterday I attended an event from Thoughtworks – Thoughtworks Technology Radar. Thoughtworks Technology Radar has positioned Cross-Platform toolkits for mobile development in the ‘Hold: Proceed with caution’ ring. Around an year ago Martin Fowler wrote about Cross-Platform toolkits for mobile development here.

Fowler’s conclusions in his bliki entry 

 

• Don’t use cross-platform toolkits
• For maximum reach: built a web app that looks like web app
• To appeal to a particular platform: build a native app for that platform, with a experience design based on that platforms interaction style

In the footnote he highlighted a scenario where using a cross-platform toolkit may be valid –

Use a cross-platform toolkit – but you write a different app, with a different experience design, for each platform you build for. The gain over doing this with native code is that you have a single platform for your developers to use and can get some reuse of common code (particularly non-UI code)

I recently read a comprehensive study of Cross-Platform Developer Tools 2012 – Bridging the worlds of mobile apps and the web (VisionMobile The Clash of Ecosystems report). This what they had to say:

The outlook for cross-platform tools

• Cross-platform tools will evolve from productivity tools for developers to strategic assets in the battle of ecosystems
• As the platform landscape remains fragmented for the foreseeable future, cross-platform tools will become “business as usual” for most mobile developers
• Cross-platform tools vendors will differentiate by reaching across the app lifecycle
• Specialisation and segmentation in cross-platform tools

1. Games
2. enterprise
3. media apps

• Cross-platform tools will be complementary to native SDKs, providing effective solutions for developers making less demanding apps that can perform well while not having access to bleeding edge features
• Cross-platform tools are taking HTML further than web browsers can, by unifying the authoring side, rather than the runtime side of the app
• Component marketplaces becoming an essential feature of successful cross-platform tools
• Cross-platform tools allow developers to reach platforms they otherwise could not. CPTs lower entry barriers, for example allowing web developers to create native smartphone apps using only HTML and JavaScript. They can provide easy-to-use languages and development tools, and facilitate modular development and software component reuse. The result could be termed a “democratization” of software development
• The next frontier for cross-platform tools – and the next major point of vendor differentiation – will be catering to multiple screens

 

I am towards VisionMobile report’s outlook and the footnote from Fowler. Interesting to wait and watch who will be right here.

Framework development

Having worked with Framework development and implementation for the last 6 years, here are some of my personal thoughts on framework development.

• It works best when frameworks are grown out of existing applications and not built from the scratch to implement a new application.
• Framework teams are hard to build & maintain, starting with recruitment.
• Frameworks suffer the Not Invented Here syndrome, since developers always feel that “I could have written a better framework”.
• Framework teams are best managed by a Development Manager who is more involved in technology than the regular Project Manager.
• It is really hard to support rookies in a Framework development team.
• Quite often Frameworks are a smell that the Business Stakeholders are not in charge, Someone from the Development Team is doing the backseat driving.
• Most of the Small and Medium development houses cannot afford the cost of developing a framework. A corollary to that is when a Small or Medium development house takes up such an effort the project is usually a Death March.
• When you are leading one such effort you need to be in the best of your health and super charged, because these kind of development projects drain you fast.

Happy Framework development.

Cheers,

Sendhil

Frameworks & Complexity – A quote from a lambda-the-ultimate discussion

All frameworks have crazy dependencies, if you don’t agree with me, name one that doesn’t! Crazy dependencies result from chunky abstractions, and you can’t avoid them unless you instead design a bunch of small generic orthogonal abstractions. But in the latter case, you have something more like a language than a framework.

Everyone (including competing product groups) seems to believe that their own chunky abstractions are better than someone else’s. This is BS, you just wind up replacing something you aren’t familiar with with something that you are familiar with because you wrote it yourself, which makes a different set of trade offs that caters specifically to your needs. There are of course better designs, but the intrinsic complexity remains no matter how good the design is. (Emphasis mine)

From a lambda-the-ultimate post by Sean McDirmid. http://lambda-the-ultimate.org/node/3720