September 13, 2018
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:
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.
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.
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.
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.
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.
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.
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.
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.
SF: There are five factors about Angular that keep people coming back.
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.
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.