ISO: Moon Shots

There will be a new router for Aurelia 2. So please, as @arnederuwe said, check out the various RFCs for it in the Aurelia 2 repo. And it’d also be great if you, and anyone else with more complex router scenarios, could join us on Discord for more direct communication.

4 Likes

Where are we with SSR by the way?

4 Likes

Also, on a related topic, where are we with NativeScript (6) plugability? (See [Request] Aurelia + Nativescript 5+)

3 Likes

we have been doing all our integration tests with JSDOM, bootstrapping/tearing an app up down easily, so it’s expected to be easy. Though I’d prefer to let either @fkleuver or @EisenbergEffect put some notes for this.

NS is the same, as the way we do it with PIXI, you can see a PIXI example in the vNext repo. NS is a natural fit for Aurelia, so once HTML story is done, it should be simple. Of course, any community member is welcomed to step up and accelerate the story, the core team would be more than happy to provide necessary help to make it happen earlier.

3 Likes

As @bigopon eluded, we run all our 50k+ tests in both the browser and in jsdom. The entirety of v2 is designed to be runnable in any JS environment. You can start a normal Aurelia app in NodeJS+JSDOM, render it in memory and send the response HTML to the client to get a static page. There’s not even a special package needed for SSR though we might add one for some syntactic sugar purposes. But it wouldn’t be a monkey patching thing like in v1.

We just need to implement the client-side enhance api to turn pre-rendered “dead” html “alive” again.

The v2 runtime is fully platform and environment-agnostic, so a nativescript renderer can be built on top of the runtime without any hacks or friction. But it does need to be implemented: someone with knowledge of NativeScript syntax would need to write the template compiler logic (traverse the markup tree, retrieve attributes etc, turn them into renderables).
With the compiler and rendering logic implemented, every core component and resource should work normally with NS the same way it would with HTML.

We have our hands full with other things though, so when it will be implemented all depends on demand and community help.

6 Likes

Thanks for the detailed status updates.
If I am to start building a Next / Nuxt equiv today, do you think it is:

  • too late (you guys already have started something like that in private), or
  • too soon (some key pieces are missing that are tricky for someone outside the core team to complement), or
  • just right (in which case, can you point me to some code examples of rendering in NodeJS)?
4 Likes

We haven’t started working on it seriously yet.

@erik.lieben has been experimenting with static html generator in azure function https://github.com/eriklieben/serverless-september-poc/blob/master/HttpTrigger/run.ts so that should give you at least an idea of how the moving parts would come together.

Whether it’s “too soon” or “just right” - only one way to find out, I think :slight_smile:

In principle it’s exactly the same code and APIs as you see in the regular examples, except you use the configuration from @aurelia/jit-html-jsdom instead of @aurelia/jit-html-browser.

1 Like

(I didn’t read this full thread) only the last post.

This is the blog post that belongs to the experiment https://dev.to/effectory/building-a-serverless-blog-site-on-azure-1phd. I still need to write a follow-up on the Aurelia parts, needed to rush this one out to make the deadline for the serverless september twitter action :slight_smile: Hope to be able to make time for that in the next few weeks.

For now I’ve just loaded the regular bundle (the one you get if you generate a new project) using dom.window.eval('bundle javascript code') (it’s at the bottom of the post) to also make the webpack plugins (that add code inside the bundle that only works in browser) work. Aurelia works without any problems on top of jsdom, the issues started with setting up the webpack style loader to include inline style.

@khuongduybui I am happy to answer any question to help you out, just let me know.

1 Like

OK, I’ll get adventurous this October! Thanks for the encouragement :smiley:

4 Likes

If I am to start building a Next / Nuxt equiv today

Can we use it as an Aurelia static site generator too? (Of course, any time in the future that was prepared.).

1 Like

My hope would be to stay as close to the 11 tenets of sapper as possible, and while static generation is not a must-have, it’s generally in-scope.

4 Likes

My SSR venture is running into a wall, so in the meantime, what is the plan with aurelia-ux?

I think it’s an open question: Do we build our own component library? or do we just tell people to use such and such CSS framework or web components library (e.g. Ionic Web Components)?

Personally, I would like to have our own, but it’s a large project and historically we’ve had trouble getting enough people to work on it consistently to build up a big enough component offering and feature-set. It really deserves it’s own team of 4-5 regular contributors. I could seed the vNext aurelia-ux with a bunch of initial components that I’ve built on the side. But, I’m not sure just yet if we have the team members who could dedicate time to take it from my initial implementation and keep it moving forward. We might be in a better position to answer this question after the alpha, once a few more core things are in place, and with more eyes on the framework. I’m working on a few things on the side that could enable this as well, but it’s too early to say just yet.

3 Likes

If I compare Aurelia with Angular (because that is unfortunately what we use at work and I hate their syntax), however I’d be happy to see these 2 features in Aurelia.

  1. Angular 8 bring supports for Differential Loading which creates a bunch of different bundles for ES5 to support old browser and ES2015 to support modern browser. The idea is that if you are on an old browser it will load a bigger ES5 bundle with polyfill but if you are on a modern browser it will load a much smaller ES2015 bundle without any polyfill.

In Angular 8, differential loading saves on average 7-20% in bundle size in modern browsers!

  1. in Angular we can use Getter & Setter on a bindable property with @Input() but in Aurelia we have to use [propName]Changed as a Setter. Don’t get me wrong, the xChanged(newVal, oldVal) is powerful but is also confusing for newcomer. I also mention this because I maintain 2 libraries Angular-Slickgrid and Aurelia-Slickgrid and there’s over 90% of the code that is almost the same expect for these Getter/Setter (I personally prefer the Getter/Setter style). Note that we could actually write code as a Getter/Setter in Aurelia but the Setter just won’t do anything (I got confused a few times while copying over my code from a framework to the other and it wasn’t working).

In Angular I write a dataset bindable property as

private _dataset: any[];
@Input()
set dataset(dataset: any[]) {
    this._dataset = dataset;
    this.refreshGrid(dataset);
}
get dataset(): any[] {
    return this.dataView.getItems();
}

but in Aurelia I have to write it in a totally different way

private _dataset: any[];
@bindable() dataset: any[];

datasetChanged(newValue: any[], oldValue: any[]) {
    this._dataset = newValue;
    this.refreshGrid(newValue);
}
1 Like

From your code example. Aurelia’s way feels more intuitive to me, even when I started with Aurelia. You choice may be influenced by familiarity.

The angular code uses setter for another side effect. It’s rigid and fixed in the implementation.

Aurelia’s way is a different idea. It’s a subscription of value change. The xxxChanged is just a shortcut of binding engine’s subscription. This sounds like an event subscription. The setter itself doesn’t directly perform other effect, it’s someone listening the value change event and triggering some logic.

Aurelia’s verbose way of doing subscription is to use bindingEngine.propertyObserver(this, 'xxx').subscribe((newValue, oldValue) => {}).

Note it’s like an event subscription, you not only can subscribe it within that VM itself, you can subscribe the change event anywhere in your code base as long as you have a reference to the VM.
bindingEngine.propertyObserver(thatVM, 'xxx')....
So that you can have totally decoupled side effect listening to the value change. I don’t know angular, but I will be surprised/disappointed if it doesn’t provide a mechanism to do something similar.

2 Likes

BTW, I don’t understand why you do this.

private _dataset: any[];
@bindable() dataset: any[];

datasetChanged(newValue: any[], oldValue: any[]) {
    this._dataset = newValue;
    this.refreshGrid(newValue);
}

Why not?

@bindable() dataset: any[];

datasetChanged(newValue: any[], oldValue: any[]) {
    this.refreshGrid(newValue);
}
2 Likes

Hi!

I haven’t uses Angular for a while. Is that offered as an option, when you generate a new Angular project with their CLI?

I think that’s worth it’s own thread, because a “Coming from Angular”-Section would be good for the Docs imho.

Best

1 Like

Aurelia has Durandal as background, which again has Caliburn as ancestor which was a C# WPF Framework. That said you’ll might recognize the PropertyChanged event subscription like in Winforms/WPF. Angular on the other side comes from ng1 which again tried to bring Java to the Frontend, given that Java is heavily used in Google and makes extensive use of setter sideeffects.

So while both achieve the same result you can See the different background which drove the decision of Implementation. Personally I like the event approach better since it allows for more flexibility

1 Like

Angular 8 bring supports for Differential Loading which creates a bunch of different bundles for ES5 to support old browser and ES2015 to support modern browser. The idea is that if you are on an old browser it will load a bigger ES5 bundle with polyfill but if you are on a modern browser it will load a much smaller ES2015 bundle without any polyfill

This is just build configuration if i understand correctly. Aurelia, in contrast with Angular, does not require any special tooling to worj, so the knowledge in webpack can be reused and apply here to create two different bundles and added it in the “differential loading manner”.

Not that straight, in a normal webpack setup, you can only change the outcome of local transpiling, not the npm packages.

Angular npm package must shipped few dist flavors for their building tool to choose from, not just the standard browser/module/main fields in package.json which webpack will pick in descending order.

Here is the list of files in @angular/core, looks like they provide two variants: esm5 and esm2015.

⋊> ~/p/t/n/@/core ll
total 1184
-rwxr-xr-x   1 huocp  staff   184B 26 Oct  1985 README.md
drwxr-xr-x  10 huocp  staff   320B 14 Oct 12:26 bundles
-rwxr-xr-x   1 huocp  staff   485K 26 Oct  1985 core.d.ts
-rwxr-xr-x   1 huocp  staff    85K 26 Oct  1985 core.metadata.json
drwxr-xr-x   8 huocp  staff   256B 14 Oct 12:26 esm2015
drwxr-xr-x   7 huocp  staff   224B 14 Oct 12:26 esm5
drwxr-xr-x   6 huocp  staff   192B 14 Oct 12:26 fesm2015
drwxr-xr-x   6 huocp  staff   192B 14 Oct 12:26 fesm5
-rwxr-xr-x   1 huocp  staff   2.2K 14 Oct 12:26 package.json
drwxr-xr-x   5 huocp  staff   160B 14 Oct 12:26 schematics
drwxr-xr-x   5 huocp  staff   160B 14 Oct 12:26 src
drwxr-xr-x   5 huocp  staff   160B 14 Oct 12:26 testing
-rwxr-xr-x   1 huocp  staff   137B 26 Oct  1985 testing.d.ts
-rwxr-xr-x   1 huocp  staff   157B 26 Oct  1985 testing.metadata.json
1 Like