Page 74 - MSDN Magazine, August 2017

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.
In the same spirit, the Angular team has reduced the overall size of the generated codebehind view templates, up to 60 percent.
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 work- ing 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.
Considerthisforamoment:The“A”intheMEANstackstands for Angular. When I began this series, Angular was not the power- house, 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 technol- ogy 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! n
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.
68 msdn magazine
The Working Programmer