Personally I’m struggling to see the benefit of abstracting that configuration, especially considering the bootstrapping is so trivial. To me it’s important to keep the app structure and code conventions as close to Angular’s own setup on their tutorials and such—that’s why the current starting template is setup the way that it is. I would be hesitant to add anything that moves us away from Angular’s own conventions, and it seems like an @app decorator would.

The starting template is very similar to the project in Angular2 (Web) angular2 starter project so i'll give a thumbs up there.

i'll agree that nativeScriptBootstrap makes it very simple over the older bootstrap function. I don't really object to main.ts over the @app decorator either. Decorators have been growing on me as a source of configuration or forcing convention through the application which raised my curiosity about this one coming into NativeScript. I did start with Ionic 2 for a month before starting with nativescript-angular, which is probably encouraging that familiarity.

I wouldn't go as far as saying its moving away from convention but rather throwing a blanket over it while hiding it behind a different curtain just as the nativeScriptBootstrap function does a bit.

So the difference to the starting template would be dropping the main.js and pointing the package.json to start at app.component.ts

Given the app.component.ts file it could look like:

import {App} from "somewhere";

@App({
    selector: "my-app",
    template: `
    <StackLayout orientation="vertical">
        <Label [text]="message" class="title" (tap)="message = 'OHAI'"></Label>
    </StackLayout>`
})

export class AppComponent {
    public message: string = "Hello, Angular!";
}

Which in my opinion is a little nicer and expresses the workflow and purpose a bit better. Failing to argue my point in a effective way however ... could the nativeScriptBootstrap return a promise with appRef just as bootstrap does? I was hoping to tie into nativeScriptBootstrap but I found it doesnt return anything so I copied its implementation to have access to appRef.

@matt4446 I’ll let others give their opinions about the @App idea so it’s not just me, but just to follow up on your other note—nativeScriptBootstrap should totally return a promise if bootstrap does. Could you file an issue specifically for that so it doesn’t get lost?

@tjvantoll #156 added.

We were discussing this today, and it seems that the bootstrap/nativeScriptBootstrap function pair provides a more flexible solution. In addition the @App decorator can be provided by a third party library.

I'll close the issue for the time being, and, of course, we could reconsider it in the future.