August 2017
Volume 32 Number 8
[The Working Programmer]
How To Be MEAN: Up-Angularizing
By Ted Neward | August 2017
.jpg "Ted Neward")
Welcome back again, MEANers.
It’s been two years since I started this particular series on the MEAN (Mongo, Express, Angular, Node) stack. And, as was bound to happen, various parts of the MEAN stack have evolved since the series started. Most of these updates (specifically the Node, Express and Mongo versions) are transparent, and adopting them is a non-event: Just upgrade the underlying bits and everything works.
But Angular upgrades have been of some concern to the Web front-end world for a while, particularly because the substantive changes between AngularJS (v1) and Angular (v2 and beyond) created some serious backward-compatibility issues. (I use the term “backward compatibility” loosely here, because the backward-compatibility story for v1 to v2 was essentially, “Rewrite the whole thing—trust us, it’ll be great!”) Thus, it was with some amount of consternation that the Angular world was watching for the first major update to Angular, and when that update was announced to be a major version enhancement, anxiety mounted.
Turns out, while we were busy writing the front end of the sample application, the Angular team did what they were supposed to do—release a new version of Angular into the world. That means it’s time to take a moment, bite the bullet, and upgrade the application to the new version of Angular: v4. (The Angular team decided to skip 3 and move straight to 4.) Spoiler alert: This turns out to be far, far less painful than people imagined it might be, and offers a lot of hope regarding future Angular updates—which is good because the Angular team has promised that they’re going to release cadence much more in line with traditional open source projects. Which means, bluntly, a lot of small, incremental upgrades released much more quickly (every 6 months) than what’s been the norm so far.
Upgrading Angular
Fundamentally, upgrading to Angular 4 means using the Node Package Manager (npm) to update the npm packages in use to the latest versions. This takes the form of the too-familiar “npm install” command, using a version tag (“@latest”) for each package and the “--save" argument to capture the latest version into the application’s package.json file. For those running on a *nix system (Linux or macOS, typically), the command takes the following form, all of which should be typed on one line:
npm install @angular/{common,compiler,compiler-cli,core,forms,http,platform-browser,platform-browser-dynamic,platform-server,router,animations}@latest typescript@latest --save
The *nix command shells allow for the various packages to be captured under the “{“/”}” pairs, even though technically each one is named “@angular/common,” “@angular/compiler” and so on. For those of you on Windows, you get this slightly longer version:
npm install @angular/common@latest @angular/compiler@latest @angular/compiler-cli@latest @angular/core@latest @angular/forms@latest @angular/http@latest @angular/platform-browser@latest @angular/platform-browser-dynamic@latest @angular/platform-server@latest @angular/router@latest @angular/animations@latest typescript@latest --save
Once the “npm install” is finished executing, for all intents and purposes the upgrade is done. Simply run the application using “ng serve” again, and everything should be back to running status.
Angular 2-to-4 Pain Points
The Angular team has admitted that it’s not always a smooth transition—however, the release notes take care to point out that most of the pain (apparently) is localized to the use of animations, which is a subject I haven’t explored yet. Specifically, the team removed animations from @angular/core, and dropped them into its own Node package, @angular/animations (which you can see in the previous “npm install” command). That way, if the application doesn’t use animations, it doesn’t have to carry along the code of animations in the core package.
Angular 4 New Features
The Angular 4 release notes carry the full weight of the story, but there are a few things in particular worth calling out.
First, the Angular team is focused on reducing the size/weight footprint of the Angular libraries. This is good for obvious reasons, particularly for those users who aren’t on high-speed fiber connections with the rest of the world. The Angular team says they’re not done, either, so expect that each successive Angular release will seek to decrease its footprint even further.
In the same spirit, the Angular team has reduced the overall size of the generated codebehind view templates, up to 60 percent. Again, this means that the application you build will be that much smaller and lighter.
Second, the team improved the “*ngIf” and “*ngFor” directives used in view templates for branching and iteration scenarios, respectively. You haven’t seen those yet, so the new features won’t be apparent yet, but you’ll see them soon, so hang in there.
Last, the Angular team also brought the Angular libraries up to the latest versions of TypeScript (2.2), which includes better nullable checking, some better type support for ECMAScript (ES) 2015-style mixings, and an “object” type to represent a type that’s the base type of all declared types in TypeScript, similar to the role that System.Object serves in much .NET code. This implicitly also brings support for TypeScript 2.1, which has some interesting features on its own, like the “keyof” operator, mapped types (which provides the utility types Partial, Readonly, Pick and Record), and support for the “spread” and “rest” operators from ES 2015. All of this is well beyond the scope of Angular itself, but any good TypeScript tutorial (or the TypeScript Web site itself) will explain their use. Fundamentally, these won’t change the code that you write when writing Angular, at least not right away, but as these features get used more in the Angular library, they might start finding their way into the surface area of the Angular API. That likely won’t happen for a while, however, so for the moment, the biggest thing to keep in mind is that Angular is keeping up with the evolution of TypeScript.
Wrapping Up
Hopefully I’ve helped you understand that doing this upgrade costs you almost nothing to do—that’s the best kind of version update. More important, it’s refreshing to know that as Angular applications grow and evolve, the required work to keep them up-to-date with the latest versions of Angular is (for the moment, anyway) trivial.
How To Be MEAN: Two Years On
While working on this column, MSDN Magazine Editor in Chief Michael Desmond pointed out that my How To Be MEAN series was turning 2 years old as of this issue. How is it that I’m still working in the MEAN mines? Some of it has to do with the fact that this series is attacking a rather large subject—a complete soup-to-nuts, front-end-to-data-storage, REST API middleware-based platform, rather than just a library or framework. But some of it has to do with the nature of the MEAN stack itself.
You see, the MEAN platform is different from the .NET Framework platform not in terms of what it provides—both have a programming language, an HTTP library/framework for receiving JSON data submitted, drivers for accessing databases and so on. Rather, it differs in terms of what it doesn’t provide. That is to say, the MEAN platform, building on top of the Node.js platform stresses a sense of “minimalism” that the .NET platform doesn’t.
That might sound like a slight to one or the other platform; that somehow Node.js isn’t “fully baked” or that .NET is “too heavy.” No such value judgement is intended. But where .NET emerged from Microsoft and continues to be heavily driven by what the .NET Framework team has built over the years, the Node.js platform has been bolted together by libraries built by hundreds of teams and thousands of developers from all across the world. There are pros and cons to each approach—but that’s not the direction I’m headed with this.
The fact is both platforms are available to you, at your discretion. And even just two years ago, the idea of Microsoft being a platform by which developers could use either .NET or Node.js—or even Java or PHP—for building applications on or near the Microsoft OS (or cloud platform) seemed ludicrous. There were signs that suggested that Microsoft might reach this kind of “all platforms created equal” mentality, but the company’s history suggested we might see an approach where .NET would be first among those equals.
Consider this for a moment: The “A” in the MEAN stack stands for Angular. When I began this series, Angular was not the powerhouse, rich-client, single-page application (SPA) platform that it is today—it was but one of several potential bets that you might make on the JavaScript front-end landscape. Angular has seen a definite rise in interest, and the pages of this magazine have been decorated with numerous references to Angular, both within the confines of this column and in feature pieces written by others.
What’s remarkable is that this interest is in a front-end technology written in the open source world by a team that not only doesn’t work for Microsoft, but works for one of Microsoft’s competitors. Yet it uses the open source TypeScript language developed by Microsoft. It’s enough to make your head spin.
The MEAN stack, and the coverage of MEAN in this magazine in many ways articulate everything about “the new Microsoft.” It’s a stellar demonstration of how the Microsoft of 2017 is so entirely different from the Microsoft of 2007 or 2000. The Microsoft that valued competition over cooperation and community is long gone. The company before us today certainly competes, but not with its community. The Microsoft of 2017 wants you to use the technology stack of your choice, ideally within its cloud or on its OS, but if you have a different choice than that, well, that’s your choice.
At the end of the day, the MEAN stack is “just” a stack made up of three parts (MongoDB, Angular and Node.js/Express) that can interoperate with one another. And the fact that Microsoft not only embraces that, but encourages it, tells you just how far things have come from where it was before.
Kind of makes you wonder what the next few years have in store for us, doesn’t it? Happy coding!
Ted Neward is a Seattle-based polytechnology consultant, speaker and mentor, currently working as the director of developer relations at Smartsheet.com. He has written more than 100 articles, authored and coauthored a dozen books, and works all over the world. Reach him at ted@tedneward.com or read his blog at blogs.tedneward.com.