Table of Contents
2017 has been another crucial year for JavaScript: if there was still someone thinking that the <script> tags wouldn't have a leadership role on web development, it has now become impossible to even say that: among the insane amount of changes we've witnessed in these latest months, the scripting language designed by Brendan Eich and firstly introduced by Netscape Communication Corp. in December 1995 is more alive than ever. Let's just take a look at these facts & numbers:
- 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.
JavaScript leading role in modern web development is now acknowledged even by those big players who chose to never really commit into it, such as IBM, who recently named it among the best programming languages to learn in 2017. The reasons for that are very simple: JavaScript nowadays it's the only language being used on both on client and server sides; whenever you need to design an UI, add reactive features to a web application, dinamically modify a page or interact with a RESTful interface, there's little or no chance you could avoid using it.
Client-Side Frameworks
However, most of the JavaScript popularity achieved within the latest 2 years has not been brought by JQuery and Node.JS: the boost, at least by a considerable amount, was due to the imposing presence of the modern Client-Side Frameworks such as Angular (formerly AngularJS), React and VueJS - just to mention the most popular ones. Although they started being simple "skeletons" for single page apps, allowing devs to worry less about the code structure and focus more on the UI, they quickly became much more than that: Server-Side Rendering, Virtual DOM / Shadow DOM, Component-based design and a lot of other features have been introduced in an attempt to create a strong set of coding standards in order to speed-up the web app development time.
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.
- If the answer is YES, we're definitely on the right track: there's simply no way to properly put together a SPA or a PWA with pure JavaScript nowadays, because there are too many things to look at. No matter how good you (think you) are, you're going to need the abstractions, the pre-loaded functionalities, the template structure, the component-based approach and a bunch more of other tools provided by these packages - unless you want to spend an insane amount of time trying to reinvent the wheel. If you think that learning a framework will be "too boring" or will take "too much time" compared with good old hand-made JavaScript, either you don't know what you're talking about or you're not aware of what a non-trivial SPA actually is... hence you don't know what you're talking about.
Why Angular?
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
Let's start with some statistics: if we take a look at the StackOverflow 2017 surveys, we can easily see how Angular (51%) is still less loved than React (62%): however, if we compare these results with the 2016 ones, we can see how Angular greatly improved its score. This is a clear sign that the framework managed to persuade a number of client-side developers and enthusiasts after its tormented start in Q3/Q4 2016, where almost all RCs and final releases had their (un)fair amount of compatibility issues and breaking changes. The new SO benchmarks clearly shows that the (brain)storm is finally over; the Angular core is now as stable as ever , with a long-term support, release schedule & migration plan available. On top of that, the source code is strongly layered upon the TypeScript tools & features set: auto-completion, navigation, refactoring, explicit abstraction, statically typed approach, code readability and so on. From a developer perspective, writing in TypeScript has a tremendous amount of advantages compared to vanilla JavaScript: the Angular team understand that two years ago and placed their bet on that, and now they're finally starting to see the fruits of their bold and risky choices. Sure, React also features code completion and compile-time checks thanks to JSX, but... (see below).
Framework-oriented
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
In terms of easeness of use, learning curve and change management, Angular scores another big hit: React heavily relies upon pure JavaScript skills, which can easily lead to different coding styles and approaches: conversely, Angular - thanks to its requisite conventions - forces the developers to stick to the same patterns, meaning that they will - arguably - quickly familiarize with each other's code... Expecially if they do already possess an OOP background. That's expecially true when talking about widely adopted software architectural pattern such as Model-View-Controller (MVC), which is where Angular really shines.
MVC out-of-the-box
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.
The only downside of doing that - from an Angular perspective - is that React only requires JavaScript knowledge, while Angular expects developers to adopt their own template sintax, which can be troublesome at first, with a negative effect to the learning curve. In my previous ASP.NET Core and Angular 2 book I didn't emphasize templates enough: I tried my best to make amend in the ASP.NET Core 2 and Angular 5 book, where all the UI-related components are splitted in three separate files: the underlying logic (TS file), the UI template structure (HTML file) and the UI styling (CSS file).
Two-Way binding
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...)
