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/)
- Routing, Navigation & History
- Template Engines
- Communicate with the server to read / update the model
- Responsive Web-design
- DOM manipulation
- Asynchronous Programming
- UI Widgets
- Feature detection
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
Let us see each one of these
Angularjs code you write typically falls into one of these buckets
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 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/
The html templates written using angularjs directives and standard html elements
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.
“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/
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/
See the discussion on directives above.
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
- A context aware pub-sub system
- GUI widgets
- It will be interesting to see Polymer custom elements and angularjs directives against each other.
Available on every device
This thought process of leveraging the
- 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
- Desktop apps
- Hybrid apps on the mobile devices (Smartphone / Tablet)
Native OS API access
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
- Code reuse between browser and server implementations
- Template Engine & Templates
- Persistence (offline on client-side and master database on server-side)
- We need to learn one language.
On the database server
There are two kinds of developers: those who know HTML5, and those who will be learning HTML5.
James Governor tweeted this
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
- 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
- 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.
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.
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