Skip to content

Instantly share code, notes, and snippets.

@krulik

krulik/gist:11193217

Last active August 29, 2015 14:00
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 1 You must be signed in to fork a gist
  • Save krulik/11193217 to your computer and use it in GitHub Desktop.
Save krulik/11193217 to your computer and use it in GitHub Desktop.
Download ZIP
The Angular vs Dojo email
Raw
gistfile1.md

AngularJS

AngularJS is somewhere in between a framework and a library, and as such it lets us benefit of both worlds:

As a library it:

  • Doesn't require a particular layout of files at development time
  • Is lightweight and small in size (79kb)
  • Works great with other technologies. Add as much or as little of AngularJS to an existing page as we like, and as much or as little of other libraries as well
  • Is modular - every feature can be modified or replaced to suit our unique development workflow and feature needs
  • Has no global state and multiple apps can run on a single page without the use of iframes

And as a framework it:

  • Designed for and gives a full solution for constructing a Web Application, not only an Ajax/DOM tool
  • Has a large set of built-in tools (Routing, Deep Linking, REST, Data Services, Form Validation, Templating, Two Way Data Binding, and more)
  • Provides an “App Lifecycle” that we fit our code into
  • Encouraging and opinionated about best practices and Design Patterns such as MVVM, Dependency Injection and Testing at its Core
  • Provides a way of defining application specific components (widgets) in a clean way
  • Serves as a layer of abstraction on top of other (optional) libraries

It also has some unique and powerful features which make it stand out from other libraries/frameworks:

  • Declarative HTML: makes for declaring dynamic views in a simple and a straightforward way which is easier to develop and maintain
  • Directives: makes for building clean and self contained reusable components
  • Dependency Injection: makes for Stateless Controllers, no main() method, and no parameters to pass back and forth

And all these make for:

  • Less custom code to write and maintain
  • Well structured, architectured, and more robust code
  • Basic concept is easy, even for novices.
  • Scales well on complexity of development, "simple stuff is simple"

It's also important to consider the forces behind and around it:

  • It is powered and Actively Developed by Google
  • Rely on well-tested and engineered code by Google instead of writing our own repetitive glue code.
  • Very active community and high momentum, becoming industry standard for professional Web Development
  • In the near future, HTML-based templating will be native in browsers, so we’ll best prepare ourselves by adopting it now. Google is already working on this with Chromium and standards bodies

Dojo

We've done some work considering using Dojo, and have prepared a POC in order to check the possibility of using a "corporate" "one-solution" framework, hearing a lot of positive things about this project. At the end we've decided to drop this path, because of the following reasons:

  • Size: the full framework is huge, with Dijit (UI framework) its sources are 28MB. Custom build is possible, but than we lose the advantage of using a "one solution" library, the reason why we chose it in the first place
  • Learning curve: it has a steep learning curve, and while the investment might pay off for the long term it also tightly couples the organization with the framework
  • Its separation of concerns is less clear and solid, and DOM manipulations inside of business-logic code is mandatory
  • The solution is not really full, and while having a lot of Widgets and UI components, changes and further development is still necessary, and is very difficult and time consuming compared to more lightweight solutions
  • It doesn't play well with other libraries/frameworks, while those are necessary to construct a complete solution. Also adding other libraries while having such a large framework at our base "hurts", and feels like a bad practice and going against performance considerations
  • Documentation is somewhat lacking, confusing and sometimes is outdated. Perhaps the reasons being a niche adoption and supporting multiple versions

Sources:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment