Warning: Illegal string offset 'filter' in /var/sites/t/theproactiveprogrammer.com/public_html/wp-includes/taxonomy.php on line 1409
Why do we want to use a framework?
I am currently setting up a new pet project, and fell into the trap of thinking too early about which framework I wanted to use. The project is quite graphical in its nature, using Raphael.js to generate SVG shapes which the user can interact with. My initial choice was Angular, partly because I am more experienced with it than the others and I would like to gain more experience still.
However, I noticed the following statement on the AngularJS website:
Games and GUI editors are examples of applications with intensive and tricky DOM manipulation. These kinds of apps are different from CRUD apps, and as a result are probably not a good fit for Angular. In these cases it may be better to use a library with a lower level of abstraction, such as
I’m not building a GUI editor, but my application will be far more graphical than your typical CRUD app. I’m going to be using Raphael statements to draw shapes, so how would this fit into the AngularJS architecture?
A few google searches later, I found that this problem had unsurprisingly been encountered many times before. The common approach it would seem is to create Angular directives which encapsulate Raphael elements. This seems fair enough on first glance.
As far as I can tell, the main benefits of creating custom directives in Angular are readability (html) and reusability, and also possibly testability. So, let’s look at these in turn.
Regarding readability, would using an Angular directive for my Raphael canvas make for more readable HTML?
As all of my Raphael elements would exist inside a single div representing the canvas, using directives I would probably end up with something like this:
…rather than this:
How about reusability? I know there will only be one canvas in my application, therefore no advantage here either.
So my solution?
I will use AngularJS in some parts of my application, but not in others.
This may not be a common approach, but in my case I think it makes sense. My point here is essentially that we need to treat each project according to its specific requirements, and avoid trying to grok our solution into a specific framework, and the same can be said of most fads in software development. Recognise the benefits and drawbacks, identify the key requirements of your application, and use your intelligence and creativity to select the best approach.