Preface (Post-Feedback)

I’ve received some (constructive) criticism on this article, and it was warranted. There’s a few things I should have been more clear on up-front.

First, my opinions and speculation regarding Microsoft’s dropping of Vue as an officially supported framework are just that — opinions and speculation. The larger goal of that discussion was to spark more conversation about the .NET ecosystem’s (as a whole) growing interaction with JavaScript front-end frameworks on the client side.

Second, I should have mentioned earlier in the piece that the second half of the article is devoted to explaining the work I did in finding a viable .NET Core 2.1 / Vue.js setup. If you aren’t interested in commentary about Vue/.NET, please — scroll down. Additionally, I’ll be expanding on that portion significantly in the coming days. I definitely could/should have made that section more robust.

Finally, I just wanted to note that despite any perceived negativity, I’m a huge fan of Microsoft’s, Steve Sanderson’s, and the entire JavaScriptServices/SpaServices’ teams’ work. Without all of the advancements they’ve made, this discussion wouldn’t even be possible. I also want to highlight a particularly promising project by Steve Sanderson that is currently in the works — Blazor.

Per Steve Sanderson’s blog:

“What is Blazor? It’s a framework for browser-based (client-side) applications written in .NET, running under WebAssembly. It gives you all the benefits of a rich, modern single-page application (SPA) platform while letting you use .NET end-to-end, including sharing code across server and client. The announcement post covers more about the intended use cases, timescales, and so on.”

I’m extremely excited about Blazor — it looks like it could be the missing piece to fill the void that Razor pages/Jquery used to occupy.

Finally, I just wanted to thank everyone that has commented both here and on Reddit. The feedback I’ve received has been well-taken, and will be considered moving forward. I’m choosing not to alter my original piece — I’ll let it stand, even if in hindsight some of my opinions could have been more deeply considered.

Thanks for reading.

The State of the SPA in .NET Core 2.1

F irst, a little background: I work in a medium-large-sized corporation’s development team. We run a traditional MVC 5 stack backed by SQL, with a Vue.js front-end. It works, but it hasn’t been without its headaches. Despite the issues, we are sticking with Vue, and are preparing to upgrade to Core 2.1 over the Winter holiday.

In preparation for our upgrade from MVC 5 to Core 2.1, I’ve been doing research on my own time — getting familiar with changes and determining where potential roadblocks may occur.

One of the first stops I made in my quest to learn Core was Microsoft’s JavaScriptServices page. The JavaScriptServices packages are described as: “a collection of client-side technologies for ASP.NET Core. Its goal is to position ASP.NET Core as developers’ preferred server-side platform for building SPAs.”

The collection is made up of three NuGet packages:

Each of these packages provides new features and are extensible in 2.1 in ways that weren’t possible or nearly as practical in previous releases. If you’re at all familiar with SPA development in .NET Core, you’ve probably already used one or all of these packages.

If you’re just getting started using the SPA features in .NET Core, run dotnet new — -install Microsoft.AspNetCore.SpaTemplates::* . The SDK comes with templates for React and Angular by default — this will install the rest of them. Once you have the full suite of templates installed, run dotnet new -l to view them.

I was happy to see that the larger collection contained a template for Vue.js. After running dotnet new vue and allowing the project to scaffold, I entered the ClientApp/package.json to inspect the bones of the project. I was disappointed, however, to find that most of the project’s dependencies (Webpack, Babel, etc.) were fairly dated. The template’s Webpack version, for instance, is 2.7 (current is 4x).

All of this is okay and the project runs, but there’s no question that you’re absolutely missing out on some of the most modern features of these dependencies.

Out of curiosity, I decided to scaffold a React project using the dotnet new cli. To my surprise, the React template’s dependencies were more or less completely up-to-date. Digging deeper, I found the cause of this discrepancy: Microsoft ended official support for Vue.js back in February, with Steve Sanderson stating the following:

“The Microsoft.AspNetCore.SpaTemplates package never shipped in the .NET Core SDK, and never reached an official level of support. The ASP.NET team's development resources are finite, and we think we can deliver more valuable features to ASP.NET developers by focusing elsewhere. So: The Microsoft.DotNet.Web.Spa.ProjectTemplates package, containing Angular, React, and React+Redux templates, is not affected. This ships in the .NET Core SDK and is officially supported. We continue to invest development effort in this package. We can put more time and effort into these SPA templates now the effort isn't so spread out. If you have an existing Aurelia/Knockout/Vue project based on our SPA templates, you’re not directly affected because these templates are only used to create new projects. You can continue building and shipping your app forever. Obviously we still support and enhance the underlying ASP.NET Core APIs (such as those in JavaScriptServices) that you are using. The Microsoft.AspNetCore.SpaTemplates package, containing Aurelia, Knockout, and Vue templates, continues to be available, but we'll no longer update it or work on issues related to it. We encourage enthusiastic community members to ship your own dotnet new templates. The dotnet new system is extensible for this exact reason. If you want to own the go-to Aurelia/Knockout/Vue project template, now's your chance! You could fork the ones from Microsoft.AspNetCore.SpaTemplates , or start from scratch depending on what you prefer. In the long term, if another JavaScript SPA framework becomes dominant, we will of course consider adding a template for it to the SDK templates package. I know this will be irritating to some people, especially those who have worked on PRs for the Aurelia/Knockout/Vue templates. I’m sorry about that! I hope you can understand that our goal is to offer the overall maximum benefit for ASP.NET developers based on the resources available. Discussion for this issue is at aspnet/JavaScriptServices#1522"

Source: https://github.com/aspnet/Announcements/issues/289

All of the above, at first glance, is completely understandable. A team, even at Microsoft, absolutely has limited resources. With the number of JavaScript frameworks available (there are many) today, one team couldn’t possibly be asked to provide enterprise-quality support for each and every framework out there. This is a more than reasonable stance to take, except that we’re not asking them to cover every framework available — just the most relevant ones.

Angular and React are without question leaders in the field — but Vue.js can no longer be placed into a category beneath either one of them. Vue has surpassed React in stars on Github, and while stars on Github do not equal commercial adoption, it’s becoming increasingly difficult to argue that Vue doesn’t deserve a spot at the big boys’ table. Just how “dominant” does a framework need to become to win back official support from Microsoft? What is the metric used to measure a framework’s dominance? How pervasive and ubiquitous does a framework need to become before it can be recognized as being a worthwhile investment of Microsoft’s resources?

Looking below at this Google Trends comparison displaying interest over time, it’s not difficult to see Vue’s increasing popularity (Vue in Blue, React in Red):