Late last year I blogged about the future of ngOfficeUIFabric, a project I kicked off and managed for a few years. This project took the Office UI Fabric Core CSS components and implemented native AngularJS directives for AngularJS v1.6.x for use in projects. I was just a small part of this project as the bulk of the coding came from some awesome and talented developers who gave their free time to contribute to the project… I have nothing but profound respect for these developers!
I’m proud of what we accomplished with this project… we had multiple releases, got the library hosted on a public CDN and can rest assured that it’s battle tested with hundreds of unit tests covering over 98% of the codebase. The ngofficeUIFabric project was never intended to work with Angular (v2+), it was only built for AngularJS v1.6.x. To move to Angular (v2+), the project would need to undergo a major refactoring, one so big it made more sense to start over and leverage old code where possible, but under a totally new structure. With [AngularJS v1.x moving to the LTS status](https://docs.angularjs.org/misc/version-support-status), last week I decided it was time to mark the ngOfficeUIFabric as read only and accept no more changes:
End of an era… #ngofficeuifabric, @OfficeUIFabric for AngularJS (1.6.x) is now archived & in read only mode. We’ll see if someone steps up to do a @Angular 6 port of Fabric maybe using #AngularElements … #HatTip to all in community to were involved! https://t.co/V6NuZuAa9H
What does this mean? Everything still works as is; nothing will stop working… there are just no more updates being made to the library. We pushed an update to make it support AngularJS 1.6.10, but we stopped there. ## Looking Forward So… what’s next for the ngOfficeUIFabric with Angular? When I wrote that post I referenced above, I was a bit overly ambitious about the future of the project and my involvement. We were learning about [Angular Elements](/blog/solve-the-sharepoint-framework-angular-challenge-with-angular-5-0-elements) and how they will make writing web components so much easier. However, after a lot of thought, it’s too much for me to tackle a second time around. I have a tendency to over-commit myself and then work too hard to meet those commitments. This time I’m going to be the responsible person and step back… if someone wants to run with it, I’m more than happy to help them set up the project and understand how we did our CI/CD process (which [I’ve written about previously](/blog/ngofficeuifabric-how-we-do-it-continuous-delivery-automate-all-the-things)). ## Does Anyone Outside of Office Care about Office UI Fabric? However, with that being said, I’m not convinced this is something the greater community really wants or cares about. I question the interest of the community… why? First of all, when you look at the UX design landscape out there, you see Bootstrap, Material Design, and Office UI Fabric. But **if you look closely, you see no one outside of the Office division really cares about the Office UI Fabric**. No third parties are creating Office UI Fabric themes, component libraries or what not. They only pay attention to Bootstrap and Material Design. Second, the **Microsoft UX design language framework isn’t clear** to me. You’ve got the Office group pushing Office UI Fabric, but Microsoft as a whole focused on the [Fluent Design System](https://fluent.microsoft.com/)… which seems to have some similarities to Office UI Fabric, but we don’t see any integration with it. Not only that, but since it was announced at the Build 2017 conference, we haven’t seen much follow through into the Office group. Third, from my vantage point, **I see a lot of developers gravitating to React when building Office or SharePoint solutions… even those who, like me, were traditionally Angular developers**. I’ll write more about this in another post, but I’ve been watching a trend where SharePoint developers who used Angular are moving to React simply because it’s the path of least resistance: Microsoft provides their reusable controls implemented in React… so let them do the work of maintaining and we can just leverage it. The fourth point was simply an observation from the SharePoint Conference this past May. There was one session on Angular Elements for use in the SharePoint Framework and another on using React. Both sessions were in the same room, but **the Angular session had roughly 20% the attendance as the React one**… *and that’s with an Angular session that was highly anticipated*. Granted, that’s a single example and a very small data point, but it was one I can’t shake from being in the room for both sessions. This observation & feeling is drove me to tweet this:
As much as I like Angular, I think my preference is switching to @reactjs esp; for #SPFx work simple because it’s the path to least resistance #submission #tiredOfSwimmingUpstream #pragmaticprogrammer
Anyway… back to the point of this post… ngOfficeUIFabric for AngularJS v1.6.10 is now in an archive / read-only state. At this point, there’s no story going forward for an Angular 6+ component library, or web component library (*which would make more sense*), that implements the Office UI Fabric.