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 
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 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 
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
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.
- 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!
- in Angular we can use Getter & Setter on a bindable property with
@Input()but in Aurelia we have to use[propName]Changedas a Setter. Don’t get me wrong, thexChanged(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
To reply on the Differential Loading subject, it’s new to Angular 8.x, it creates multiple bundle and depending on your browser it will auto-detect whichever bundle is best suited for the browser you currently use, if you use an older browser like IE11 it will load more bundles and polyfills but if it detects your browser is a modern browser it will use a bundle that is much simpler. They can achieve this by a couple of different tricks, first is to change your tsconfig to target ES2015, then once that is done the Angular CLI will generate all bundles (for ES5 and also for ES2015), then they use some kind of script imports that only old browser understand and the same tricks for newer browser… The end goal is that, you as a developer don’t have to care how it’s done, it generates all bundles and you copy them all over to your server. The browser will automagically call the correct bundle, this allow to support all browsers and at the same time you have a much smaller bundle on newer browser because your tsconfig is targeting ES2015. You can all about this feature in this blog post, which is also where I copied the sample below from
Here’s a set of minified bundles, they seem to be using script type="module" for newer browser and nomodule for older browser. Each browser will auto-detect what it needs and use what is best for them. It allows to target multiple browsers in 1 shot with the best bundle size possible, you’re on an old browser well you get the big fat bundle, modern get small bundle, we get the best of both world.
<script src=“runtime-es2015.858f8dd898b75fe86926.js” type=“module”></script>
<script src=“polyfills-es2015.e954256595c973372414.js” type=“module”></script>
<script src=“runtime-es5.741402d1d47331ce975c.js” nomodule></script>
<script src=“polyfills-es5.405730e5ac8f727bd7d7.js” nomodule></script>
<script src=“main-es2015.63808232910db02f6170.js” type=“module”></script>
<script src=“main-es5.2cc74ace5dd8b3ac2622.js” nomodule></script>
For the Getter/Setter subject
I agree that the propertyObserver is much more powerful in Aurelia, but what I was saying is that that to me the Getter/Setter is easier to remember. The other day I lost 30min or so because I copied over some code from my Angular lib to my Aurelia lib and couldn’t figure out why the Setter wasn’t working (it wasn’t throwing any errors, it just wasn’t triggering anything), then I remember that “…oh yeah I have to use the xChanged() in Aurelia”. I just wrote about it for a comparison purpose. It’s about how you can bring developers from a different framework (Angular) to Aurelia, this is a small but confusing area at first (and I often forget about it). Nonetheless, both of my subjects seem to have brought few good discussions, hope that it was worth to mention it 
3 Likes
Hi!
Did you come across John Stew´s Findings. It would be interesting to compare a hand-crafted setup to angular´s magic, because there seems to be some pitfalls even with modern browser.
1 Like