Migration vCurrent to vNext


maybe it’s too early to ask that kind of question but as in our company we use Aurelia in 4+ applications, where each application has more than 400 elements, I wanted to check what kind of migration we’ll have to do when upgrading to vNext - or how much work it will be …

I downloaded the webpack-ts example from the aurelia-vnext repo and tried to create an additional element like I used to do it in vCurrent:

  1. created a new class and added the @autoinject decorator => there is no autoinject. Is this decorator gone?

  2. removed @autoinject and added @customElement, like it’s done in app.ts. Than added a require tag to app.html. Run “npm run watch”, browser opened the page and my element is ignored. Will the require tag not work anymore in vNext?

Although vNext is still in pre-alpha it would be great if someone could create a small example using two elements and some kind of service using as less code a necessary (I like convention over configuration) :slight_smile: With the current example I’m a little bit lost.

Btw I really like the way of creating views and view-models in the current version. Most of the time I only needed the two things mentioned above (@autoinject and require-tag).

Thanks for your help and great work!
Best regards!


Hi @stefan, appreciate you trying things out and providing feedback :slight_smile:

It is never too early to ask questions. It is a little too early to start trying to migrate vCurrent apps, however. To address your concerns:

  1. This is temporary. We do not have @autoinject in vNext at the moment because of uncertainties around the decorator specs, which is causing the TypeScript team to delay a feature that we would like to utilize for a new (cleaner) type registration API for DI.
    Since TypeScript is waiting for the spec to mature, we are too. At least, to the extent where it does not unnecessarily delay a vNext beta. We are simply deferring this feature to the last possible moment in the hopes to avoid having to re-do the whole thing.
    Furthermore, @autoinject would only apply in JIT scenario. In AOT you would not need a decorator at all.
  2. The <require> tag is also simply not yet implemented. For JIT this would be handled by requirejs and a template pre-parser, for AOT this would be statically analyzed and registered in a more runtime-efficient manner beforehand.

So @autoinject and <require> (and most other core APIs) not going anywhere. You definitely do not have to worry about breaking changes of that magnitude. It’s just that some things which are runtime features in vCurrent are going to live in a different piece of the infrastructure in vNext.

As for the conventions, they are staying the same and there will be cleaner alternatives as well. There’s a good chance that you’ll find yourself mostly deleting unnecessary boilerplate when migrating to vNext and not so much changing stuff. vNext will be smarter in many ways.

In the case of JIT (when you dynamically want to load resources during runtime) the conventions are probably going to move to loader plugins such as requirejs. For AOT, well, AOT will statically analyze the application and make the appropriate modifications in order to completely remove the need for such loader plugins (to keep the runtime bundle smaller and faster).

Regarding examples, we are still very heavily focused on working on the core and therefore haven’t been able to spend much time on examples yet. We will, though, when we feel things are starting to get ready for experimenting by early adopters :slight_smile:

If you would like and if your employer allows this, some code samples would be very welcome though. I am always on the outlook for kitchen sink repositories to find out how the community is using vCurrent so we can focus our efforts on eliminating breaking changes for parts where we know the community uses them. It wouldn’t be feasible to do this for the entire API surface of vCurrent, and I’m sure this wouldn’t be necessary either (I doubt every nook and cranny is being used).
So the more information we have on how the community uses vCurrent, the easier we can make the migration path.

Of course feel free to keep reaching out if you have any other questions :slight_smile:

Thank you!


Hi @fkleuver,

thank you very much for your detailed answer! I really appreciate you take the time to do this because I see you doing a lot of coding in vNext :clap: :clap:

Sure, I would be happy to help you by providing kitchen sink code. Is there a paper or something where I can read what and how you want it?

We made an element supporting the DevExtreme toolset in a way DevExpress did in AngularV1 (as I prefer the way of putting the configuration in the viewModel, where I can reuse it, instead of increasing the view code). This element uses some features not that well documented in vCurrent (BindingEngine, TemplatingEngine, …). If I put this in a small example would this help you or is this to much, as it’s more than 10 lines of code?

Another question: you mentioned JIT and AOT in your answer. I know what these two abbreviation mean but what do they mean in case of Aurelia or to be more specific: what is the most important difference?

Oh, and one more: in the some tests in the git repo I saw some special “bindings?” like :disabled or @click. Will you introduce “magic” symbols like AngularV2+?

Thank you!


@stefan No problem! And thank you for following up :slight_smile:

There is no paper, it’s actually a very open-ended ask. What you are saying about DevExtreme / BindingEngine / TemplatingEngine is precisely the kind of thing that I’m looking for and would definitely be helpful. No such thing as “too much”! Just a standalone repository that succeeds at installing and running would be great. No need to spend much effort in trying to simplify it. Raw and even messy is completely fine :slight_smile:

About JIT vs AOT, in a nutshell:

You could certainly combine the two as well, using AOT to optimize the static parts of your apps to improve startup performance and still including JIT for doing some dynamic stuff at runtime. (speaking of startup performance, we’ve already clocked vNext as starting more than 5x faster than vCurrent in various cases with JIT, and AOT will speed this up even more)

  • “magic symbols”: not in a million years :slight_smile: Look, some people start to find the property.bind, property.trigger syntax to become a bit verbose over time, especially when there’s lots of them. And there have also been various requests to make it easier to implement custom syntax.
    So I introduced the @attributePattern decorator that allows you to specify your own custom “pattern” (comparable to registering a route) to allow people to define their own custom / shorthand syntax with a few lines of code if they want to. The :disabled and @click are shorthands employed by Vue which a lot of people seem to like, so we added those as an example for folks who are familiar with the syntax of other frameworks.

I’m not going to dig into the pattern syntax just yet as it might change, but to give you an idea, here is the full code to allow the template compiler to recognize those 2 shorthands:

// @foo - shorthand for 'foo.trigger'

@attributePattern({ pattern: '@PART', symbols: '@' })
export class AtPrefixedTriggerAttributePattern  {
  public ['@PART'](rawName: string, rawValue: string, parts: string[]): AttrSyntax {
    return new AttrSyntax(rawName, rawValue, parts[0], 'trigger');
// :foo- shorthand for 'foo.bind'
@attributePattern({ pattern: ':PART', symbols: ':' });
export class ColonPrefixedBindAttributePattern {
  public [':PART'](rawName: string, rawValue: string, parts: string[]): AttrSyntax {
    return new AttrSyntax(rawName, rawValue, parts[0], 'bind');
// in your app:

And done. You have now taught the template compiler how to recognize these two shorthands. One thing we are hoping to accomplish here is to improve interoperability with other frameworks as well. We already had this capability in vCurrent but I don’t think anyone in the community ever managed to utilize it. Now it’s only a few lines of code to let Aurelia parse Knockout or Angular bindings, and actually something end users might be able to utilize :slight_smile:

(fun fact: Aurelia’s own dot-separated syntax is also fully implemented with these decorators)


Hi @fkleuver,

wow, thanks for the explanation. When I read this I’m really happy we have choosen Aurelia instead of Angular about two years ago. In Aurelia almost everything works as you expect and you don’t have to deal with strange namings, strange syntax (like [/*#) and a lot of configuration.

I’ll prepare the repo and come back to you when it’s done.


That is great! And thank you for not adding Angular styled snytax. That’s one of the many things I dislike about Angular or any other framework for that matter. Aurelia has really done a GREAT JOB at keeping unobtrusive and I’m so glad @EisenbergEffect pushed for that in Aurelia. We now have 6 plus enterprise apps built with Aurelia and haven’t looked back since introducing it to our team 3 years ago.


@fkleuver here it is: https://github.com/stenet/au-dx

It covers some of the more interesting parts like templates, binding, … Hope that helps.


Btw that’s perfect. That means I can start using the unicode :clap: emoji instead of “.bind”? :smile:


That sounds pretty awful and awesome at the same time.

Here you go https://codesandbox.io/s/k2zly648pv

You may lose some friends if you use :clap: binding command instead of bind, just a warning.


I prefer :wink:

1 Like

I can’t seem to find those emoji :thinking:

So i got something close to it:

  <div textcontent👏="message">textcontent👏: ${message}</div>
  <div 👏textcontent="message">👏textcontent: ${message | up}</div>
  <div 🔎textcontent="message">🔎textcontent: ${message}</div>
  <div textcontent🔍="message">textcontent🔍: ${message}</div>
  <div textcontent🧙‍♂️="message">‍textcontent🧙‍♂️: ${message}</div>
  <div 🧙‍♂️textcontent="message">🧙‍♂️textcontent: ${message}</div>
  <input value.two-way="message" />

Still the same sandbox https://codesandbox.io/s/k2zly648pv

Its a proposed unicode symbol from the site I grabbed that from to stay on topic with the off-topic post :smiley: :rofl:

1 Like

haha :smile: well done :clap: :clap:
also i know that nobody will use it, at least you easily find bindings, delegates, … in code as these are more colorful :wink:

1 Like

I think a write up is in order on medium showcasing the simplicity of adapting other language syntax into the parser.

Article Title -> Vue Who? Angular What? - Aurelia Where? - Everywhere


@stefan Regarding your code for using DevExtreme controls with Aurelia, I’d like to use some of this. What is the licensing?

1 Like

Hi @scotru

please feel free to use whatever you want from my part. Probably it’s better to start with this repository https://github.com/stenet/au-dx-builder, as I’ve changed quite a lot and now it’s up to the developer to choose the syntax for every specific case:

<dx-text-box disabled.bind="disabled" value.two-way="textValue"></dx-text-box>


<dx widget-name="dxTextBox" widget-options.bind="textBoxOptions"></dx>

More info find in the readme.

In the repository you’ll find a metadata.json, copied from https://github.com/DevExpress/devextreme-angular/blob/master/metadata/NGMetaData.json. Using this json you can call npm run build-dx to rebuild all elements (all in src/elements/*).

1 Like

For a project that relies heavily on the enhance capabilities of Aurelia, can we also not ”worry about breaking changes of great magnitude”?

Would be great with some input on that.

1 Like

@deap82 The short answer is that you indeed don’t need to worry.

Enhance is mission critical in some applications that rely solely on it, and we’re fully aware of this. Also, due to the nature of these applications (often legacy and highly time-constrained), we realize it’s especially important to keep migration efforts here to an absolute minimum.

The main thing about enhance is that the html is compiled in-place, instead of being “eaten” by the template compiler. This allows the framework to play nicely with CMSes, legacy applications, etc, leaving existing structures and event handlers and such in place.

While it’s not yet implemented in v2 (as are several other important things), we definitely plan to do so. As far as I can tell even the API will stay largely the same.

That said, there is a lot of API surface in v1 and we are trying to reduce the api surface while providing more/better features with a smaller, more coherent set of APIs (even for low level stuff) that makes it easier to learn and master the framework.

Feedback from the community regarding which APIs are actively used will help us ease the migration path with a “compat” package that exposes some of v2’s API in a v1-compatible way. For us, it will mostly boil down to adding some extra classes and functions with the original method names mapped to the new APIs.