Farewell, Flex Layout

tl;dr Angular Flex Layout is entering LTS for the next year (at least), after which it will no longer be supported. If you have a complicated migration, you can request a migration guide for your use case on the GitHub repo.

In the summer of 2016, I was brand new to Angular. No, not the Angular of today. AngularJS, the progenitor. Angular as we know it now was in its infancy, with Angular Material (now Components) still in those quirky “named” beta releases. It was then that I was tasked with a simple project: build a basic webapp for my company, one capable of displaying data and performing some basic API operations for an API without a UI. Easy, right? The engineer next to me that summer had a similar project, and we established a kinship of sorts working long hours wrangling with JavaScript just to make something work. The difference was, he went with BackboneJS, and I, through team convention, was using AngularJS.

This was the height of AngularJS’ popularity and relevance; docs were aplenty, libraries were well-supported, and everything was clicking. Things on the BackboneJS side were not as glamorous, and very quickly the kinship turned to envy. One of the best libraries of AngularJS was AngularJS Material, pioneered by Thomas Burleson. AngularJS Material was powerful, feature-rich, and customer-focused. It had powerful utilities for everything you could need to build a successful web app, including, as luck might have, a powerful, expressive layout engine. With just a few lines of HTML code, you could have a fully responsive webapp, fit to your exact specifications (within the Material set of breakpoints of course). To a new-to-AngularJS and almost new-to-modern web development engineer, this was a godsend.

That summer quickly ended, and as the color of the leaves changed, so too did the prevailing winds of framework development. Angular was on the rise, leaving AngularJS in its wake. Building the new Material Design library for Angular was Jeremy Elbourn, who is now the technical lead for Angular. Wanting to keep the intention of the library small and focused to start, the powerful, expressive layout engine of AngularJS Material was not brought over to the new library. Instead, Thomas broke out the library into its own separate unit, deemed Angular Flex Layout. Possibly more powerful than its prior iteration, this library had several key benefits:

• Same great declarative HTML interface for new developers to hit the ground running
• Powerful service utilities to listen to breakpoint changes
• Compatibility with all browsers and their various quirks

It’s easy to forget now, but at the time Flex Layout first came out in 2016, the browser landscape, especially around relatively “new” features like CSS Flexbox, was wild and untamed. Flex Layout papered over these issues and hid them from users, allowing them to get on with whatever work they needed to complete, unencumbered.

Enter the fall of 2017. After getting my feet with Angular, and porting my application (including the layout functionality), I started entering the server-side rendering (SSR) space more aggressively. I wanted my application to be as performant as possible. The only problem? Flex Layout didn’t have a great SSR story. And so, for the first time, I crossed the line of demarcation between consumer and collaborator. I reached out to Thomas and pitched him on an idea for implementing true SSR for Flex Layout, and he jumped at the opportunity to work together. He immediately invited me into the discussion groups, established an active dialog, and shared his intentions for the library as a whole. We built and launched SSR after a lengthy design, and we hit the ground running together from there. We fixed bugs, added docs, improved performance, cut down bundle size. We did everything short of a complete refactor of the library.

Throughout all of this, Flex Layout stayed in beta. First, we paralleled Angular Material in their beta state, but soon enough Material exited beta while we were stuck in neutral. The sentiment from some of the Angular team was that Angular’s scope is growing and the layout layer belongs to the web platform rather than a first-party library. The perception was that it introduced unneeded JavaScript bloat and latency, though those claims are disputed. Due to increasing scope and an evolving ecosystem, a path for Flex Layout to exit beta within the Angular GitHub organization did not exist.

We worked hard on behalf of our customers to add increasingly desired features, specifically around CSS Grid, and print-mode layout rendering. Thomas eventually moved on from Angular to explore other spaces, entrusting the project largely to me. As steward for Angular Flex Layout, I kept up with every release of Angular, dealing with the inevitable and often immediate “when will this library support Angular X” comments; feedback that often would see 20 +1s. With the help of Paul Gschwendtner and Alan Agius, we restructured the library to be more maintainable. And with the continued support of the Angular team (and specifically the folks on the components side), we were able to regularly cut releases with fixes, updates, etc.

Unfortunately, the time has come where this arrangement is no longer sustainable and the Angular team has decided to cease support of Angular Flex Layout. The plan is for the library to enter Long-term support (LTS) for the next year at least, at which time new versions will no longer be published.

It has been an incredibly rewarding and humbling experience to be a steward of this project for the past several years, and to our avid and active developer community, I want to express my sincerest thanks for your support and engagement over that time. I also want to thank the Angular team for their support of the library over the past few years. They gave me the option to continue maintaining the library under a forked namespace, but unfortunately I too do not have the bandwidth to maintain the library as an official release.

So, for the Flex Layout customers still reading this and wondering, “so what do I do now??”

Flex Layout is massively complex and feature-rich, and there is simply no 1:1 product quite like it available today. There are several excellent products that have come out since Flex Layout’s inception, like Tailwind, but automating a migration from one library to another simply isn’t tenable.

You can also “go it alone” by moving to native CSS Flexbox and CSS Grid functionality, depending on the browser versions you are targeting. There will be a separate blog post by the Angular team that will help you explore these options.

For those with more complex use cases, we will be opening up an RFP on the Flex Layout GitHub repo asking for migration use cases. For those that are popular or highly complex to migrate, we will author some migration guides to help you make the transition. I know this isn’t as seamless as an Angular schematic might be, but is the best that we can feasibly do.

To those disappointed at this announcement, simply know that I share your disappointment, and that I fought this off as long as possible. Unfortunately, the old adage is true, all good things do come to an end. Thank you as always, and hope to see you out there, somewhere.