Roadmap for Aurelia 2 alpha

#1

Hello friends!

With the v2 alpha release in sight in a matter of weeks (more on that later), we would like to share a high-level roadmap with regards to the packages and features that are in-scope for the alpha release, as well as those that will be added later.

What does “alpha” mean?

For Aurelia 2, “alpha” refers to feature completeness, API stability and compatibility. Due to our huge investment in testing we are confident that there will be little to no bugs in the core framework that we don’t already know about.

These bugs that we know about, the documentation, the last pieces of the router and a few misc things are all that remain for an alpha release that we think you will experience as productive and pleasant to work with.

There are still some experimental APIs that need polishing, some packages need to be renamed, merged or split up, and we have a fair bit of cleaning up to do in the area of unnecessary exports.

We will use the alpha period to polish and stabilize our APIs as much as possible so that once there is a stable release, you won’t be confronted with any breaking changes for some time to come.

In concrete terms, as you upgrade from one version to the next while still in alpha, you might run into one of these situations:

  • An api is renamed, or moved from one npm package to another
  • The signature of an api changed (e.g. parameters are added or removed, or the return type changed)
  • Two or more APIs are consolidated into one, or one API is split up into two or more APIs
  • The side-effects produced by an API might change slightly

We will make sure to clearly inform you which APIs are particularly unstable, via both the documentation (at docs.aurelia.io) and the JSDoc comments (visible in the IDE via intellisense). This will allow you to make your own trade-offs.

As a rule of thumb, when something already existed in v1 it’s probably stable. While the newly added APIs in v2 are generally based on community requests as well as real-world needs of the core team, some of them will require more exposure to real-world usage to discover how they can be made more ergonomic.

The list below is neither completely exhaustive nor completely set in stone; it will evolve as we receive community feedback and progress towards a stable release.

So without further ado:

The roadmap

pre-v2.0.0-alpha

  • [x] @aurelia/metadata
    • [x] v1 features
    • [x] tslib & reflect-metadata compatible Reflect polyfill
  • [x] @aurelia/platform-browser
    • [x] v1 features
  • [x] @aurelia/platform-node
    • [x] v1 features
    • [x] node-specific scheduler optimizations
  • [x] @aurelia/di
    • [x] v1 features
    • [x] Injectable interfaces
    • [x] callback resolver
    • [x] Registration hoisting configuration
  • [x] @aurelia/logging (new DI-based concept)
    • [x] Customizable formatters
    • [x] Customizable sinks
  • [ ] @aurelia/events (was: event-aggregator)
    • [x] v1 features
    • [ ] EventEmitter-compatible api
  • [x] @aurelia/scheduler (was: task-queue)
    • [x] Queueing mechanisms
      • [x] queueMicrotask
      • [x] setTimeout
      • [x] requestAnimationFrame
      • [x] requestPostAnimationFrame
      • [x] idleCallback
    • [x] Async & cancellation
    • [x] Delaying & preempting
    • [x] Looping tasks (for manual animation, game loops, etc)
  • [ ] @aurelia/runtime / @aurelia/runtime-html
    • [ ] Custom Attributes
      • [x] v1 features
      • [ ] au-slot (was: replaceable)
      • [x] portal
      • [x] focus
      • [x] blur
    • [ ] Custom Elements
      • [x] au-compose (was: compose)
      • [ ] au-slot (was: emulated slot)
    • [x] Binding Behaviors
      • [x] v1 features
    • [x] Value Converters
      • [x] v1 features
      • [x] view
    • [x] Class Decorators
      • [x] v1 features*
      • [x] @view
      • [x] @bindingCommand
      • [x] @attributePattern
      • [x] @instructionRenderer
    • [x] Property Decorators
      • [x] v1 features*
    • [x] Local templates
    • [x] Await async bind & attach hooks
    • [x] Async hook cancellation
    • [x] Composition cancellation
    • [x] Proxy-based observation (auto computed, array index, array length)
    • [x] Bindings
      • [x] All v1 features
      • [x] class & style (bind to object)
    • [x] Tens of thousands of integration tests
  • [x] @aurelia/i18n
    • [x] v1 features
    • [x] improved APIs and binding integration
  • [x] @aurelia/validation
    • [x] v1 features
    • [x] model-based validation
    • [x] OOTB i18n support
    • [x] improved APIs and binding integration
  • [ ] @aurelia/fetch-client
    • [x] v1 features
    • [ ] v2 api consistency
  • [ ] @aurelia/router
    • [x] v1 features*
    • [x] Direct routing (routing without explicit configuration)
    • [x] dynamic mode, where conditionally and/or dynamically rendered viewports work seamlessly on the same navigation where they were created
    • [x] Sibling routes
    • [x] @route decorator
    • [ ] Tens of thousands of integration tests
    • [ ] And much, much more (additional details will follow)

*Some features will be completed over the course of alpha, and so they may be marked as complete but that only refers to the part that’s in-scope for alpha. The rest is specified below.

post-v2.0.0-alpha

  • IE11 compatibility
  • @aurelia/inspect (serialize arbitrary objects into a readable format, used by assert)
  • @aurelia/assert (a web-compatible port of node assert with some aurelia-specific helpers)
  • @aurelia/platform-webworker
  • @aurelia/platform-deno
  • @aurelia/di
    • Interceptors
  • @aurelia/runtime
    • Custom Attributes
      • show
      • switch
      • virtual-repeat
      • au-host, au-bind, au-transfer-bindings, au-transfer-attrs
    • Class Decorators
      • @processContent
    • Property Decorators
      • @observable
    • Suspense (already possible with if.bind, but this is about a more ergonomic api)
    • Time-slicing
    • createElement api
    • Destructuring in binding expressions
    • CustomElement as template controller
    • Dirty checking configurability (explicit disable/enable, override interval)
    • Surrogate behaviors on au-viewport / au-compose
    • @bindable type conversion
    • @bindable reflection
    • Improved handling for file observation, and toggle-like attributes
    • SSR integration
  • @aurelia/runtime-xml (nativescript)
  • @aurelia/runtime-json (interop layers)
  • @aurelia/runtime-tsx
  • @aurelia/dialog
  • @aurelia/store

Node packages

  • @aurelia/http-server (clean alternative to http-server with http2 push optimizations)
  • @aurelia/test-runner (more performant, easy-to-use alternative to karma for real browser tests)
  • @aurelia/bundler (to provide more performant, native modules compatible outputs)
  • @aurelia/compiler (build-time optimization for smaller and faster bundles with less framework code)

Why the hold-up?

That checkbox with “tens of thousands of integration tests” underneath the router is the main reason for the hold-up. As you may already know, the v2 router brings some amazing new productivity feats to the table. We’ve also made a promise that migrating from v1 to v2 should be a breeze for most people, and that v2 will be able to do whatever v1 can do (and more).

The combination of a fundamentally new way of routing with the ability to do things the “classic” way has led to some entirely new types of challenges.
We want to ship something of which we’re confident that it’s deterministic and predictable in even the most complex edge cases, and that it stays that way in the future when new features are added. So the past 2-3 months have revolved almost entirely around getting the router working (and tested!!) in every situation we can think of.
We’re not done with that yet, but the biggest challenges are behind us now and we’re very excited about what it has become: quite possibly the most powerful, flexible, robust and well-tested router in the front-end landscape.

In short, we don’t want to ship something when we’re not confident that it works (even if it’s alpha), but we also understand that people are counting on being able to start working with v2 relatively soon.
This is why we’ve moved a number of backlog items to be done post-alpha. In the case of core features, most will be added before we go beta, but some packages (such as the compiler) will likely come a bit later and have their own separate version.

What’s next?

Once we feel that the APIs are good enough to serve for a few years, we’ll move to v2.0.0-beta. At that point, there will be limited new features or breaking changes. We’ll focus on fixing any browser or platform-specific bugs (up until alpha we’re only running our tests in Chrome, FF and Node) and creating a IE11-compatible release.

When we’re confident that things work on all necessary browsers/platforms, we’ll move to v2.0.0-rc and focus almost exclusively on technical improvements (improve runtime perf, reduce memory usage) and documentation.

Finally, we’ll release as v2.0.0. We’re skipping v1.0.0 for the @aurelia/-prefixed packages just to reduce the potential for confusion with v1 <-> v2.

With that, I’d like to thank the community for their ongoing patience and support and the team for their commitment and relentless effort in building, promoting or otherwise helping to ensure the success of Aurelia!

39 Likes
#2
#3

Super exciting! Keep going guys, you are almost there!

4 Likes
#4

I’ve been using metadata/di for a node app, and it’s working great, still needs a few improvements, but can’t complain too much. Soon to production.

#5

Any chances to have it working on, say, StackBlitz? Recently I wanted to convince my team to use Aurelia for a new project. The fact I had to set up local project for a demo was a big point against :frowning:

#6

Aurelia 2 works on StackBlitz, CodeSandBox and anywhere else, you have no restriction.

Also you can use https://gist.dumber.app/ too. This is made by one of Aurelia core team member.

1 Like