puremvc

Neil kinda gave a talk/ walk through of Puremvc on the 20th. I've summarized the key points of the meeting, but also have some concerns about the framework and its uses.

Puremvc is quite a verbose framework, therefore should only be used in contexts which warrant the extra weight. The applications which require its use should be complex large desktop or web applications. An example of its use, shown by Neil was an air (desktop) scheduling application. An example of a web application that I think could benefit from the Puremvc framework would be SumoPaint (an online paint application which mimics Photoshop).

Neil made a point of warning that Puremvc is not suitable for games or 3d applications, because of heavy reliance on the view and its affect on performance. Puremcv adds a lot of bloat and layers to an application which would have a negative impact on a fast paced game, or a heavy rendering process.

It seemed as though most members of the meeting were struggling with some of the abstract concepts during the session. Indeed it was pointed out that there is a high learning curve to using Puremvc. Writing an application in Puremvc isn't something you can simply leap into, since the flow of notifications is difficult to follow. Neil mentioned that this may be a good thing, since its forces him to plan and draw out an architecture before writing any code. However it does create a high barrier to entry for anyone not familiar with the framework.

Neil recommended use of the Muliticore as apposed to the single core for flexibility. Multicore stops some of the core classes being instantiated as singletons; it allows cores to communicate with each other in larger, more complex applications which are ultimatly more flexible.

The documentation for Puremvc is very good, although I found from personal experience one of the fastest ways to gain an understanding of the framework is to study the flow of instanciation and notifications. Since this notification process is considered difficult to follow, its beneficial to study a small sample application and draw out the flow as you guide yourself through the application. I think this gives more of an instantanous reference making the application more transparent as a learner.

Although I can see how a framework such as Puremvc is benificial to developers creating large web applications; I am concerned about its use. Its easy to get wrapped up in creating "beautiful code" but without remembering a framework or design patterns original purpose its easy to end up with something that looks like its visited Jocelyn Wildenstein's plastic surgeon. Websites and small applications don't require the level of abstraction offered by Puremvc; and the reality is bulked out code, which is needlessly complex and probably quite confusing to update and maintain. The end solution becomes a bunch of classes which do not provide obvious answers as to their purpose, responsibilities and relationships.

When all said and done, good code should always be flexible and maintainable which are qualities boasted by Puremvc. Ironically the complexity/ abstract(-ness?) of the system counteracts these qualities by creating a high barrier to its use. Imagine switching your team over to the Puremvc framework for your larger applications, granted once your employees have completed training they will have the skills and tools to create sophisticated flexible applications.

However, now imagine (as with many digital creative agencies) you have a busy period, in the first scenerio you hire freelancers to come in and take some of the heat. In this scenerio you can't pick your usual freelances because they have no knowlege of the framework; if you do the projects are going to take a lot longer as they get up to speed. In the second scenario, you hire some new junior developers, again training takes alot longer but even usual junior tasks such as maintence become complex and daunting. I can imagine that debugging becomes a hugly more complex process as data flow becomes difficult to follow. Having said this I do believe that any training is a worthwhile investment and the knowelege will only benifit the quality of future projects, but my point is that when code becomes difficult to maintain that also means that its inflexible. By my book inflexible unmaintainable code = bad, so choose your weapon wisly.