Many developers picking up the SharePoint Framework are coming from a traditional SharePoint development background. Some of these people server-side developers primarily who may have some client-side development experience while others may have been customizing SharePoint using client-side development techniques for a while.
One common thing I do see in my experience is that many developers picking up the SharePoint Framework is that they have little to no experience with one of the modern web frameworks that make building client-side web applications a better experience. They see the value in them, but they aren’t sure which one to go with as there are a few very good options such as Angular, React and Vue.
This past week at the SPFest Chicago conference I had multiple people come up to me and ask a version of the following question that I recently received from one of the students of my Mastering the SharePoint Framework course:
If we are coming at this with little or no Angular background does it make sense to go headlong into React and pay little attention to Angular?
A blog post is a perfect spot for me to share my thoughts on this so here we go.
I don’t think it is a good idea to pick a web framework based on what someone else says or without evaluating all the landscape. Choosing anything without looking at your options is never a good idea because maybe one is more or less suited to you and your organization.
Personally, I have a long history with Angular going back many years. I’m still a fan and prefer it as my web framework when building client-side applications.
But that’s just me… I default to Angular because that’s what I’m comfortable with from past experience. If you are coming at this from a fresh perspective, you have an advantage over someone in my position as you have no bias to any one framework.
I suggest you run through a tutorial and build sample application in each of the three popular web frameworks. See which feels the most comfortable, which is the easiest for you to understand. Then look at the advantages and disadvantages of each one.
The Vue site has a pretty good unopinionated comparison of the different web framework options. I suggest you check that out as well.
So what options do you have? Allow me to filter it down to a few options and propose the questions you should ask yourself as well as share my opinionated advantages & disadvantages of each.
At the present time, we have a lot of different web framework options available to us. Those who’ve created a project using the SharePoint Framework Yeoman generator are aware of two options: Knockout & React.
The term web framework typically refers to a library that provides functionality that renders and manages the HTML via the DOM for you instead of you directly manipulating the HTML via the DOM.
jQuery, a popular library, is the latter; it is used to manipulate HTML using the browser DOM. While jQuery can be used in SharePoint Framework projects, it isn’t a web framework and thus I’m not going to cover it here.
I’ll cover React below, but a few others out there include:
- Knockout: This data binding library was one of the first of its kind many years ago. Recently it’s shown its age and doesn’t have much active development or support. I don’t recommend using it these days… instead, look to Vue.js which is seen as the modern day Knockout with much more active development, support and a supporting ecosystem than Knockout.
- Aurelia: This has a similar feel to Angular, but leverages conventions over code for how things are declared. It’s a very good library, but it’s not one of the bigger ones I see people talking about or interested in. That’s not a slight in any way, I’m just focusing on the bigger ones.
- Ember: Ember is another web framework that leverages handlebars like templates. Similar to Aurelia, it’s not one of the “big three” leaders I see people asking about so I’m not going to focus on it here.
- Preact: Preact is very much like React, but it’s a much smaller version (~3k) to React (~45k) by stripping out React’s event handlers in favor of the browser’s default event handlers. For SPFx projects, I don’t think the benefits of using Preact over React are there since React is already on the page (more on this in the React section below), there’s no reason to get a smaller version of React when you can use what’s already on the page.
Feel free to explore any of these options above. However, in my opinion, you really only should consider the following three popular options:
- Angular (v2.0+)
React is primarily a view implementation web framework at its core. It enables developers to create single components with or without state. It can also be used to create full-blown applications. There are plenty of add-ons available to handle things like model management, routing and much more.
Microsoft selected React for SharePoint Online and many other Office 365 related properties not so much because they think React is the best of all the frameworks, but because it worked well for their needs. React works great if you are creating components that will be used in various places, such as web parts, and allows multiple teams to collaborate together.
Looking to get ramped up on React? Check out the React tutorial on the React site.
Let’s look at why you should use React in custom SPFx solutions, but also why you should avoid it.
The SharePoint team is using React to implement various controls, such as property panes on SharePoint modern pages. This includes the filter panes in lists and web part property panes. Because of this, the React library is already on the page in most cases. This library is roughly ~45kB (v15.6.2… the version of React currently in use in SharePoint Online at the time of writing) in size… since it’s already one the page and in use by SharePoint, you can leverage the version they are using and not have to add another library to the page.
Furthermore, the SharePoint Framework team at Microsoft has included a React project template for creating SPFx client-side web parts and field customizers.
The Office UI Fabric is a set of styles and components from the OneDrive team that are used across Office 365 properties, including SharePoint Online. The interactive components are created using React, called Fabric React. Not only is Microsoft using these controls, but you can leverage them within your own projects as shown in the SharePoint docs here: Using Office UI Fabric Core and Fabric React in SharePoint Framework.
Are there reasons you should avoid React? Avoid is a strong word… I don’t think you should avoid it, but there are reasons you may choose not to use it.
You very well may have deep experience with another front-end framework, such as Angular, Vue.js or one of the others listed here.
There’s nothing in SharePoint Online or SPFx that blocks you from using another framework.
The team behind Fabric React has made a few sudden changes that have introduced backward incompatibilities which have broken many developer’s projects. As such, Microsoft’s latest guidance in using the Fabric React components is to include them in your project’s bundle and not reference the versions provided by Microsoft so you can insulate yourself from these changes. Of course, the challenge with this is now you are shipping reusable code multiple times within each of your projects, making for heavier pages.
Angular is another popular front-end library that has been around for a while. Angular comes in two forms, AngularJS (v1.x) and Angular (v2.0+, including the current 5.0 version).
This library is traditionally a full-blown web framework that you use to build full web applications, including single page applications (SPAs) because it provides routing, navigation, data access, dependency injection and much more.
For the purpose of this article, I’m going to focus on the current version of Angular, Angular 5.0.
Looking to try out the latest version of Angular? Look at the Angular Tutorial on the Angular.io website.
Why would you consider using Angular in SPFx projects?
Angular, in its initial version AngularJS and now it’s v2.0+ life, is a very experienced front-end library. It’s battle-tested at Google and by millions of developers worldwide.
There’s a good chance you already know Angular if you’ve been in the client-side development world. If you already know a library, why would you want to go jump into learning yet another front-end web framework?
This was one of the biggest frustrations I saw with experienced SharePoint developers picking up SPFx. Most who had done client-side dev had experience with Angular, but not with React. As such, there was a lot of angst from people who thought “I just followed your advice to learn Angular and now you tell me I have to switch?”
As I explain in my post Solve the SharePoint Framework + Angular Challenge with Angular 5.0 Elements, soon Angular will provide an ability to author components and not just full-blown applications.
One nice aspect of these components is that they are web components, a web standard which will allow them to be used with or without Angular applications, even in React or VanillaJS applications. This promotes reusability.
Why wouldn’t you use Angular in SPFx projects?
Today, Angular 5.0 doesn’t work well within the SPFx solutions. I’ve explained why in my blog post What’s up with Angular (v2.x / v4.x) and the SharePoint Framework?, but I then go on to explain in my post Solve the SharePoint Framework + Angular Challenge with Angular 5.0 Elements.
So it’s coming… and within just a few months so I don’t see this as a big roadblock anymore. Want to see what it looks like today with some real-world working web parts? Check out Sebastien Lever’s repo on Github: spfx-no-webparts
Yeah… that’s a downside. React is already on the page so there’s an argument against adding another front-end framework to the page. How big is Angular 5.0? It all depends on what pieces you are using, if you are using animations and so forth. But, it’s another library you are adding to your user’s page download so there’s that to consider.
Unlike React projects, there is no popular Office UI Fabric component library implementation out there and certainly not one created and used by Microsoft. While there’s motivation behind one as I shared in my post Future of the ngOfficeUIFabric Project - Office UI Fabric Components, we’re still a good bit of time away from that.
That’s not to say there aren’t component libraries. Google’s Material Design shares very similar design elements that the Office UI Fabric has… to many developers and users, it’s close enough. There’s even a suite of controls from Google that you can use in Angular projects: Angular Material.
Another front-end library option is Vue.js. This library is similar to React in that it is mostly a view implementation with a strong suit in data binding that has a rich ecosystem around it.
If you are familiar with KnockoutJS, think of Vue.js as the successor to Knockout, except one that has more support, activity and a vibrant ecosystem around it.
Want to give it a shot, check out the Vue.js Tutorial on the Vue.js site.
In addition, you can see an example of Vue.js in use within an SPFx project in this todo single file component sample web part from Microsoft.
When should you consider using Vue.js?
You know the answer to this if you used KnockoutJS. KnockoutJS isn’t a full-blown front-end library. You would use KnockoutJS when you simply wanted to do data binding on the page and you weren’t looking for routing, navigation, data access or other things. Those are the same reasons when you would use Vue.js.
It is a great little library when all you need is data binding.
While it isn’t already on the page like React is, unlike Angular, Vue.js is a tiny front-end library, weighing in at just a tiny 20kB.
While not based on the Office UI Fabric, there is a very complete and impressive UX library available to Vue.js developers. VuetifyJS contains a ton of UX components that implement Google’s Material Design language… just like the Angular Material library.
While the whole library is over 200kB, there is an a-la-carte option where you can get only the components you are interested in.
When should you avoid using Vue.js with SPFx?
As stated above, Vue.js is great when you need data binding and event handling with templating capabilities. But if you need stuff like dependency injection and additional capabilities like frameworks such as Angular can provide, then Vue.js might not be a good suit for your project.
Yeah… that’s a downside… just like Angular. But then again, this library is tiny so is it really an issue?
In this post, I wanted to provide a few different things you should consider when looking at different front-end libraries. I am doing my best to avoid giving a direct “you should learn foo front-end framework” when people ask me which one they should learn. Look at what you are doing and try each one out… it won’t take more than a half-day to run through all three tutorials.
Clearly, there are advantages to adopting one over the other… and it might seem like React is the most sensible option. For some, it may be… there are a lot of things going for it being that it is already on the page, there are project templates included in the Yeoman generator & you can use the component library that Microsoft uses.
But for others, it may be too much to adopt and abandon their existing investments in other libraries such as Angular.
Hopefully, this has shed some light on the dilemma and provided some insight into the decision process in picking a front-end framework for your next SPFx project.