Table of Contents
- JQuery is literally dominating the scene, being applied to 96.2% (in October 2017) to all JS-enabled websites.
- ECMAScript is evolving at an insane speed, amending its 5-years hyatus (2011-2015) with a yearly batch of proposed features (2015, 2016, 2017) since the launch of ES6. If we took some time analyzing the new proposed features, we can see how serious such approach actually is: concurrency and atomics, zero-copy binary data transfer, math enhancements, observable streams, syntactic integration (await/async) with promises, SIMD types, operator overloading, value types (first-class primitive-like objects) and so on. One thing is for sure, that’s not the easy messy, yet dressy scripting language we used to know anymore.
- Node.js, even after the expiration of the initial hype, continues to be enormously popular and growing in 2017 in terms of its community, opportunities and versatility: all recent surveys agree upon the fact that it’s still eating huge market share quotas as an universal development framework for digital transformation with a broad diversity of apps.
Did they succeed in doing that? The numbers speak for themselves: each one of these projects managed to get an impressive amount of followers and popularity, despite they share the same market quota – they’re no less than competitors, after all! There’s no way in the world that using more than one of them in the same project would bring up something good (except for very specific scenarios). How is that possible? Well, it’s not so different from what already happened on the server-side part of the street just few years ago, when ASP.NET/C#, Django/Phyton, Laravel/PHP and a bunch of other opponents started their fight to impose their leading presence among the best MVC frameworks. What was the outcome again? No clear winner, yet each one of them is doing pretty much fine in terms of popularity and overall usage – leading us to thing that, luckily enough, framework wars are not that deadly for those who fight them.
Angular, React or Vue?
Choosing between Angular, React or Vue – or even less-known alternatives such as Aurelia, Ember, and more – is an anything but easy task. The first question we should ask ourselves is: do we really need to build a Single-Page Application or a Progressive Web Application? Or, to put that same concept in more precise words: are SPAs and PWAs the most effective tool to fullfill our given set of requirements?
- If the answer is NO, we are probably wasting our time: we could probably do a better job with one of the server-side MVC frameworks such as the one mentioned above and build the client-side UI with the help of DOM and CSS general purpose frameworks such as JQuery.
There are multiple things to consider when you have to choose a client-side framework: among them, those related to the strengths and productivity advantages of the framework itself are arguably the most important ones. We’re talking of questions like the following:
- How mature the framework – together with its primary set of add-ons, packages and/or libraries – actually is?
- Is the SDK and the development interface viable, stable and user-friendly enough?
- How easy is it to use such framework for small-scale and/or large-scale applications?
- What kind of performance can we reasonably expect?
There are also a number of strategical considerations that also need to be considered, such as:
- Is the framework widely used?
- Is the community widespread, active and helpful enough?
- What kind of documentation & support is available as of today?
- What does the learning curve look like?
- How easy is it to find (and/or replace) expert developers?
Address all these questions at the same time can easily be overwhelming, expecially if we consider the fact that the client-side popularity boost could easily hide the actual truth for most of them. How to distinguish between the faerie fire and the real deal?
A look at the stats
Another thing to consider is the fact that Angular is meant to be a framework rather than a library because it provides strong opinions as to how your application should be structured and also has more functionality out of the box. This basically means that Angular already has most of its features bundled within its own package set, thus aiming to be a complete development framework by itself, while React and Vue heavily rely to independent, unsettled, fast-moving libraries: the latter approach can easily be a nightmare for the developer, since he has to take care of the corresponding updates and migrations on his own.
The learning curve
Most of the other client-side frameworks only have the V part, leaving the developer with the task of figuring out how to deal with the M and the C on his own. Angular integrates most concepts of the MVC approach, to the point that has a number of things in common with the ASP.NET Core MVC Pattern: the Component class and its HTML template is not that different from the MVC Controller and its View, at least from a conceptual point of view: that’s why the two technologies blend so well.
This is among the best reasons which led me into picking them for my ASP.NET Core 2 and Angular 5 book, where I did my best to demonstrate how easy it is to build a sample SPA using these two technologies.
HTML + TypeScript
On October 2013 Peter Hunt did a great job defending the React’s JSX approach, switching the focus from the Templates to the Components: he was also correct in stating that the developers should give their best to separate the concerns, not the technology or the application layers. Conversely, Angular strongly advocates the template layer with their brilliant implementation of HTML + TypeScript, allowing the developer to build different Components and also keep their UI/presentation layer separated from the inner logic. We could say that Angular (with their template approach) found a way to inject TypeString into HTML, while React (with JSX) struggles to put HTML into JS.
Another big difference between Angular and its competitors – apart from Aurelia, which was made by Rob Eisenberg after his departure from the Angular 2 team – is the two-way binding feature: Angular’s two-way-binding changes the model state when the UI element (for example, an input issued by the user) is updated. Most client-side frameworks, including React, only go one-way: they update the model first, then they process the UI element.
Angular’s approach is arguably easier to pull off than its counterparts and allows the developer to produce succint, clean and readable code. Two-Way data binding is a major concept of Chapter 3, 5 and 7 of the ASP.NET Core 2 and Angular 5 book, being one of the key features of the sample SPA built during the various chapters.
Size, Performance & Testing
When it comes to size, performance and testing, all the client-side frameworks shows a pretty similar face. The package sizes tends to be fairly equal, as long as tools such as Webpack are used to optimize the production build; the performance benchmarks show little or no differences, at least for the time being; as for the testing, they’re all suggesting Karma as their primary choice, so there’s not much to compare there. Before Angular 4 we could definitely say that JSX was more powerful at compile time because it had compile-time checks, but the recent AOT improvements, together with the TypeScript support provided by Visual Studio, fixed that gap for good.
In my previous book I didn’t use Webpack at all: I went for the dynamic module loader approach using SystemJS instead, coupling it with a task-runner (GULP) to deal with the rest; it worked out well, yet I felt that the whole package was too cumbersome for the average developer. In the ASP.NET Core 2 and Angular 5 book Webpack plays a major role and – thanks to the new WebpackMiddleware shipped with ASP.NET Core 2 – greatly simplifies the development and deployment scenarios.
(to be continued…)