« Auth0 Architecture - Running in Multiple Cloud Providers and Regions | Main | Sponsored Post: Apple, Asana, Hypertable, Sprout Social, Scalyr, FoundationDB, AiScaler, Aerospike, AppDynamics, ManageEngine, Site24x7 »
Wednesday
Nov262014

Make Any Framework Suck Less With These 10 Insightful Lessons

Alexey Migutsky in 2 years with Angular has a lot to say about Angular, which I can't comment on at all, not being an Angular user. But burried in his article are some lessons for building better frameworks that obviously come from deep experience. Frameworks will always suck, but if you follow these lessons will your frameworks suck less? Yes, I think they will.

Here are Alexey's Lessons for framework (and metaframework) developers:

  1. You should have as small as possible number on abstractions.
  2. You should name things consistent with your "thought domain".
  3. Do not mix several responsibilities in your components. Make fine-grained abstractions with well-defined roles.
  4. Always describe the intention for your decisions and tradeoffs in your documentation.
  5. Have a currated and updated reference project/examples.
  6. You abstractions should scale "from bottom up". Start with small items and then fit them to a Composite pattern. Do not start with the question "How do we override it globally?".
  7. Global state is pure evil. It's like darkness in the horror films - you never know what problems you will have when you tread into it...
  8. The dataflow and data changes should be granular and localized to a single component.
  9. Do not make things easy to use, make your components and abstractions simple to understand. People should learn how to do stuff in a new and effective way, do not ADAPT to their comfort zone.
  10. Do not encode all good things you know in the framework.

Reader Comments (2)

Thanks for sharing. There are some interesting points in there!

I do question the first point though that you should have as small as possible number on abstractions. I think the number of abstractions in a framework doesn't matter. It's the amount of coupling between them! Or in other words: the amount of abstractions you need to use simultaneously before getting productive.

This closely related to the third point IMO. Take libraries from Java, .NET, python, etc. Very rich frameworks if you think of it. Lots of abstractions! However (in most cases) the different parts of these frameworks are so loosely coupled that they are 'friendly to the grey matter' :) Layering and the good old 'composition over inheritance' go a long way.

November 27, 2014 | Unregistered CommenterFrens Jan Rumph

+1 my personal favourite is #10 Do not encode all good things you know in the framework. - that's so true.

Yet still some people need to show how "smart" they are and insist on building giant overloaded can-do-it-all frameworks (plugin interface and batteries included) for quite simple tasks. Yes, it is possible to bloat a 10 line algorithm to 300 lines of code, consisting of at least 4 classes and 2 interfaces - while still hardcoding the important parts at various indenpendent places, making it hard to use, hard to maintain and hard to extend.

PostPost a New Comment

Enter your information below to add a new comment.
Author Email (optional):
Author URL (optional):
Post:
 
Some HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <code> <em> <i> <strike> <strong>