Welcome to the FileNotFound.Studio Angular Tutorial series! This will be a somewhat in-depth look at the Angular language, framework, and coding practices, done by a guy who kinda knows it, but is still learning it. It took a while for me to get the gist of everything Angular-related, so this is my opportunity to help others get over that hump a little easier that I did.
For a long time I was a .NET guy. I started with VB, moved to VB.NET, and then switched to C# and never looked back. It suited me for over a decade, and I was happy being a senior guy in that particular environment. But a few years ago I started to get a wandering eye for the growing JavaScript ecosystem. I think I felt like something cool was happening out in the wilderness (wild to me at least) and I needed to figure out what everyone was talking about. And true to form, when I find something truly interesting, I dive in without a second thought.
…and that’s essentially what the process of learning Angular felt like, at first – diving into the deep end of a pool without a life preserver. The JavaScript ecosystem, of which Angular is a part, can be both fascinating and unforgiving. It changes almost daily, and it incorporates design and development practices I wasn’t really familiar with. I had to learn, and re-learn, a number of new concepts (in fact, I’m still learning them… hello, RxjS), and not all of it was easy.
I have a little better handle on everything now, (we even do a lot of our software and web development in Angular) but I had to work through some rough patches to get there. And in retrospect, I think the learning process would have been easier if I’d been able to find tutorials or quick starts that didn’t already assume some knowledge of other JS concepts. Or worse, the tutorials were so dumbed down that they didn’t provide context or explanation. A why to go along with the what and/or the how. So, I decided the best way to remedy that would be to create a tutorial series myself, one that demystifies the JavaScript ecosystem, Node.js, NPM, and JS frameworks like Angular. Hopefully, future potential Angular developers who read this series will have an easier time learning how to make sense of it all than I did.
Let’s Start With Node
Part 1 of this series won’t actually dive into any Angular coding. Instead, I want to spend a few minutes (or paragraphs) talking about the environment Angular works in, what exactly Node.js and NPM are, and what Angular can do for you. This should hopefully give you some understanding of how all these tools relate to each other, along with the confidence that developing in Angular is right for you. It’s not going to be comprehensive. There isn’t time for that, not at the beginning, and not if you want to learn this stuff without getting a headache. But I want to at least introduce the concepts now so they make more sense when I sprinkle them in throughout the remaining tutorials.
So let’s start with the big name hanging over all of this… what is Node.js?
https://www.tutorialspoint.com/nodejs/nodejs_introduction.htm
Node.js is a platform built on Chrome’s JavaScript runtime for easily building fast and scalable network applications. Node.js uses an event-driven, non-blocking I/O model that makes it lightweight and efficient, perfect for data-intensive real-time applications that run across distributed devices.
There’s a lot of words in that description, and not all of them make sense to a newbie. So let’s put it in layman’s terms. Node.js is a tool that allows developers to create run-time applications that run on a server, instead of a client. Up until recently, JavaScript was the cute little scripting language that browsers supported to provide some interactive functionality on web pages. If you wanted to update the DOM dynamically, or move text/images around on a page, you used JavaScript. But it was all front-end, client-facing stuff. Now, thanks to Node, JS (JavaScript) is a full-stack development tool.
Why does this matter? Well, there are several reasons, but let’s get into the obvious one. If you’re using Node.js for your back-end development, and JavaScript for your front-end development, you can now build full-stack applications (also called the MEAN stack) using only JS developers. That’s a pretty big deal for teams currently stacked with three different types of developers, who know five different languages. Not only that, but there are databases now that can also be accessed via JS (like Mongo), providing a true full-stack experience. Development teams who all work in the same language can be smaller, cheaper, and more efficient than the alternative.
In addition, using JS across all tiers means we can use a universal data format, typically JSON, to ensure that data is passed from client to server to database and back again all in the same format. There are a ton of reasons why this is all good, but I don’t want to bog down too much into the history and ubiquity of JavaScript. Instead, I’ll let some other really smart people delve into the details. I do want to bring up an interesting quote from that linked article, though, one that talks about how JavaScript has become intrinsic to the web developer’s toolbox:
JavaScript was designed for the Internet, it’s been here since the beginning, and it’s not going away. All attempts to destroy it have failed: see, for example, the downfall of Java Applets, VBScript’s replacement by Microsoft’s TypeScript (which compiles to JavaScript), and Flash’s demise at the hands of the mobile market and HTML5. It’s impossible to replace Javascript without breaking millions of web pages, so our goals going forward should be to improve it. And there’s nobody better for the job than Technical Committee 39 from ECMA.https://www.toptal.com/javascript/guide-to-full-stack-javascript-initjs
Ok, alternatives to JavaScript are born everyday, like CoffeeScript, TypeScript and the millions of languages that compile to JavaScript. These alternatives might be useful for development stages (via source maps), but they will fail to supplant JavaScript in the long run for two reasons: their communities will never be bigger, and their best features will be adopted by ECMA script (i.e., JavaScript). JavaScript is not as an assembly language: it’s a high-level programming language with source code you can understand—so you should understand it.
Hopefully that makes practical sense. JavaScript is everywhere, so if we can expand it to develop applications from top to bottom, instead of just top (assuming ‘top’ is the client-end) then that makes things easier, cheaper, faster, and ultimately, better for development teams.
So what would you use Node.js for? Well, that’s the kicker. Node.js can do a lot, but it can’t do everything. When looking through quick starts, a popular development example for Node is usually a messaging app. Messaging apps don’t have your typical page refresh like a normal web site, and they require pretty instantaneous communication and feedback from the server. This plays right into Node’s strengths as a fast, lightweight, efficient, real-time, data-intensive app. That’s what Node is good for. It’s NOT good at computation-heavy applications, which means number-crunching or analysis. But it shines in real-time communications, which is an important aspect of modern web sites.
For a more robust description of the messaging app example, check out this article, and pay close attention to the connection between API and DB. That’s where Node shines, and if you don’t believe me, you can ask PayPal, Uber, Netflix, LinkedIn and more. They all use Node.js for some or all of their application development.
Again, Node can’t do everything, but few development languages are designed to do everything. They have strengths and weaknesses, and areas in which they shine and those where they stutter. The key is to understand Node’s strengths and to use it for apps that can make the most of it.
What About NPM?
So, Node.js allows us to write back-end server code in JavaScript. Cool. But we don’t actually HAVE to use Node.js for Angular apps, since Angular is a framework unto itself. Knowing what it does and how it works helps us better understand Angular, but it’s not a necessity. NPM, however, is a MUST HAVE.
NPM stands for Node Package Manager, and it’s essentially the world’s largest Software Registry. You get it automatically when you install Node.js, so there’s no need to grab it separately. NPM is the command-line tool you will ultimately use to get the Angular CLI, along with the dozens or hundreds of ‘packages’ that will typically run along with your Angular application.
A package is basically a fully-formed piece of code that does something useful for your application or project (kind of like NuGet for .NET devs, or Maven for Java). For example, one package might provide some UI elements for your page. Another helps you create a small, efficient web server to serve your page locally. A third provides animation support, and a fourth includes styling and css. Yet another helps with unit testing. The key point here is that each package provides some useful, self-contained, pre-built functionality, that’s typically community-developed. Also… these packages are usually free.
(I have yet to see one that costs anything, but I can’t discount the idea that some people charge for them. I’m hedging my bets by saying ‘usually’, when it reality it’s more likely ‘almost always’ free.)
Each package is stored in NPM’s library of packages, and you use the NPM command-line tool to download the package and include it in your Node or Angular (or other) application. Not only does NPM manage the package, it manages the version, too, and it does it all via the handy package.json file.
Package.json is Important, Too
Package.json is an important file in the JavaScript ecosystem. It’s a text file, written in JSON (hence the .json extension) that describes the application you’re creating and lists out all the dependencies, or packages, your app relies upon. NPM and package.json could be the topic of an entire post, as could Node.js and the history of JavaScript, i.e. How We Got Here, but as I mentioned before, let’s not bog down too much in the details, especially since we’ll get a lot more clarity on it all once we start developing. These concepts are all easier to understand when they’re introduced along with some context for WHY we’re using it.
The important thing to note with NPM and package.json is this – NPM is the tool that gets you the packages you need to include additional functionality in your project without writing it yourself. There are thousands and thousands of packages out there, nearly 800,000 as of March 2019, according to Modulecounts.com and NPM is essential to managing all of that. And package.json is the file that not only connects your app to NPM, it also manages your project configuration and some of the build details for compiling (or transpiling) your app.
One quick note on NPM, Node.js, and Angular… all of these things rely pretty heavily on command line tools. It’s a bit of a recurring theme. So it might be worthwhile to brush up on basic Command Prompt or PowerShell (my personal choice) usage. Most of the commands are pretty straightforward, but it helps to be able to navigate around quickly in a DOS-style window.
Can We Get To Angular Already?
To be clear, I’ve only barely touched the surface of Node.js and NPM. There’s so much more to learn about those tools, and I recommend you spend some time doing just that. But we really should start talking about the development language we all came here for. Angular. And fortunately for us, working with Angular will require us to delve into these other tools on occasion, so we’ll learn a bit more about them either way.
What is Angular? It’s a development framework, maintained primarily by Google and the Angular community, that allows you to develop JavaScript applications using something similar to MVC (Model-View-Controller…. don’t worry, we’ll get to that eventually). To make things a bit simpler, though, Angular’s strength is SPAs (Single Page Applications). These are apps, built on the web, that essentially operate within the context of a single page, or frame. Think of something like Gmail, or a modern web email client, as an example. You go there to check your email, create a new email, or to organize existing emails. There isn’t a lot of page navigation, and you don’t really see a page refresh when you click a button.
Angular’s strengths are varied, and a search won’t always return the same list, so I decided to just create my own, and we’ll flesh it out as we get deeper into the tutorial series. To get things started, I find Angular useful in developing high-quality, fast, user-friendly, and interactive web pages that are indicative of the modern web. And that’s just the front end. On the back end, Angular allows me to separate the View code from the back-end code, which in my experience almost always sits in a REST API that I connect to through HTTP. This allows for a more distributed application design, one that can work in almost any environment (desktop, mobile, etc.) We’ll get to that part in more detail later on in the series since it’s one of the tougher concepts to work through.
That’s the beginning of a list of high-level strengths of the framework, and while important, they don’t provide a lot of detail. Let’s rectify that by getting into some more specific items…
The Framework
Angular comes as a full-fledged framework, which means it provides everything you need to build an app from top to bottom. Not all JS ecosystem languages do this (React, for example), and the reasons for this vary, but in terms of functionality, having everything you need in one framework makes it easier to start learning and building. And while some will say that the entire framework makes the barrier to entry higher (a reasonable argument, which we’ll delve into later), it also makes the language popular with large companies, who prefer enterprise development solutions.
Components
Angular separates its code into services, models, and components (an oversimplification but one we’ll accept for now). Services are designed to handle what we’ll call ‘back-end code’ for this discussion, while the model describes the domain data your application will be working with, like users, or orders, or widgets. Components, in Angular, are pieces of the View, and by View I mean what the application displays to its users. (Again, I’m trying to oversimplify these concepts down into a language I would have better understood when I was trying to learn.)
The benefit of components comes from re-usability and focus. If a component handles a single piece of the View well, a Login component, for example, that handles both Sign In and Register functionality, then it could theoretically be used in other applications with minimal tweaks. Additionally, the component can handle just the login functionality and nothing else, forcing it to ‘stay in its lane’ and not be too dependent on other parts of the view.
Change Detection
React, the Facebook UI library that draws many comparisons to Angular, has a concept called a Virtual DOM. It’s essentially a virtual representation of a web page’s DOM (Document Object Model) that can be updated on the fly based on JS code. Angular doesn’t have a Virtual DOM, or a Shadow DOM, the other term for it, but it does have something similar in concept – change detection.
(Sometime in the near future I’ll be doing a comparison between React, Angular, and Vue, three very common JS frameworks that tend to do similar things. A common question people ask when getting into any of these tools is “which one is better?” A similar question to ask would be “what flavor of ice cream is best?” It’s subjective, and therefore I don’t intend to answer the question, so much as to help readers find the tool that fits them best.)
Change detection means that parts of the web application’s View (the actual page the user sees) can be bound to the model, which as I mentioned above describes the domain data of your app. When the data in the model changes, Angular is smart enough to update the View to match it. A very simple example would be if a user enters their name in a Sign Up form, and that name shows up, nearly instantly, on a separate part of the page. This gives your web application the feel of a desktop application, which can go a long way toward usability.
Performance
This is an important topic, but one that might be a little too detailed and analytical for this stage of the discussion. So I’m saving this for later. But, I do want to point out that Angular is fast. How fast is a matter of interpretation.
TypeScript
Angular, unlike a number of other popular frameworks, relies pretty heavily on TypeScript. If you work through almost any tutorial or quick start, even on angular.io, you’ll find it done in TypeScript, which is a typed superscript of JavaScript. That means it’s a higher-level language, with additional concepts, objects, and rules, but in the end it turns into plain old JavaScript. It does this through a concept called transpiling. Most people would think of it as compiling, and I guess technically TypeScript does ‘compile’ into JavaScript. Transpiling is a form of compiling, however, that means one language gets translated into another language with a similar level of abstraction (unlike C# into IL code, for you .NET people).
You can get more detail at typescriptlang.org but it helps newbies to know three things about TS.
First, for those of you coming from more structured languages, JavaScript can look scary and unorganized (don’t deny it, you know it’s true). TypeScript can act as a ‘middle ground’ for entry into JS, allowing devs to get the benefits of JS without having to figure out its eccentricities from scratch.
Secondly, TypeScript provides concepts that are eminently familiar to most OO developers, but that don’t exist in JavaScript. Example number one – classes. JS has something called prototypes, which aren’t exactly classes, but they approximate some of their functionality. TypeScript allows devs to create classes in a manner they’re familiar with, and then compiles those classes into prototypes.
Which leads us to the third item… TypeScript turns into JavaScript. Whatever you do in TypeScript, it will turn into JS in the end, which means it will run in almost any modern browser. So you’re getting the benefits of JS and TS all at once.
Ready to Code?
Whew, that’s a lot of text, and we haven’t even reached the fun part. But I think it’s important to understand a few basic concepts before we dive into the meat of this language. Even if you don’t understand them, at least hearing the names beforehand should help when these concepts come up later in the series. And don’t fret, I’ll have part 2 up shortly. In that one, we’ll go through the Angular environment setup (pretty simple), understanding the project layout (also simple), and building our first app (I’ll do my best to keep it simple). In the meantime, let me throw out one last item.
Get yourself a good text editor. While most any will do, I think the best one out there for Angular development is Visual Studio Code. I can’t recommend that tool enough. It manages projects pretty well, has built in TypeScript intellisense, it includes source control, extensions, folder searches, and a terminal window, and, of course, it’s FREE. You may have a tool you already prefer, but if not, I’d seriously look into VS Code as it will make following along with some of the examples easier.
Getting Help
If you need to find some help with quick starts, tutorials, architecture, or just learning the basics, the best advice I can give you is to go to the source for all things Angular:
That’s the website for Angular, and it’s full of documentation, examples, and tutorials. It’s not the only place I go to for help, but it is very comprehensive in its Angular education as long as you read through everything thoroughly. In addition, the regular sources will work as well, such as Stack Overflow, or tutorial sites like Udemy or Lynda. Or just regular Google searches will pull up a ton of material. But again, the point of this tutorial is to help you understand the language/platform well enough that you don’t have to learn it via a ton of random, sometimes unhelpful Google searches.
One thing to keep in mind, though, and this absolutely drives me crazy, is that there are two completely different types of Angular. The original version of Angular (v1.0) is called AngularJS. When you get stuck and you start Googling for answers on various Angular topics, you’ll inevitably find a ton of articles referring to AngularJS. IGNORE THESE! Starting with Angular 2, the entire platform changed pretty drastically, to the point that AngularJS concepts don’t really apply anymore. It’s kind of like in .NET where developers had to draw a line between versions 1.1 and 2.0 because of the sizable differences.
To counter this issue, when you do a Google search be sure to put -angularjs somewhere in the search field. This tells Google to remove articles referring to the old version. The current version, as of this writing, is 7, so I’d look for topics covering version 4 and above (there isn’t a version 3 if I remember correctly), although for some specific topics you’ll want to search for version 6 and above. Confusing, I know. Welcome to my world!
Recent Comments