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 Recommend One; I Recommend a Process How to Choose one
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.
In addition, check out the latest JavaScript survey… the results of the 2017 survey were published on December 12, 2017. Also check out what the survey panelists said. I found it quite interesting they were pretty unanimous in favoring React over the others, although it was disappointing there wasn’t much “why” or background to their answers.
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.
Web Framework Options
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:
- React
- Angular (v2.0+)
- Vue.js
React
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.
Use React with SPFx Because…
Let’s look at why you should use React in custom SPFx solutions, but also why you should avoid it.
It’s Already There
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.
Growing Popularity
While I’m not big on following the leader, you can’t deny React is growing in popularity. Looking at the latest results from the front-end Library results in the 2017 State of JavaScript survey, React is clearly the dominant player here when measured against other front-end libraries. This story hasn’t changed much since the 2016 results of the same survey.
First Class Support in Yeoman Generator
Furthermore, the SharePoint Framework team at Microsoft has included a React project template for creating SPFx client-side web parts and field customizers.
Office UI Fabric Components from Microsoft
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.
Avoid React with SPFx Because…
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.
Experience with Other Frameworks
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.
JSX Syntax
React introduces a syntax that mixes HTML and JavaScript that rubs some developers the wrong way. This syntax, JSX, and it’s close TypeScript cousin TSX, can be enough of a change that it keeps some developers from picking up React.
Fabric React Has a Challenging History
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
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.
Use Angular with SPFx Because…
Why would you consider using Angular in SPFx projects?
Robust, Experienced Library with Vibrant Ecosystem
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.
Don’t let the comments about “Angular’s diminished popularity” in the State of JavaScript 2017 survey scare you. From my POV, The story hasn’t changed that much from 2016 to 2017. Yes, Google dropped the ball in taking so long to get from v1.* to v2.0 and then there was the whole naming fiasco. Regardless of all that, this library isn’t going anywhere. It’s critical to so many internal projects at Google, you can rest assured it’s got a nice long life ahead of it.
You Already Know Angular
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?”
Soon, It will Support Authoring Components
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.
Avoid Angular with SPFx Because…
Why wouldn’t you use Angular in SPFx projects?
It Doesn’t Work with SPFx yet
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
It’s Not Already There; Another Library
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.
No Office UI Fabric Component Library
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.
Vue.js
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.
Use Vue.js with SPFx Because…
When should you consider using Vue.js?
You Just Need Databinding
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.
Tiny Payload: 20kb!
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.
Very Complete UX Component Library
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.
Avoid Vue.js with SPFx Because…
When should you avoid using Vue.js with SPFx?
You Need More than Data Binding
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.
It’s Not Already There; Another Library
Yeah… that’s a downside… just like Angular. But then again, this library is tiny so is it really an issue?
Conclusion
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.
