Thoughts on framing.io

I just participated on the panel for an ngHouston online user group meeting, where Ryan Campbell of BizNas / framing.io presented the Framing framework for complex enterprise Angular applications. You can watch a replay here:

Here is a quick analysis, pros and cons of Framing and its approach. Keep in mind as I write this: Framing has just recently been released and is at the very beginning of working to build a user community.

Pros

Ryan pointed out that, at a certain scale, enterprise teams tend to eventually build something in the general direction that Framing has gone… And he is completely right. Angular’s built-in abstraction for building aggregate of more than one component, NgModule, is still relatively low level, and provides just some low-level structure. It does not provide a pattern to follow around how an application feature could be structured, or other patterns. Teams building large sprawling systems tend to want a more structured way to follow consistent patterns across highly numerous features. Framing provides such a pattern and tooling.

In our work teaching and consulting on Angular, we have met groups who have built things generally like this under AngularJS 1.x, though I don’t think I’ve seen anything similar published for 1.x. Framing is the first thing of its general nature I have seen published for Angular 2+. Actually getting something published is always impressive and worthy of appreciation, there are probably dozens of other somewhat similar libraries/frameworks scattered around the industry, hidden behind firewalls.

Framing appears to have avoided many of the obvious ways that a framework like this could go wrong. There are numerous plug points and overrides available. An application can pick up a feature, and override display strings, data, components use inside the feature, chunks of code used inside the future, and so on. An application can do this without “forking” or copying all of the unchanged code in the future.

Although at first glance it seems like Framing might override the Angular way of doing some things, with a deeper look it seems instead that it provides an additional higher-level, more abstract API for building Angular applications at scale. This API is oriented toward composability and reusability, and a coarse-grained way that the core Angular obstructions are not.

Cons

There are risks, of course. The obvious ones include:

• Framing might turn out to be 80% good enough but not 100% good enough, and that might be discovered after having built mountains of code.
• Framing might turn out to be great for a while and then get abandoned, making it to Angular 6 but not Angular 7 for example.
• Framing might turn out to be completely against the grain of some future change in Angular, such that it really can’t be updated but rather must be re-architected completely.
• … and more.

Ryan mentioned that there is a path by which they believe they can make Framing fully AOT compatible, but I’m skeptical of this until I see it running. AOT relies on static analysis of the module structure, it’s not perfectly clear that it is possible to perform static analysis of something built this way. (This reliance on static analysis is perhaps the greatest strength and greatest weakness of Angular!)

Framing comes with its own dataflow/reactivity library and approach. This approach might be ingenious, but it is undeniably much less popular and proven than the Redux-flavored design offered by ngrx/store, which seems to be well on the way to “de facto standard” for complex Angular applications.

Learning Angular, learning the many of libraries people typically use with Angular, teaching those things to others, is already a really big challenge. Another additional abstraction like Framing on top, adds to a tall stack of things that have to be learned and taught. This challenge of teaching and learning so much to so many, is already one of the bigger concerns for large organizations (the kind of folks who would benefit from something like Framing) adopting Angular. (Marketing plug: at work at Oasis Digital, we help with the sort of thing, and we teach Angular at Angular Boot Camp.)

Conclusion

Framing is definitely worth a look, and I will follow its ongoing development. I recommend others responsible for sprawling applications do so also.