Get the Newsletter

Aurelia vNext

Posted by Rob Eisenberg on August 5, 2018

The codebase of today's Aurelia is approaching 4 years old. Much has changed in the industry since 2014, with advances in JavaScript, TypeScript, module loading, packaging, browsers, tooling, and much more. We've worked hard over the years to maintain full backwards compatibility and minimal-to-no breaking changes. We're one of the only frameworks that has managed to achieve this. Most other frameworks have several major breaking change releases every year. Aurelia's stability is something we know our community appreciates, and it's something we're very proud of. That said, it has been almost four years and the time has finally come to think about Aurelia's next major version.

Early this year we began experimenting with ideas for Aurelia vNext. We love and firmly believe in the unobtrusive and standards-based approaches of Aurelia, so we wanted to see if we could build a vNext of the framework with all the same conventions, templating and binding syntax, and core capabilities, but modernize the code to improve size, performance, stability and many other important characteristics.

We're happy to report that in Q2 we made such significant progress that we've transitioned our experimental work on vNext into the official Aurelia vNext monorepo .

Below are a few things you need to know about Aurelia vNext.

Still the Aurelia You Know and Love

As mentioned above, we love Aurelia's conventions, its binding and templating language, its embracing of standards, and its unobstrusive, focus-on-your-app-code nature. We're not changing any of that. What we are doing is reworking how those features are actually implemented under the hood. So, for example, you'll have the same @customElement decorator and name conventions, and the same .bind syntax, but the code enabling that to work will be different. With vNext we won't be able to ensure full backwards compatibility. This is a breaking change version. However, most "high-level" constructs, approaches and syntax will remain unchanged. Low-level and more advanced APIs will have more changes. APIs related to dynamic composition, such as the compose element, will also be changing (due to the fact that the underlying composition engine is changing in order to address some long-standing issues).

The Tech Stack and Architecture

After experiments with Aurelia UX, Aurelia Validation, and several other current Aurelia libraries, we've decided to write all of Aurelia vNext in TypeScript 3.0 . A modular, large-scale project like Aurelia greatly benefits from the compile-time verification and tooling provided by TypeScript. We've seen a ton of benefits of this on our plugins and it's been invaluable in our early work on Aurelia vNext. The result will be a more refined, less error prone, and easier to understand and navigate codebase. If you're not a TypeScript fan, don't worry! In the end, the packages will be shipped as standard EcmaScript and we're making sure that all of the APIs work great with the standards, just like they do with today's Aurelia. We won't accept any compromise in that area.

Another change we've made is to adopt a "monorepo" approach to source control. With today's Aurelia, each package is in a separate repo. This made it easy to independently version, release and deploy packages, but extremely difficult to accomplish tasks requiring cross-package work. This was not only difficult for our team, but made understanding where and how to contribute to Aurelia very confusing for our community. In the time since we first started work on Aurelia, new tooling has emerged to help with managing multi-package projects like ours. As a result, with vNext, every package can exist in one repository. Each package gets its own folder and we use Lerna 3.0 to manage, build, test, and publish across all packages. Contributors only need to do a single checkout and run a few basic commands to build Aurelia vNext in its entirety, run all the tests, and start contributing. We're excited about the productivity and community collaboration that this is going to open up for us.

The final important aspect we want to mention is how we're re-defining the packages that make up Aurelia. In our current version, we break the core framework apart by feature. However, in practice, all core features have always been used together. The feature package distinction ended up being an artificially-enforced divide, resulting in a number of problems: out of sync version numbers, compatibility resolution complexity, problems in tree-shaking, inability to easily drop debug code, etc. For vNext we're splitting the core framework more along deployment lines and less along feature lines. The new package organization more closely models modern language and runtime design. Here's an explanation of a few of the packages:

  • @aurelia/kernel - The Kernel is the lowest level part of Aurelia and contains core interfaces and types, the basic platform abstractions, and the dependency injection system.
  • @aurelia/runtime - The Runtime builds directly on top of the Kernel and provides the bare-metal runtime needed to execute an Aurelia application. This includes the binding engine, templating engine, component model, and application lifecycle management.
  • @aurelia/jit - The JIT (Just In Time) module is capable of parsing binding expressions and compiling view templates. You only need to deploy it if you don't use the AOT module.
  • @aurelia/aot - The AOT (Ahead Of Time) module leverages the parsers and compilers inside the JIT module to pre-build all templates and bindings, doing work as part of your build process rather than at runtime in the browser.
  • @aurelia/debug - The Debug module enables detailed error messages, richer stack trace information, and other debug-time instrumentation and tooling.

While all this is subject to change (see below for status and timelines), we feel this general approach is going to serve developers, businesses, and their customers better. Beyond the modules above, there will also be a number of optional plugins for routing, SVG, state, i18n, dialog, and more, just like we have today. We think these make sense to continue to ship as feature packages but the core framework itself can benefit from the modified approach we describe above.

Advantages

We've mentioned a few advantages of our vNext work above, but we wanted to take the opportunity to call them out in more detail here as well:

  • Increased Team Agility - As previously discussed, use of Lerna 3 and TypeScript 3 projects is going to make it super easy to develop across packages, do cross-package refactoring, perform simpler integration testing, and have pain-free publishing. The entire Aurelia Core team will be able to better maintain the code and assist our community by using the new setup and architecture.
  • Easier Community Contributions - With one repo, there will be no confusion on where to post issues or how to find the code in question. Anyone who wants to help fix a bug or add a new feature can checkout one repo, run a couple of simple commands, and be able to test their contributions against the full Aurelia framework and plugin set. Our new setup also has improved CI and code coverage reporting. We'll be adding additional automated code analysis and nightly builds in the near future as well.
  • Removal of Cruft - There are many parts of today's Aurelia which are no longer needed or which can be represented by simpler abstractions. We're removing all these bits, simplifying internals, and performing a major cleanup. This will result in code that is smaller, faster, easier to understand, and can more easily evolve to meet future needs.
  • Higher Quality, More Intuitive APIs - Over the last four years we've received a lot of feedback on Aurelia. While we've heard mostly great things about the base conventions and templating/binding language, it's clear that the low-level, imperative APIs for more advanced scenarios are not great. We can do much better. With Aurelia vNext we're committing ourselves to spending just as much time on the low-level APIs as we did on the high-level developer experience and conventions. The result will be a powerful set of advanced APIs that are easy enough to be used by beginners.
  • Improved Documentation - Using TypeScript will enable us to provide better baseline documentation of our APIs from the start. However, in addition to this, we're committed to providing detailed engineering documentation of the implementation details and the reasoning behind various decisions. With vNext, we expect to have a smaller API surface area, but with more power. The smaller API surface will enable us to provide more detailed API documentation and examples.
  • Smaller Framework - By removing unnecessary abstractions and cleaning up portions of the codebase that haven't aged as well, the core framework is being significantly reduced in size. Additionally, our new architecure, which allows developers to ship their apps without the JIT and Debug modules, and enables better tree-shaking, will result in even smaller bundle sizes. In the future, we believe we can make further advancements in our AOT compiler to produce customized builds that are even more streamlined.
  • Improved Performance - A smaller framework downloads faster and has less JavaScript for the browser to parse. This will result in faster load times on its own. However, this isn't the only change that's going to have a huge impact on performance. There are many small improvements in templating, binding, application and component lifecycles, etc. which are contributing to not only faster startup time but also faster render and repaint time.
  • More Power and Flexibility - We're removing older, leaky abstractions and focusing on creating solid advanced APIs. The end result is that we're going to open up more powerful possibilities for developers. Additionally, we're standardizing new ways to plug into the framework to extend it, define your own conventions, and use other industry technologies with less fuss (e.g. simpler Webpack integration, easier CSS Module support, etc)
  • Many Requested Fixes and Improvements - Over the years we've had a number of requests for new features and even the discovery of various design flaws that we just couldn't address in the current version of Aurelia. Our vNext implementation has already been incorporating a number of these ideas, including things like additional component lifecycle callbacks, more predictable lifecycles in complex scenarios, binding and task queuing that's easier to reason about, better/simpler dynamic composition APIs, easier imperative component creation, etc.

Status and Timeline

We've made great progress on vNext since we started with our experiments earlier this year. So far, we've got mostly feature-complete early implementations of the Kernel and Runtime, with solid progress happening on the JIT. There are many details that are likely to change, but we hope to be able to build simple JIT-based applications in the next couple of months, with an alpha-ish release of the JIT by the end of the calendar year. At that time, we'll likely advise that no one begin building real apps with the vNext framework, but we do hope it will be mature enough for early adopters and long-time Aurelia developers to take for a spin, begin providing feedback, and helping us build migration support.

At this time, it's too early to say when vNext will be production-ready. In fact, it's still a bit too early to contribute to the project (unless you want to read a ton of undocumented code, deal with frequent major changes, and are willing to systematically contribute on an almost daily basis). Due to its early, volatile nature, we're respectfully asking our community to refrain from creating issues or filing bugs on the vNext repo at this time. We're moving as quickly as we can to get something that you can play with. We'll be super clear in our announcements when we believe we're at a point where wider contributions will become productive.

Wrap Up

We're bubbling over with excitement about the great progress we've made on Aurelia vNext and the vision we have for its future. While we're changing many low-level details of Aurelia, the high-level experience will be the same. vNext has the same conventions, the same templating and binding language, the same view-model-based methodology for writing components, and it focuses on standards and unobtrusve approaches, just like today's Aurelia...but it's going to be smaller, faster, more stable and intuitive, more powerful and flexible, and better in every way.

We hope you'll star and follow the project and stay tuned for much more news in the coming months.