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!

50 Likes
3

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

5 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.

1 Like
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:

1 Like
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.

5 Likes
7

Thrilled to support this project and looking forward to 2.0 like the rest of us. SUCH a better 2.0 than angular ::shots fired::

7 Likes
8

There’s any estimation dates? I know that covid is people on vacation can be affection the progress, but I see aurelia 2 activity very low.

2 Likes
9

Well, we’ve got a few pretty awesome new features from @Sayan751 recently. For the activity question, my guess is at the moment, we are trying to get basic set of features on par & stable. I think for this design/foundation heavy type of work, it’s hard to be super active. And it’s not alpha yet, so … no user, pretty much everyone came to Discourse & Discord for question.

Maybe @jwx and @Sayan751 and @fkleuver have more to say. For me, I’m working & experimenting on a few new capabilities of the observation & binding systems.

4 Likes
10

I fully understand but is been hard to convince other people to use aurelia when they see so low activity in the project and around it. I know that angular and react have more money to spend on teams focusing on their frameworks. Even me, I’m bit losing hope, seems like fast.design is more important now then aurelia 2.0 for some people,

2 Likes
11

Well, if it’s someone day job, then I would think it better be more important. Though I share your feeling, can only try a bit harder to push things over the line. Also, the evolution of FAST has given some pretty good ideas in some areas we could improve v2 as well. Finger crossed we can materialise those ideas.

2 Likes
12

To quote the famous Blizzard saying “it’s done when it’s done” won’t really help but keep in mind exactly that extra time it took made great games. I hope you see the relation :wink:

Depending on how one determines activeness you’re right it lacks visibility but we’re close to alpha so all distractions are purposely pushed back.

I can only ask in the name of the team for a bit patience.

5 Likes
13

I think I am really patience. But referring to a quote from @fkleuver on may 22th.

The aim is to get au2 alpha released by the end of June.

After that quote I also read a lot of times that the alpha release is only a couple of weeks away or it is very close. No commits anymore on the master branch for two months is also not helpful.

When people have to make a decision right now for a front-end framework and have to convince their management it is not really helpful that there is no release planning at all for Aurelia 2.

5 Likes
14

I’m not even able to convince my work mates, main reason is small comunity. I’m my case I dont mind with low popularity, I just dont want to migrate a project from knockout to a frameworks that has aslo almost no progress.

2 Likes
15

Perhaps something should be made clear. This is going to be an alpha so by all means you shouldn’t go prod with a big project using it. Nothing stops you from using v1 and the port to v2 is going to be way easier then people might think.

6 Likes
16

Hi,

Out of curiosity: Is an alpha release in 2020 still likely to happen?

Cheers!

2 Likes
17

@arjendeblok

So sorry for delay, Actually there are some important things before releasing alpha.

No commits anymore on the master branch for two months is also not helpful.

Yes, but this does not mean inactivity. e.g. You can find one of the most important PR here

or

ready to review.

@nmocruz

I’m not even able to convince my work mates, main reason is small comunity.

What does a “small community” mean to your colleagues?

I am a little familiar with other frameworks like Angular, Vue , React let me show you an example, In Angular, they (The big community) are looking for containerless feature in 3 years and they got nothing!

image
image1282×372 30.7 KB

A bit hope from the creator of Angular. (22 days ago)

image
image960×254 21.5 KB

I want to say that whatever you use (Angular, Vue, React and …) there are problems, which one do you feel comfortable with? For me Aurelia.

Believe me, the project is in progress.
Anyway, We still apologize for the delay.

Out of curiosity: Is an alpha release in 2020 still likely to happen?

@CaptainPaella Sure!

But guys as @zewa666 said:

This is going to be an alpha so by all means you shouldn’t go prod with a big project using it.

There is no magic here sometimes to get the best result we should be patient and it’s always hard.

12 Likes
18

I guess the reason given about use Aurelia 1 is not right.

For one when a new version is about to release (even alpha :wink:) why start new project with old one and who will explain to bosses why they have to migrate again after few weeks or after couple of months.

Another reason, the Aurelia 2 seems so much awesome, so people want to use it right away.

I think for future version it would be best not to discuss it until its at least alpha level.

Thanks

1 Like
19

That’s a big problem in the community you’re tackling here. Larger projects require solid architectural understanding and part of that is knowing when you can reach out to experimental tech and when to stick to established tooling. I’ve seen various projects go nuts just because people followed trends.

There is a reason why things are called alpha, beta, rc and stable. If you’re about to start a new large project on an alpha of any framework you’re essentially a fan of russian roulette :slight_smile:

Just because something looks nice and fancy doesn’t mean you should jump board. That is also true for Aurelia v2. We’ve always tried to educate people to make conscious decisions about their framework choice. That includes ourselves as well

1 Like
20

I believe that low resources online, documentation, people blogging, doing tutorials, maintaining plugins etc. If you google about Aurelia, try find videos on youtube etc. you don’t find many, and seems like is decreasing the frequency to new contents about it, many people don’t even know about it.

But that not on our controller, I would like to see microsoft to stop pushing blazor all the time to do web applications, and just support aurelia, this fast.design framework is another time waste, 0.001% of people would need that and some day micrsoft will move way like they did with silverligth.

2 Likes