Interview: Angular, the Successor of AngularJS, Is Thriving

AngularJS revolutionized how we build modern apps. In early July, AngularJS entered its long-term support phase, which means that the Google team will no longer be merging any new features or fixes that would require even a minor breaking change. Its successor, Angular, is now one of the most loved JavaScript frameworks and a standard for large-scale applications.

Two weeks ago, I had the privilege of talking to Stephen Fluin, Developer Advocate for Angular at Google. 

Stephen helps developers and organizations achieve success with Angular and strives to ensure that Angular is built in a way that helps people—it is part of his mission to understand the reality of software development by learning what it means to be a developer in the real world.He’s also a regular conference speaker and the go-to person when it comes to Angular (and a great guy to talk to!).

If I was to say what was the most important thing I learned from our convo and everyone else should keep in mind, it would be this:

Angular is not just a platform that cares about the experience of the ones building apps. Angular cares also about the experience of the end users and has a significant role in the development of the entire JavaScript ecosystem. 

Stephen shared with me a bunch of exciting insights on AngularJS entering LTS as well as Angular and its future. If you have a couple of minutes, dig in—I wholeheartedly recommend reading through the entire interview.

Karolina Gawron, Monterail: Do you remember the first time you ever heard about AngularJS?

Stephen Fluin, Developer Advocate for Angular, Google: It was quite a long time ago, probably in 2010 or 2011. I was writing in PHP that time, as well as .NET, Java, and those sorts of things. But there was bigger and bigger demand to build better user experiences so things like jQuery became really popular then. And then there was AngularJS. It had this magical thing that you could bind data so when you changed the data in one place, it automatically rendered it updated. The idea of binding your data and using one framework to keep all things in sync—it really hit me. I wanted to write more and more applications in this. Over the next two or three years, I wrote less and less backend code and more AngularJS.

KG: And how did you get from that point to becoming Developer Advocate for Angular?

SF: I’d say there are bunch of different pieces in this story. I watched Google I/O around 2010 or 2011. All those great products announcements and excitement were there and I really thought this is a cool thing and I wished I could go there instead of watching it online.

And I heard you could get a ticket if you were a Google Group Organizer. I took like a year to finally become one, so I got to go to Google I/O 2012. That was the year of Google Glass. They actually skydived onto the roof of the building. Generally, it was the most exciting conference I’ve ever been to.

The program kept growing and so did the number of Google group organizers. Pretty soon, only a subset of organizers could get a ticket to Google I/O.

Then I heard there’s another program—Google Developer Experts, where all the experts got their ticket. So I signed up to become an expert. To join you have to have different qualifications—know how to speak, how to communicate, and be a Google Web technology expert. As part of that, I ended up speaking a bunch of times about Angular, during ng-vegas for example.

And then a recruiter just asked me if I was interested in joining Google. I was leading developer relations for Trello back then, so I rejected the offer. Three months later they approached me again, so I asked what the role was. But they only said “It’s confidential, we can’t tell you,” so I had to go to the interview to find out. Secrets at Google sound like the coolest thing! It turned out to be this role in developer relations in the Angular Team. There was a fit, so I joined the team as Developer Advocate.

KG: What do you think was making developers (including you) and businesses choose AngularJS?

SF: That was the first time we were building the client-side experience using the Web. There was this idea of declarative templates, data binding, and all those things gave developers superpowers to do things they couldn’t do before. Or they were just too hard. Once you learned AngularJS, you got all those things automatically.

KG: And yet AngularJS is still entering its Long Term Support period. What’s the process of making such a huge decision look like? What were the reasons behind it?

SF: There were millions of AngularJS developers and millions of AngularJS apps. The cracks started showing. If you wrote an AngularJS app the wrong way and had thousands of things on the screen, it ended up getting very slow. The architecture was just not designed with this kind of large-scale usage in mind.

Another thing is that the Web has evolved and user expectations have shifted. Nowadays, users want more all the time and you have to meet those demands or you’re going to be left behind.

The Team realized that there wasn’t an easy path to make AngularJS what it needed to be. And that’s why Angular was born. We moved from, for example, a controller and template model into a more component-based model. We added a compilation step that solved whole categories of errors that people would make in AngularJS.

We had a lot of the tooling built on the modern Web standards, such as ES2015 classes, modules… Those sorts of things.

I often say that an Angular app on day one looks like a AngularJS app would after three months of writing code.

We also moved from a framework to a platform. AngularJS was a framework. It took the data you wanted to show and it showed the screen in the right way, moving properly. Angular does the same thing, but we broadened our scope. Therefore, the team also focused on how you get started or how you create a new application. What are the steps to build and ship this app? How should I render it on a server? How do I handle the SEO and performance?

So instead of focusing on a problem of rendering to the screen, we focus on the entire developer experience.

KG: If you were running an AngularJS-based app on your own right now, what would you do? 

If the app is just in maintenance mode and nobody’s working on it, it’s gonna keep working just fine. We’re not taking AngularJS away. Everything is still on npm, it’s mature and stable. If you’re just maintaining your app, not investing further in it, keep it on AngularJS.

If this is something you’re investing in, though, and you’re forward-looking, you want it to take advantage of Angular.

If you look at all the questions we get from AngularJS developers, 90% of them are solved by moving to Angular. Performance of large-scale applications, shipping accelerated mobile pages (AMP), progressive Web apps (PWAs), or server-side rendering… They are easy to achieve with Angular, but no one ever built those capabilities with AngularJS.

KG: How many people are working on Angular right now?

SF: The core team is about twenty or thirty people, depending on how you slice it. We’ve got a few people working on core Angular, a few people who work on tooling, like CLI (command-line interface). Some people work on Material, and a few of them work on Typescript for Google.

Then we have the community of millions. Not everyone is contributing directly to Angular, but they’re contributing indirectly in lots of ways. Tons of companies are doing education and delivering courses, building libraries, tools, and components. Consultancies are building apps with Angular, figuring out best practices. There are users who report bugs so we can fix them. Our community is huge. 

KG: What is the most exciting thing you’re working on right now?

SF: I think for a lot of developers there are two things: Angular Elements, and the other thing, which is kinda happening behind the scenes is Project Ivy.

Elements are an ability to ship an Angular component as a custom element. It can be bootstrapped by the browser even in a non-Angular context. So, for example, you can use an Angular component in a React application.

In Ivy, we’re rewriting the rendering pipeline in Angular to make it smaller and simpler. So this is going to happen in kinda backwards compatible way and at some point in the future we’re just gonna click the switch and everyone’s apps are gonna get smaller and better.

There are many other fun things going on. With Angular for Designers, we want to improve the collaboration between developers and designers, and make designers more effective. We’re working on Angular Console which is a GUI (graphical user interface) on top of our CLI which makes it easier for new devs to use Angular without have to dive into it—for example create a project, run a project, build a project… Those sorts of things. A discoverable, visual interface.

There’s one thing I am a big fan of: we’re trying to be more opinionated and explore this idea of how one should serve an Angular application. A lot of JS developers are good in developing applications, but they’re not great at serving them. There are many relatively straightforward best practices that everyone should be doing and not everyone is, like compressing your content. By doing that you can reduce the loading time of a page by half. It has nothing to do with Angular, but if Angular can be more opinionated and help developers who use it follow those best practices, then they’re gonna have a better experience for their users.

KG: What in your opinion makes developers and business owners choose Angular over any other framework or a JS library?

SF: There are five factors about Angular that keep people coming back.

• It’s opinionated—so we offer an integrated set of tools that solves the most common problem that developers have. They don’t take away any freedom and most developers use those tools, so when you onboard a new team member, they probably already know the things you use in your app. Because it’s cohesive and integrated, we’re able to help the entire ecosystem move forward together.
• It’s trustworthy—we set up very clear expectations in terms of when we’re going to release majors. So you always know what’s coming from the Angular team and you can plan around those things. We’ve got two plus years of good track record of saying what we’re gonna do and then doing it.
• It’s familiar—whether you’re coming from AngularJS or some backend technology like Java or PHP, Angular gives off a very application development feel to it. We’ve heard from educators that around a half of learners come from AngularJS and the other half from backend technologies.
• It’s focused on scale—at Google, we’ve got billions of users and lots of apps that are used, but also teams with hundreds of developers working on the same Angular app. So we think of how collaboration can be effective and how an application can scale also in terms of different roles: architects, developers, designers, and a bunch of other different people so they can be effective within a single app.
• It has a great ecosystem—we talked about the community that’s collaborating and we would not be successful if there were not hundreds of companies out there building on top of Angular, educating, and training developers. They give us momentum and are one of our biggest strengths.

KG: What future do you predict for the JavaScript world, and Angular in particular?

SF: I think more and more people are going to turn to Typescript. Angular uses Typescript and we adopted it wholeheartedly very early in our process, and the whole ecosystem seems to be moving in that direction. People like it and how it improves their effectiveness.

I think that people are gonna get better at making smaller JavaScript bundles so you just ship the smallest amount of JS you need for any given experience. This is a trend we see across the world.

I think there’s gonna be more compatibility by things like Web components. I’d say that in order for the JS and its ecosystem to evolve and continue to stay effective, it has to be better at server-side rendering. There are all those really common and relatively straightforward best practices that if you get them wrong, your JS app will end up worse to your end users. So I think we’re gonna see JavaScript developers getting better and better at serving their JavaScript.

KG: Our mission at Monterail is to deliver meaningful software. How would you interpret that?

SF: Meaningful software means something different to everyone. I think it can be, for example, when I’m building a healthcare startup and I need to show heart rate data to my users, so they can make better choices about their health. There’s even a medical device company where they use Angular as the platform for building the app integrated with their hardware device, so they can see patient data in real time inside the Angular application.

But even just making people more effective at their jobs is meaningful. One of the important things I see all the time is that companies, especially the big ones, forget that their employees are people too. They think that employee experience doesn’t matter and they have to use some tool, regardless of whether it’s good or bad. And it’s important to tell those people that it’s not true. If you focus on employees as users and user experience, you’ll have happier and more effective employees. We’re trying to support that by making Angular a great platform to build those sorts of apps. Where we care not just about the experience for people building those tools, but also the experience for people using them.