Disclaimer: this post reflects my personal experiences from the last 1.5 years since the previous post I wrote about this subject might and be a bit subjective. Feel free to comment!
In 2016, Angular and React are the main frameworks. Don’t try migrating from Angular 1 to Angular 2. Consider Aurelia instead of Angular 2 because of simplicity and common sense.
Gulp and Grunt are still much used for building and packaging apps, but webpack is starting to take over. For package management, NPM has become the standard. Don’t use Bower (or NuGet).
Visual Studio Code has become a very serious alternative for the full Visual Studio. It’s fast and support for either ES2015/2016 or TypeScript is superb.
Todays main players are Angular and React (with their ecosystems) and these will probably not go away in the coming years. You could just say: pick Angular if you favor two-way databinding and an Object-Oriented approach with enterprise-feel (similar to server-side .NET and JAVA). Choose React with some add-on libraries if you prefer a one-way data-flow and a more functional and light-weight approach. Unfortunately, the release of Angular 2 has made things a bit more complex.
Before Angular 2 was announced two years ago, Angular 1 was getting massively popular and still is today. Its concepts of two-way databinding and dependency injection resonated with a lot of .NET developers and most people could live with its intricacies.
However when Angular 2 was announced, it became clear that this was going to be a totally different framework with no straight upgrade path. For me, this meant that I put Angular ‘on-hold’ because Angular 1’s future was uncertain and Angular 2 was nowhere to be seen yet.
But today, Angular 2 is released and can be considered for new projects again. My feelings over it are mixed: I really like the concept of Components, working with TypeScript is quite nice (you can still choose ES5 or ES2015, but nobody does that) and gone are the days of $scope.apply() but on the other hand, the template syntax is strange and it has so many parts and abstraction layers that it has become almost impossible to grasp in a short time. For example: Angular 2 now relies on RxJS for some of its core functionality and that alone already has a huge learning curve.
Despite the efforts made to make the transition from Angular 1 to Angular 2 possible, I think it’s going to be very hard to migrate. I gave it a shot with an existing 1.x app, but that experience was the same as choosing a completely different framework.
Still, I think Angular 2 is going to be used a lot despite some objections I may have :-). The community around it looks quite healthy, there are plenty of resources and training courses and component vendors like Telerik and Ionic already fully support and leverage Angular 2. It’s probably a safe bet for new projects.
Initially, many people are put off by the JSX syntax of React, including myself, but actually it works quite well. Otherwise the learning curve isn’t really steep because React itself is so small and focused. The addition of and interaction with other libraries can make it complex. Still, I find it very enjoyable to work with. Simple and easy to reason about due to the one-way data-flow. No magic.
There are many other frameworks and libraries like Ember, Vue.js and golden oldies like Backbone and Knockout (which you really should not be using anymore for new projects) but I’d like to especially mention Aurelia. This framework historically has a strong connection with the .NET community due to its creator Rob Eisenberg (in same way Ember has a strong link with the Ruby on Rails community). In my opinion Aurelia is the common-sense alternative for Angular 2. Supports two-way databinding, super clean template code and generally very straightforward to program against. My only concern is the relatively small community. Aurelia has a hard time attracting developers from other non .NET communities but on the other hand, the same can be said about Ember and that has proved to be a solid framework for many years already.
So whether you’d use one over the other depends on if you want types or not. Personally, I still prefer ES2015 with its flexibility but TypeScript doesn’t really get in your way because almost all of the extra type functionality is optional. For large projects, I’d probably pick TypeScript because of the better refactoring possibilities and tooling support.
Most people use Babel to compile ES2015 and TypeScript comes with its own compiler (tsc). You probably also want to use modules and therefore you’ll need a module loader/bundler such as webpack, SystemJS, Browserify or RequireJS. Most of these also have the possibility (via plugins) to build and package stylesheets and include images in the resulting bundles.
In theory it’s possible to hook compiling and bundling (the entire build process) together with batch/shell scripts, but many people prefer to use a task runner like Gulp or Grunt.
As you can see, there are many options here and it takes a lot of time to figure out the best combination of tools for your situation. All I can say is that for me, webpack with just a couple of scripts just worked great where the others always required a lot of fiddling and tweaking. Apparently, I’m not the only one because we’re clearly seeing a trend towards the use of webpack in various Open Source projects and frameworks (for example, the Angular-cli recently switched from SystemJS to webpack).
NPM has become the standard for browsers. All major packages are published there. Bower had its time and JSPM, although great in theory, never delivered its promise because of too much moving parts and too complex.
It’s a bit unfortunate that Bower was introduced in Visual Studio 2015 as the default package manager for browser packages just when NPM took over. Oh and please stop (ab)using NuGet as package manager for browser packages. NuGet is for compiled .NET libraries, period.