The Wind and the Waves: The formation of Framework Waves from the Epicenter

Our collective understanding of innovation is wrong. It may seem at first like problems are solved and innovations are introduced by a single point of light, a lone person having a eureka moment. However, we can see that for any major innovation, this is just not the case.

For instance, let's take the story of who invented the computer. It may at first seem linear, like a single event and a single implementation was the start. However, it was not one, but many steps forward. Maybe under certain definitions it was ENIAC, widely regarded as the first electronic, general purpose digital computer. There were other computers that had all these features, but the ENIAC had them all in one package. That said, it wasn't binary. Colossus was also regarded as the first programmable digital computer, although it was programmed by switches and plugs, not a stored program. Binary being pretty important, maybe you want to trace it back to Aiken's Mark I, which had binary principles, but wasn't electronic. Each storage location, set of switches, and registers were assigned a unique index number. These numbers were represented in binary on the control tape. However, the Z3 and Z4 were the first programmable computer. Atzinosoff and Berry designed the first digital electronic computer, the first time a computer was able to store information on its main memory, but none of those would have been possible without Turing's evolving theory, writing his uncomputable numbers, where he defines what we now know as a Turing machine. But also Claude Shannon laid the foundations of information theory. His theories laid the groundwork for all electronic communication networks, but also EDVAC, Manchester Baby, the Franzi Mark I, and IBM all brought new developments to bear, all of which influenced important pieces of what make up a computer.

But none of this would have been possible without Jacquard's Loom, which was a set of cards to produce a pattern in a weave in a cloth, way back. Or Babbage, who created two mechanical calculators, one was the Difference Engine, and the other was the Unfinished Analytical Machine. Or Edda Lovelace, who invented the concepts of modern computers, including software and subroutines. She thought about how computers could handle any subjects, not just numbers, and that data could be represented in digital form and published the first computer program. But then this really does depend on your definition of a computer, whether you mean modern computer or not, because what would computers be without the computer chip? Jack Kilby and Robert Noyce unveiled the integrated circuit known as the first computer chip. Or what about when the prototype of the modern computer was shown in a research center for augmented human intellect, including a mouse and a GUI? And really, what would modern computing be without the development of Ethernet, for connecting multiple computers and other hardware? As Matt Ridley says in How Innovation Works, the innovation of a computer can no longer be pinpointed into a single product than one can pinpoint the moment a child becomes an adult. For even one of these pieces, we can see that they're interconnected and not just on a linear time scale, but also connected by what spectrum of innovation it pushed forward the most. And thus, we see that innovation is a system, a series of interconnected frequencies. Innovation is connections. Innovation is a network.

Yet many talk about innovation as a light bulb turning on, on an aha moment that strikes only the most brilliant of creators. But even the light bulb was invented simultaneously by 21 different people in different parts of the world. Edison might've gotten that final patent over the line, but the innovation of the light bulb was slow, cumulative, and inevitable. Innovation is not a singular eureka moment.

So what does it take to make an entirely new and useful thing out of things that already exist? How do we create a seismic shift out of things that were here before? We often talk about the waves of JavaScript frameworks, that single moment in time where a framework hits massive relevance. But we don't talk about what makes up a wave. Waves are not created on their own. They're created by a force of nature, the wind. And so today, as we talk about innovation in the industry, we're going to talk about the wind and the waves.

I'm Sarah Drasner, and today we're going to talk about the formation of framework waves from the epicenter. So who am I to talk about this stuff anyway? Back in the day I was a React developer. I keynoted React Rally in 2016 among some other conferences, and then eventually found Vue and became enamored with it, eventually becoming a Vue core team member. In September of last year, I took a director of engineering job at Google, including but not limited to the JavaScript and TypeScript languages, web testing, including Karma, and a few frameworks, one of which is Angular. I don't personally run the Angular team. You can think of me more like Angular's grandma. And although I'm going to focus a lot on Angular today, know that what I'm telling you, know that I can tell you the same story from the perspective of focus of a number frameworks, as the point is that we all do learn from one another. However, what I think is unique and intriguing about Angular is how well it survived. It's shaped and influenced multiple JavaScript waves in ways that I think few fully realize. And in turn, learns and grows and is continuing to grow from those around it. So basically, when I see other frameworks thriving, I feel very happy for them, too.

Which leads me to, how did we all get here? And how did Angular play a part? In order to see where it's going, it's helpful to learn from the past and where we came from. But I'll warn you, this is a contentious area, and people might not always agree on some of these points. Remember how I said that innovation was more like a network or a system than a single aha moment? And remember how I said that Angular and others have stood the test of time? Well, none of these frameworks were made from thin air. The first versions of Angular and AngularJS was one of the most modern JS frameworks, and it drew inspiration from its predecessors, Rails and JQuery. Neither of which I'd really categorize as a modern JS framework, as we know today. From there, we have Ember, also in this first wave, drawing inspiration from Rails as well. Handlebars, which Yehuda Katz worked on previously. And AngularJS spa capabilities. Then we have Backbone, learning also from Angular, but also MVP approaches. And Knockout, which learned from Handlebars in jQuery, introducing important concepts, such as in computed properties.

In the second wave, we have React drawing from AngularJS, but dropping the M and the C from MVC and focusing on the view layer only. It was also inspired by Backbone. And Redux, heavily adopted at times for state management, drew inspiration from Elm.

The second version of Angular obviously drew inspiration from the first, but also learned from React. And Vue took inspiration from many sources, AngularJS for some template and authoring and binding, React for a Vue layer-only approach, Knockout for computed properties, and Elm and Redux for Vuex state management.

Svelte simplified a lot of what came before it, drawing from many modern framework concepts, but leaning more heavily into the compiler and simplifying some of the previous approaches mentioned with state stores. You'll notice that I haven't told you my bets for this third stage because I'm not a weatherman. I will note that meta frameworks such as Next and Next have become quite popular and note that Solid is doing some amazing and potentially industry shifting things. And lastly, I'll note again that it's impressive that Angular has lasted multiple waves.

I mentioned that Angular influenced a lot and it might be hard to see as stands of time tend to wash these things away. Angular developed Spas, first class usage of TypeScript, test integration and harness, actually even today when you create a new component, you get all of this test infrastructure pre-built for you. Tree shaking, ahead of time compilation and first compile time built-in internationalization with zero runtime overhead and mature CLI driven updates. That last one is really impressive, especially as I run infrastructure team at scale, those updates being so seamless is really important.

That said, Angular does not sit or stay still or sit alone. One of those things that I've noticed in time is that I've spent with the Angular team is how humble and curious and eager to improve the team is. Angular is working on a ton of improvements right now and is currently inspired by Svelte's authoring simplicity, Vue's approach to SFCs, Svelte's stores and simplified state management, Solid's reactivity, React's unidirectional data flow, Vue's animations, and Aurora, as seen, you know, Aurora is in the Chrome team, they worked with Next.js on an image component. We are also subsequently working with them as well. So, you may have noticed that improvements to Angular's external feature set has halted over the last few years, calling into question by many, has Angular stalled? Well, the team has had to pause on some of those features due to Ivy. You may or may not have heard what Angular has been working on for many years, Ivy was a massive ground-up rewrite of Angular's renderer. Ivy was our exploration of how to build a framework that can evolve over time, shipped in the last year. You can liken this update to what many of you React OGs will recall, an update called React Fiber many years ago. The team worked on changes to the RIG reconciliation algorithm under the hood. And recently Vue did an upgrade of the internals as well called Vue 3, rewritten in TypeScript and a complete rewrite of the reactivity system. What do all these under-the-hood rewrites have in common? Well, they have massive gains but a slight trade-off that some other work on the framework can slow for a time. However, Ivy brought with it a bunch of great improvements. For instance, we've seen an improved codebase organization, since tech debt has decreased and the code base is more organized, which makes it much easier to do more improvements coming up. Angular language service has allowed for better integration with IDEs, like VS code, and improved syntax highlighting and more informative tool tips. We've seen significant speed improvements as well as bundle optimizations and stricter checks to test, as well as improved compilation errors. Here is an example of that last one. Let's say you add a component without fully registering it and there's now more CLI information about what is missing and where so that you can spend less time debugging and more time being productive. Now that these updates are done and Angular is evolving, that brings us to today. We're focusing on two major themes, advanced features and simplifying development.

So, and in that advanced feature set, today we're going to talk about strictly type forms, advanced styles, resource inlining, updates and error handling and streamlining page title accessibility. First, let's talk about strictly type forms. One of Angular's nice features is built in form validation. You can see here how easily I write and build in reactive form validation in only a few lines of code with no external library or setup. In previous versions of Angular, even as I wrote this validation, the type was cast to any. This is a shame given the strength of typescript to do this kind of evaluation. So in previous versions in Angular V13, you can see that that form state is any.

You can see how many people have asked for this. We've got almost 1,000 thumbs up in this issue in the repo. Oh, no. But have no fear. We just added a feature that is both something that should be improved and something that's way ahead. Angular already has form validation baked in and now we leverage our usage of typescript for strongly typed forms and validations as well. It's Angular's most requested feature, now shipped in V14. To see it in use, we now get great insights and type checking in our forms, making the debugging and developer experience much more powerful, without having to add any external libraries or interrupt with typescript.

Great. Let's talk about some of the advanced features that Angular has for styles and resources like components. So, one great new feature is that you can now add inline Sass styles without a ton of config. For instance, just dropping this into a component. It offers sophisticated effects like this with just a few lines of Sass mixins directly inline.

Or we now have built-in Tailwind config. You can add a Tailwind config file that will register in the application allowing for seamless integration with Tailwind's libraries. Which brings us to another feature that's great for performance resource inlining. Say we want to add a style sheet to our application. We can do so, but notice this is render blocking, causing users to wait for everything to load. Similarly for fonts, we're downloading the font family every time we serve this request. But with this simple addition to our AngularJSON, we can now see critical fonts inlined in a style tag and our style sheets have been updated to load asynchronously.

Awesome. I already mentioned that Angular has been ahead of its time in terms of updates and migration, but ng-update and ng-schematics have been worked on to provide even more detail and useful information. Some of this is due to the fact that Angular runs at scale, and for such projects such as Google Cloud, Angular has some of the most sophisticated upgrade functionality in the industry. Within Google, we do what we call LSCs, or large scale changes, and we use ng-update to transform the codebase seamlessly providing sophisticated logs and error reporting along the way. That means that Angular can continuously improve over time with smaller risk to its users. We learned about breakage the hard way. And codebases aren't littered with many different ways to do things and write components, which is often the case when upgrades happen in large code bases, where people don't have time to update every single component. And everything still is backwards compatible. ng-update plugs into the same AST that we use for TypeScript. And we've now added enhanced template diagnostics, which give great error detection, especially for common errors that could potentially be difficult to debug for people first working with the framework. Here we see a binding error that we affectionately call banana in a box. Because banana is delicious and arguably the funniest fruit. Other better error messages include nullish coalescing errors and tree shakable error messages. We now have new runtime error codes. These error codes make finding references on how to resolve the errors that you might encounter. This includes, this allows the build optimizer to also tree shake error messages from production bundles. Angular CLI now offers auto-complete functionality as well, which keeps developers in the flow of their tasks more readily. And another really important feature is streamlining page title accessibility.

This is important in SPA approaches because, without intention here, the title of each page would remain the same, which is the first thing a screen reader reads upon root change. So as of v13.2, Angular router now offers a streamlined new title property that helps people using assistive technology understand the content title and purpose of the page. You can also create a more complex logic for dynamic and conditional page titles as well by extending the title strategy.

Okay, we've just talked about a bunch of different improvements and advancement. This brings us to our next subject, simplification of development. Angular v14 is just the tip of the iceberg in what we're taking on to make the developer experience much more seamless. In it, we're offering standalone components where devs no longer have to worry about writing and update NgModules. For those of you unfamiliar with Angular, you may ask what does that mean? Here's an example of a lazy loading component. Previously, in NgModule, we'd have written our imports and then we get to writing our routes and our routing configuration. Today, we remove a ton of that configuration. We just focus on our routes alone, writing our lazy loading component like so. Today, we have a number of these types of improvements rolling out, streamlining the developer experience and removing a ton of overhead for code that people need to write, learn, and build.

So that brings us to the future. After the Ivy completion this year has been an avalanche of these smaller quality of life features. These improvements are just the beginning. Next year, Angular is tackling larger developer experience gaps. So what I presented today is really just the tip of the iceberg and what's under development now are some larger strides forward with this framework that I can't wait for. Next year and the years to come are gonna be really exciting. Aside from that, the core team has grown which enables us to hammer on some outstanding issues and pay down technical debt that this humble and hardworking team is really proud of. Coming up you'll see a lot of really great improvements many of which as I mentioned before are inspired by the great work of others in the industry. An easier and simplified API including state management inspired by Vue and Svelte. Revamp of the reactivity system inspired by Solid and Svelte. Improved performance image components, script loading working with the Aurora team in Chrome addressing core web vitals. Better hydration and SSR inspired by so many people in the industry. Better stack traces, better accessibility more reusable headless ARIA primitives and the documentation revamp with new interactive onboarding and examples. Angular both pushes the web framework ecosystem forward and also learns from and is inspired by those around it. And this is how we all evolve. It's never in isolation it's by learning from each other.