!= Making Angular Great Again - Sessions by Pusher

Making Angular Great Again

Guy Nesher speaking at JS Monthly London in March, 2017
Great talks, fired to your inbox 👌
No junk, no spam, just great talks. Unsubscribe any time.

About this talk

AngularJS is 6 years old and is still widely used to build modern single page applications. With Angular 4 entering Beta it's time to talk about what went wrong and how we can make Angular great again.


So, my name's Guy Nesher. I've been running this event for a while and now I'm leaving the country. And I thought that while leaving the country I might as well give my last farewell gift which is to convince you not to use Angular 2. I'm going to be a little mean. I'm going to try not to make it into a 30 minute rant and actually give reasons why I've been disappointed with Angular 2 so far. If you have questions, feel free to ask them. This is going to be free form. Okay so, a short preface. These are just my opinions. I'm sure some people are using Angular 2 and are loving it. I'm not saying Angular 2 is inherently bad, I'm just saying my experience wasn't good and that Angular 2 did not meet my expectations. I hold Google developers in high regard. They have some of the smartest developers I've ever met. And I'm using quite a few of their products. So yes, maybe if this wasn't Google but a small start up from London, I wouldn't be this harsh. But they're not, they're one of the biggest tech companies in the world. I'm not going to talk to you about bugs, because yes Angular 2 and now 4 have bugs but I'm a developer, we all build apps, we all created bugs. As long as we try...except the guy there, he didn't create bugs. But I'm not going to complain to anyone about trying to make a good program and kind of have a few bugs sneaking in. So these are bigger issues in my opinion. And finally, I love Angular. I'm giving this talk because I genuinely enjoyed using Angular 1 when it first came out and I genuinely had a lot of high expectations for Angular 2 and believe it can be a very valuable addition to the single page application market. If the Angular development team just did a few things a little differently. And let's start to talk about that. So, table of contents, we're going to talk a little bit about how Angular came to be. And then we're going to talk about three things that annoyed me about Angular 2 and why I think they should annoy you. There are plenty other things but some of them are quite specific to Angular 2 and how you write applications with that. And I just didn't think they would pass well in a 30 minute talk, but there's plenty of things to discuss in those three subjects. And then we're going to talk a little bit about where I think we can go from here because just telling you that Angular 2's bad is not really helping anyone. So let's start with just a little bit of history on Angular. So Angular 1 was released in 2011. It's been in existence for about six years now. Which is forever in JavaScript terms. It was one of the first single page frameworks that actually offered a full solution. Back then, back when JS was a very popular alternative. Back when JS was I think, about 8,000 or 10,000 lines of code. You could just read the entire library in a day or two and kind of know it. Whereas Angular presented something much more substantial, it had two-way data binding which was the best thing in the web at the time. We hate it these days, but who knew? It has more than 50,000 stars on GitHub. It's one of the biggest frameworks still being used for creating single page applications. And yes, by the end it started to get a little rough around the edges because again, six years in JavaScript world is quite a lot. I found this online. It really amused me but I'm being a little unfair. Between Angular 1 and Angular 2 announcement around 3 or 4 years and even then we had about 2 years from 2014 when the change was announced until Angular 2 was actually released. This was happening because a lot of the code decisions behind Angular 1 just proved to be not so great. Not because Angular 1 wasn't created well, but because things change drastically on the web over time. The big surprise everyone got was that Angular 2 was not going to be backward compatible which left us with a two year gap of uncertainty. And I think even six months ago I was talking to companies that said that they're struggling to start new applications with Angular 1 because the developers were refusing to start working on the new applications with Angular 1 because Angular 2's coming out any minute and no one wants to be stuck with using old technology in JavaScript on the web. So, after about two years of a lot of anger, we finally got Angular 2. And it was released about six months ago, maybe a little more than that. It was moderner and it was faster. It's not the fastest framework out there, I think Angular never was. But it is definitely faster and better behaved than Angular 1. They've decided to move to a six month release cycle, which is a little frightening because that means that every six months we may get breaking changes but it also formalizes how changes happen in Angular which didn't quite happen before. And yes, but while having this talk, Angular 4 has already been released last Friday. But this is not why we're here. We're here to discuss three specific challenges that made me quite unhappy with moving to Angular 2 and why I think Angular 2 began it's life and actually ended it's life still being in beta. And the first part would be missing practices. So when Angular 1 came out we got a lot of options to make our lives really miserable. If you've used Angular 1 before, you may remember that putting a lot of variables on roots code and sharing them around components seemed like a really great idea somewhere in 2011. And somewhere in 2011 we also realized that it's actually unusable and stopped using it. Angular 2 kind of decided that we didn't learn the lesson and gave us a lot of new ways to write bad code without actually helping us or directing us. Now, Typescript is one of these things that can do a lot of good. I've got nothing bad to say about Typescript, really. At the same time, most of us have not used Typescript before. Typescript was not a big complaint from the Angular 1 community and you could suddenly build Angular 2 without Typescript with minor modifications. The reason why this is all a problem is that while Google team, the Angular development team decided that Typescript will allow us to make better applications, they have made no attempt to tell us how to properly use Typescript. And while it's really easy to copy and past code from the internet, you will notice that half that code's just badly written Typescript. And without anyone actually directing us, you just get a lot of badly written programs six months after the initial release of Angular 2. The Angular team does not seem to be interested in taking part of educating the community and it kind of leaves a gap where in the year's time we'll be really sorry about what we've written so far. But this isn't really a big problem. Let's talk about RXJS. RXJS is a library for reactive programming which is the cool new thing online. It's not that new but we just adopted it. Much like Typescript, it's not technically needed in order to build any local apps but the Angular 2 team seemed to think that it's hip and new, and therefore we need to use it. Unlike the Typescript documentation, the RXJS documentation is quite bad. So if you think you can just go to the RXJS website and know how to use it, you're going to be disappointed. And it effects how we manage state in Angular 2. Now managing state is one of the harder things in building an app and it's where most of the pains in Angular 1 came. Creating a new way to manage state in Angular 2 without telling us how to do that is a little odd for me, because again, we know what's going to happen in a year. We'll have a lot of unusable code because we experimented. Now, I did what a reasonable developer does and I reached out to a group of people called the Google experts. The Google experts are volunteers that were vetted by Google about specific subjects, in this case the Angular platform. And I asked them something very simple. What's the recommended best practices of using the active programming within the data layer of Angular? And the general answer was that they don't know. Now there's two things that that can mean. One thing is that maybe at least the Angular experts that I've talked to have decided not to use Angular 2, which is a fairly big problem but not related to RXJS. I'll leave that to the Angular team to discuss. The other option is that actually the new state with RXJS is considerably more complicated. And the Google team does actually need to weigh in and give at least some direction. Just to give an example, in the company I'm currently working at we have about four teams using Angular 2. The decision was generally that each team will use their own RXJS implementation to see how well we can do that and then after a few months see what works best and use it across the company. After roughly four months I'm happy to say that we decided to use an external library called NGRX because none of our options were really very good. It might be because we are not great developers but possibly because there's a challenge that needs to be solved there. But you know what, that's not it. Let's talk about the community support because all of these questions are rising now because it's new and there's a lot of gap in the market. And this is the point where you reach out and talk to Google and ask questions. And one of the people in the Angular 2 chat told me, "Listen, this isn't really open source, this is Google. Which brings me to the following example. Which is, this is from the Angular 2 GitHub. One of the... I think it was the library and developer, found out that the library he developed for and he looked to stopped working and the Angular 2 core team says, "Actually if you don't follow our clear directions, it's not going to work. Which was a fair question, which was followed by a very obvious question. It was upvoted like 30 times, and this is back in December. We are still waiting for the clear instructions that were promised in the GitHub bug tracker. To be fair, at some point one of the non-Google employees shared a third-party blog post that made some suggestions. But the fact is that six months after the release of Angular 2 we do not have the best practices of how to develop an Angular 2 library by Google even though they kind of suggested that it exists somewhere. The problem is that again, a lot of the third-party tools out there are going to be broken. Not because we're not smart or not trying but because Google's not really engaging enough in the community and giving us the tools to actually build proper web applications on top of Angular 2. But you know what, I'm being a little unfair to Google. These are all external things, but let's talk about something more interesting, the Angular CLI. The Angular CLI is the recommended [inaudible] for Angular. You can see examples of using the Angular CLI within the Angular 2 documentation. And it's the best solution for something called AoT or Ahead of Time Compilations. We'll discuss that in a bit. Now, the one thing that the Angular team forgot to say when they announced that Angular 2's out of beta and wrote these documentations is that the Angular CLI tool is very much still in beta. So, for the first four months of the Angular 2 release, the building tool for the product kind of broke, because it's beta. So breaking changes are completely accepted. There was a whole conversation on GitHub I wanted to share but I couldn't find, about a developer who had an app in production using Angular 2 and he came on Monday and realized that he can't actually push changes because the Angular CLI broke, and was not going to be released in the next couple of days and he's like, "Okay I need to go back to my manager and tell him that we can't update the app because the Angular CLI broke." He doesn't know what the Angular CLI...he does know that Angular's production ready. I'm not sure what to tell him. And the thing is that, throughout the life cycle of Angular 2, the Angular CLI was not production ready. In around February they moved into release candidate and the biggest change for Angular 4 is that the Angular CLI now actually mostly works. Which kind of moves to the next point, which is Ahead Of Time Compilation. Now, one of the biggest advantages between Angular 1 and Angular 2 is the move to a whole new templating engine, that allows the Angular 2 to process templates and compile much faster. You can run Angular 2 in two modes. Just In Time, which means that you don't compile the templates ahead of time and just compile them as you wrote the app. This is perfect for development. And then you have the Ahead of Time Compilation which is a process that Google recommends before you release an application to the market. To give an example, we have a mid-size Cordova. A mobile application using Angular 2. We have about 150 templates, most of them very small. Without using Ahead Of Time Compilation we add about four or five seconds to the load time. Which is unacceptable to us, but maybe acceptable to the Google team. I'm saying this because there were a few things Google forgot to mention about Ahead Of Time Compilation. There's a few common design patterns that you can't use with Ahead Of Time Compilation. They will run absolutely fine when you use the Just In Time Compilation development mode but we break later. This is the list, so a few. But you know what, at least we can see what works and what doesn't. It's annoying that doing development we don't get these errors caught, but at least we know. Second thing they forgot to tell us is that actually, when they said using Ahead Of Time Compilation reduces the size of an Angular app, that's only true if you have few templates. If you have a big app, since the compiled templates take more space than the uncompiled templates you get to a point where your Ahead Of Time Compilation enabled application can take quite a lot of space. Now in the demo, the Angular team did a Hello, World app without any of your code really, 2.5 megs, so this is an acceptable size apparently for some applications. But that's not all. So the list you saw, that's not an official list by the Angular team, because the Angular team has not technically acknowledged the fact that Ahead of Time Compilation doesn't support certain coding practices. Six months in, after the release of Angular 2, with the release of Angular 4, if you go to the official documents of Angular you see no mention to the fact that if you write certain things, it'll work in development but not work in production. Now this isn't my text really, this is from the Rangle.io documentation. Rangle.io is one of the big companies that helps you build Angular apps. This has been online for the last couple of months to the best of my knowledge. I've not been able to see any direct comments from the Angular team about this. Now, I completely understand that with the release of Angular 4 and time tables being tight, and the fact that they have other things on their mind, maybe making the compiled list of what you can and can't do wasn't going to happen. A link at the beginning of the documentation saying, "Hey guys, actually there's a few limitations check that list, would have helped." Or at least the acknowledgement, a warning that there might be some problems. After six months of the app being live, to me is unacceptable. Now let's try to see what this all means. And this is kind of made up math, it's not completely made up but it shows what I think is a reasonable assumption on cost for community when one of the biggest frameworks out there doesn't care. So the Angular 2 depository has more then 22,000 stars. Let's divide it by half because a lot of these people don't really build anything concrete. And let's say that since we didn't know that the Angular CLI was working and since AoT didn't quite work as expected because there's no documentation on that. We lose a week or $2000 for a developer. $2000 for a week of developer time is really not a lot. That's 20 million in the past six months. In a purely theoretical math guesswork type thing. Now, let's say I'm being very optimistic. There's not actually 10,000 projects out there, there's only 5,000 projects. That's still 10 million and that's the amount of cost that the community's actually paying because the Google team, the Angular team, couldn't add a comment saying, actually guys there's a problem with AoT, please check this before making a decision whether you want to use Angular 2 or not. Because they couldn't tell us, or decided not to tell us that the Angular CLI which is fairly critical for building apps with Angular is actually still in beta. Now I'm not... I don't think that my expectation here are unreasonable and I think that the cost for the Angular team to actually do this is probably much, much lower than the cost we as a community are paying for these missing descriptions, I guess. In the last eight minutes I'm going to try and talk about where I think we can go from here with three basic assumptions that I think we need to kind of accept. So JavaScript kind of embraced open source and we're in a scenario where we have tons of alternative open source projects, but very few of any paid solutions. It's great, but it means that we can't move forward without saying that even though this is an open source project, and even though that maybe you don't have to share it with us, we do have certain expectations for what an open source project is giving to the community. Especially when this is one of the biggest companies in the world. Especially when this is one of the most widely used frameworks in the world. The second thing is that JavaScript applications are only getting more complicated. And if we can't rely on the framework, on the documentation this isn't going to go well for us. Because if I write that code and my app doesn't work, I should write better code, I maybe should start writing unit tests. Using Typescript's good. But if my app fails because I can't trust the framework I'm using, then the future of JavaScript single page applications is difficult, in my opinion. The last thing is that, I'm so sorry but, Google is perceived as the responsible adult here. If I go to a new company and tell them, "Listen, there's a whole bunch of really nice new framework out there, or libraries out there to create single page applications," Vue.js is amazing. It's faster than Angular. It's faster than React. It's been growing in a crazy speed. They tell me that they don't know Vue.js. They don't know who manages Vue.js but Angular's been around for five years, six years. And Angular's being managed by Google, so let's use Google and we need to either accept this perception and force Google to act accordingly or take it upon ourselves to tell our companies that actually Google's not doing the job we think they do, which moves me to the last part of the presentation which is the call for action. Angular 4 was just released. A lot of the technical problems that I mentioned were solved. So the Angular CLI is now officially production ready. I don't think the problem was that the Angular CLI wasn't production ready. I think the problem was the Angular team didn't actually tell us that the CLI's not production ready. And didn't warn us that we're going to dig a small hole for ourselves. So I think it's great that Angular's solved these technical problems but if we accept that and move on we're going to see the repeated problems happening in Angular 5, and Angular 6, and Angular 7. The second problem is that I would expect more ownership from the Angular team. So I cannot accept a developer who knows for six months that there are significant limitations in the application he's giving me without him updating the documentations. This isn't... I'm sure they had their deadline, I'm sure they had their own set of priorities but somewhere in an open source community I expect the developers to be open about what they're offering us. As an aside, the Angular team did take the time to announce that they're moving to a new semver versioning. So it wasn't Angular 3, it was Angular 4 because this was something that the community wanted. I'm going to say that maybe if something with the priorities is a little off if the priorities to talk to the community about semver before talking about the fact that we might not be able to compile Angular 2 in certain conditions. It's kind of [inaudible], I mean, I talked with the Angular 2 team. Not officially through the chat, and I don't have any responses from them but the fact is that they don't see this as a problem. They really believe that they're giving us a platform as is and if we use it and cause damage to ourselves then it's not their fault. It's not their problem and I think that needs to stop. I think that we need to tell them that if we can't trust the documentation we get from Angular, if we can't trust the Angular team to tell us if there's problems with Angular then we can't continue to use Angular. They're quite active, everywhere really, but it's really easy to get a hold of them through Gitter. I highly recommend going and expressing your concerns there. I would advise your superiors because, let's be honest, a lot of the decision makers assume that Google's safe, that Angular is safe, and if it's not the case and I don't think it is, then we need to level the playing field. Because that will allow a lot of other frameworks out there to be adopted and developed, and a lot of them do a better job than Angular in addressing community needs. The Dojo guy, as an example, gave Dojo an excellent foundation that supports Dojo, so Dojo no longer is centralized around a single company but there's actually organization that does that. And the last thing is just track your cost. See how much it's cost you to use a free software like Angular 2 and realize that maybe it's time for us to pay. Because I mean, if in the last six month, half of my estimate was correct and 10 million was thrown away because of bad community support, bad documentation. Then maybe we as a community can pay 10 million and get the framework we want, and need, and deserve. And not the framework that Google wants, needs, and deserves. That's it for me. If you have questions, I'm very happy to answer. Yeah, we'll start with that. - [Man] Which formula do you recommend? React or Angular? - Oh, so I'm moving to a company that uses Angular 1. Angular 1's absolutely fine. There's things with Angular 1 that are outdated and I don't like but, it's rock solid and it's working. React's lovely. I would recommend it as well. - [Woman] How similar is Angular 4 to Angular 2? - Very. So I would say that in many ways Angular 4 is what Angular 2 should've been six months ago. They've added very few new features. It's mostly just improving on Angular 2. You should be able to drop it in as a replacement and just work. Since it was released on Friday I didn't have the time to test it. Pub, I'm sorry.