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.

 

Angular component library AOT

Angular component libraries don’t ship with AOT “ngfactory” output. Why not?

Angular 2-and-up (I’m working with the version 4 release candidate at the moment) is a relatively large and complex single page app framework/library, but unlike some of its smaller competitors it has a key feature to mitigate this and provide a performance boost in deployment.

The feature is “ahead of time compilation”. With AOT, HTML templates used by an application are parsed/compiled during the build process, rather than when they are used in the running application on a web page. This compilation converts the textual templates to TypeScript classes, which are then bundled along with human-written application code. As a result, with AOT large portions of the Angular framework can be excluded from the deployed application.

AOT is typically performed with a command line program “ngc”, in an application build process.

But what about libraries of pre-built Angular components? Should a component library (which might be published as a NPM package, or by some other means) include this AOT output, which takes the form of “*.ngfactory.ts” files?

No – Angular itself does not work this way and build tooling does not support or encourage such a thing. If it did encourage bundling the AOT output libraries:

  • Libraries would not benefit from further improvements to AOT, without also releasing out a new version of the package.
  • AOT would need to generate code which works across version skew, in order to respect semver. this would be a frequent and problematic restriction.

The actual implementation of AOT expects AOT to be performed always at a project level and never at a library level (although the letter is not exactly true; you may use the AOT tool in the library to produce “metadata” files).  With this design, you can consume a library written (for example) with Angular 2.3.3, even if your project is using Angular 2.4.5 (somewhat different AOT output) or Angular 4.x (very different AOT output).

 

Pug (formerly Jade), in the browser?

 

Over at Oasis Digital Angular Boot Camp, we teach Angular 2+ using tooling that operates entirely in the browser. It compiles TypeScript to JavaScript, it processes a module system, etc. This works very well, and makes for a fast, easy setup and edit/run cycle during class. Great stuff. (We also teach the use of heavier duty server-side tooling like Angular CLI; but CLI is still short of the convenience in-browser tooling.)

I recently wondered whether might be possible to support some of the other tools we use, in the browser. Many useful tools in the JavaScript development ecosystem (including Babel, TypeScript, and many others) are implemented such that they can execute in either a browser environment or in a server (node) environment. This appears to not be a great technical challenge, for projects intended to work this way. The aspects which require node APIs (such as talking to the file system) are simply implemented and wired up separately from the core functionality – which is “just JavaScript”.

Unfortunately, this plan didn’t get very far: the tool I wanted to add next is Pug (formally known as Jade). Pug is currently implemented using Node APIs scattered throughout the code base, rather than in a universal node/browser way. I noticed an open issue asking about this, but it appears there is not interest in achieving such a thing.

Browsing around the Pug code base, it appears would be a moderate amount of work to reshape things to make this possible; but it would involve small changes widely scattered around the code. That kind of change is generally frowned on the project unless there user and developer eagerness for the feature in question. Therefore, I am curious, readers of my blog: is there much interest out there, enough for someone to consider maintaining a fork of Pug converted to universal JavaScript? Or a wrapper/shim around it, to stub Node APIs sufficiently for Pug to operate in the browser?

Managing a To Do list

There are thousands of to do lists applications to choose from, across most every kind of programmable device we’re surrounded with. I have a to do list, but I don’t use any of the apps. A few years ago someone noticed how I did this and asked me to write a few words about it. Whoever it was… I have forgotten, sorry to take so long.

I manage my list using a spreadsheet. Yes, an old-fashioned, dawn of the PC era spreadsheet. The killer app from before that term existed. Why?

  1. A spreadsheet is an amazing general purpose tool.
  2. It has the columns of data I wanted to have right now. I want a new column? Click click and I have it. It doesn’t matter if someone who wrote the to do app thought I needed that column.
  3. Some old column of data no longer useful? Click click, it’s gone.
  4. Finding or sorting data? Yes, in arbitrary ways, right now.
  5. Fonts too large or too small? I don’t go shopping for a new application from someone with a better sense of design. Click, the font is whatever size I prefer.
  6. Sometimes color coding or bold seems like a good idea… and it can be done instantly. Or removed – without shopping for a different application or trying to persuade an author of an application is a good idea.
  7. Sometimes I want to access my list from my phone or tablet. Therefore, I use a cloud spreadsheet application – and have access to the list anytime, without yet another app.
  8. Print? Sure, everyone once in a while.

I think this is a good general pattern: pick out an app for a special purpose only when there are aspects of the behavior of such an application that are not easily met with the general application. But by default, it’s your data, keep it in one of the many applications that already deals with your data in a generalized, flexible, proven way.

At the technical level, my to do list is very well managed. But what about at the logical level, what about really managing my to do list? That’s for another post.

 

Really Managing a To Do list

Earlier, I wrote about managing a to do list, recommending a boring general purpose tool (a spreadsheet) for the purpose. But what about managing the contents of the list, not just the bits? Here are some ideas that have proven useful.

  1. If you are responsible for more items than you can easily remember, have a to do list. Ignore the advice out there to discard your list.
  2. If you’re young and don’t have a list yet, consider that having one might be a necessary step to taking on more responsibilities over time.
  3. Ideally, have one list. However, if your work involves sensitive information that can’t be mentioned (even tersely) on a personal device, have two lists. Keep your work and home lists, on your separate work and home devices.
  4. Record each new thing to do, on the one list (or the one of two lists). Don’t let other extra lists build up elsewhere. No post-it notes, no 294 inbox emails each of which is a todo, etc.
  5. Prioritize the top N items on the list each day. N might be more or less depending on the size of your items.
  6. Compare/reconcile the top of your todo list, with your calendar, briefly each day.
  7. Keep a close eye on urgent vs important while prioritizing. Research Eisenhower or re-read Covey if you forget.
  8. Each week, review: prioritize further down the list.
  9. During a review, notice items that aren’t likely to ever be of enough priority to do at all, and delete them.
  10. During a review, notice items that should be on someone else’s list instead, and delegate them there.
  11. During a review, notice items that are better not to do at all, and make a “not to do” list if necessary.
  12. Beware the arrival of new TODOs that endlessly push the old ones down the list. New items that aren’t of enough priority to do relative to what’s on the list, are better of discarded.
  13. Don’t prioritize and review too often – organization good, procrastination bad.