[Brainstorm][ns+ng] App launch performances


#1

Hi there,

I was wondering lately on what is, as of today, the main issue with using nativescript + angular. My company is working with this awesome framework since the alphas of ns+ng, and we’re glad of the way it went.

As we are developpers, we tends to struggle to take a step back and see what are the main issues on our apps (bugs appart !) for the user point of view. I’m creating this topic to have an open discussion on the issue of startup time.

As far as I see it, startup time is the main issue for us. Why ?

  • For our customers, first launch (fresh install) is long enough to trigger a “the app is not responding” - which is wrong and can be ignored by the user, but still.
  • app launch is too long ! Seriously, this is a big deal. I’ve read a very promising thread from the nativescript blog about AOT compiling with webpack. I’ve not been able to make it work properly, and I’ve allocated an entire day to it. This raises to me one question, why is this not more documented ? A blog post is not enough on that, even if it’s a good start.
  • Startup time is a big deal for us, because we experience a lot of “hard reboot” of the app when resuming the app (I guess it’s the default behavior when the resume sequence fails). Therefore, the startup time directly impacts the application lifetime, and is not experienced “just once” in the best case.
  • Default package JSON imports the nativescript android snapshot (tns create xx --ng), which is responsible of a direct crash of the app when building signed APK. I’m raising this in that topic because this one is supposed to speed up startup time. weird.

Well, in a nutshell, I’m dropping this out to get things better ! :slight_smile:

I think that telerik’s goal is to have real apps running wiith ns, and I wanted to raise this up !

Cheers,

Echap


#2

Your startup time will be much improved if you can make webpack work. I feel your pain here, it’s not particularly easy. However we have experts here who have done it successfully! I’ll ping @bradwaynemartin @NathanaelA @wwwalkerrun @triniwiz - definitely we need to get our arms around this!


#3

If you are using NAN (NativeScript ANgular) webpack is a MUST. If you are using PAN (Plain Awesome NativeScript), webpack is nice, but has only a minor effect.

NAN has so (so so so so) many files that startup up time is amazingly slow if you don’t use webpack to make the app be built into a single (or two) files. In addition webpacking will affect the size of the application greatly.

Now as to using WebPack; you just need to install the plugin and use the --bundle parameter. However, depending on what plugins you use you might have to do some work to get webpack to fully function properly in your app. It isn’t quite install and run simple yet. Please read the github issues for webpack and you should see where people have reported issues and work arounds that you may need to use.

I know I personally have reported several issues and fixes. However, I haven’t played much with the all new webpack that was just recently released. I do know that some of the old fixes still apply as I helped a client with it the other day, but I haven’t actually used the new version on any of my apps.

In addition if you can use the snapshot it does help for startup time. But I have to admit even in my PAN app; I haven’t had any real success using snapshots and had to disable them for my app. But my PAN app starts almost instantly already so it wasn’t that big of an issue for me or my client, so I haven’t spent any time figuring out why it breaks yet…

Nathanael A.


#4

Thanks @jen.looper and NathanaelA for embracing this issue, I’m glad to hear that this is a keypoint for you.

Both of your comments are pushing me into webpack and be sure that we will take a good look at it. I’d rather say that we will make everything we can do to have it working, since we can’t decently provide apps with 20s launch time.

Once again, my wish is to take nativescript closer to a real option as a “reliable” appplication. (I’m only talking about ns+ng ).

I strongly belive that this should be taken in account for next releases. Apps should be bundled with webpack if it provides the performences you says it does.

As a Angular 2 user for our webapps, it’s been a long time now since @angular/cli is bundling with webpack, and it’s really, really helpful for releasing real software.

Now, practically, we’ve been building our app around ns+ng without taking care of bundling with webpack. We’ve got several modules with a 100th of components, and I’m really afraid that introducing webpack will be a pain in the ass.

Don’t you belive that nativescript 3.0 should embrace webpack by default ? I have no clear idea of what it means for Telerik. I feel like there is a messy thing around bundling, and that even the angular team itself is in beetween systemJS and webpack.

The keypoint for me about enabling Webpack by default is to force third party developpers to have bundling-ready plugins.

To be continued, I will try to introduce webpack for our app within the following days.


#5

Thanks Eric for bringing up this very valid point. To make this a bit more concrete I’ve done some “testing” on a Moto E3 which indeed is not the fastest phone around. I just ran the standard templates and measured how long it took to launch.

tns create test-no-ng 3 seconds
tns create test-ng --ng 16 seconds

At the same time starting the app on Genymotion on my laptop is rather fast (1 or 2 seconds) which makes me believe that the performance of the file system is the bottleneck. Not sure whether it is the total size or the amount of the file is the issue here.

Concerning webpack, it is a bit of a pain to get started. To make matters worse:

tns create helloworld --ng tns platform add android npm install --save-dev nativescript-dev-webpack npm run start-android-bundle

give errors. So there’s is even a starting to work from.

As Eric said, I hope that webpack is embraced in {N} 3.0 since I feel it will be we they way to go when delivering {N} + ng2 apps.
Having said that, I love {N}! It’s a joy to develop apps with it (especially w/ ng2 & TypeScript).


#6

Yeah well, thanks for bringing figures on that @bfv, this show up quite clearly the impact of angular for launch time. On top of that, adding a full set of node modules and a consequent app is a real pain.

Regarding to emulators, it’s right, there is visible impact on performances, and you cannot relie on it to juge to the performances. I would say it’s the case for any app (even native), but for this particular purpose, it’s a very tricky thing.

Then, a little bit of feedback about implementing webpack on an existing project :

With tns@2.5.2, our first move was to make a fresh project and doing the exact same thing.

This went well for us withtout any issue, and the difference is significant event for a clear project (the default app template launches at least twice as fast on a Nexus 5X).

Then, the pain started.
Removing all the requires for a quite big project is very long. Yet not very complex for much cases, we had to update all our dependancies for which fortunately the last versions embedded a correct main value in their composer.json.

I have to note that the telerik-ui stuff was the most tricky thing import correctly.
The webpack compiler throwed a very strange error because we did not have a main.aot.ts file (No mention of that in the documentation).
Also, the globals.addModule trick to use require is not that easy to work with, we had the chance to use only well typed packages to avoid using it. (After we took 3 hours replacing all the requires with it :smile:)

We finally managed to build the project with webpack, abd its reaaaaly a fresh breath !
We still need to fix some issues with custom shema imports, but it’s drastically more efficient.

To sum it up, I can’t figure out why webpack is not defaultly embedded by the nativescript CLI. The work is almost done here ! For all the new projects that are comming up, it’s not an issue to make correct imports, I’ve not seen much of other drawbacks using webpack.

Now, your move :wink:


#7

Ok, I redid my timings, this time with a rebooted and clean phone (no other apps running) and a descent timer.

tns create test-no-ng: 4 seconds
tns create test-ng --ng: 12 seconds
tns create test-ng --ng + webpack: 5 seconds

Again, these number are measured on a Moto E3 which is slow. Another of my projects (ng, no webpack) however was even slower than these numbers on a Nexus 5X.

Just to let you know.

Btw, got my webpack running on the template project after a npm cache clean


#8

I’d also like to add that the initial startup after the app has been downloaded will be considerably slower than any follow up startups due to the fact that application resources (everything in /app dir, including the angular sources) and metadata are extracted on the device.


#9

This is indeed the case on nativescript angular without webpacking.

With webpacking, this is not significant (I haven’t benchmarked it but it doesn’t feels bad)


#10

The reason why Webpack isn’t default is because it is fairly new to the NativeScript eco-system in the grand scheme of things. NAN was released in the NS 2.x time frame, and shortly after NAN was released Webpack was released to deal with the size/startup issues of NAN apps. It doesn’t really do a whole lot for PAN apps.

Btw to install Webpack in a new project; try tns install webpack much simpler… :wink:

At this point Webpack is still a pain to get working properly and as such I rarely use it. So I am really glad it isn’t default. :wink:

You might not have meant it that way, but that “quote” I just quoted from you @eric is wrong thinking and really frustrates me… I assume you are getting paid by someone (employer, contract, customer(s)) to make this app; and you are now stating I should do MORE work for free (to make my plugins webpackable) on a free plugin to make your life easier? Seriously?

The plugins are free and provided as-is! You are free to submit a pull request which fixes it or to pay me to fix it; but otherwise count yourself blessed that we even released them for you to use. And stating that your keypoint for making WebPack default is to make me have to do more work for free by no means makes me at all happy.

Nathanael A.


#11

Another thing you would will is a release build also if you are all about speed i think android-snapshot should work in your favor


#12

WoW, wow, wow, as you wrote as a disclaimer, I might (and did not) meant what you just wrote. I am absolutely not saying that third party developers should work for me. I’ve been forking and made PR on plugins whenever I was able to do so.

My idea was just to provide efficient plugins out of the box. Nothing more. FYI we are making our own application.

Discussing about the business model of open source is a thing, but I’m quite disappointed this topic means for you that I want someone else to do my job, and not helping the community to do things better.

Hope we just misunderstood :wink:


#13

Sorry this is a hot button topic for me, demanding usage of other peoples time. Your wording of forcing third party devs says to me that you want the plugin authors to fix it, and since the plugins are free; that implies for free. I am really glad it was a misunderstanding, because the way you wrote does not convey discussion for how to improve the situation. It conveys an expectation of my time. :frowning:

I am a contract developer; so most of my plugins were done on my own time using my own money to fund them. Any updates/support are again using my own time and money. The point I was trying to make with your app; is you stated your company is making this app; which typically means you are being paid to make this app and even if the app is released for free you still got paid. You can see how very annoying it is for me who has to fund any and all free work with my own money to have an implied expectation that I do more work for free from someone who gets paid. Hot button time! :wink:

Since I have written over 40 plugins; I still have many plugins that still have the .js in the package.json; (since the removal of the .js is a brand new requirement in the upgraded version of NS-webpack which was released around the same time as NS 2.5). .

IMHO, A better way to start a discussion on how to fix this issue with Webpack and making plugins more webpack friendly would be something like.

  • Q: How can we improve this situation so there is less issues?
    A: Do pull requests for any plugins you are using (and even some you aren’t).
    A: Do pull requests against NS-Webpack for issues you find in WebPack
    A: Ask the plugin authors and see how you can help the plugin authors fix any webpack issues in their plugins. Several of the top contributors are here on the forums… :wink:

  • Q: Can we detect if the plugin is WebPack compatible? Add a field/notice to PNR (http://plugins.nativescript.rocks) or add additional points to PNO (http://plugins.nativescript.org)?
    A: Yes, I can detect this situation,and PNR will be getting some updates in the future to use a better data source (about 20% done already). PNO should inherit the additional scoring change from PNR when I merge the data gathering system and start collecting that data…

  • Q: Can we fix Webpack so that having the postfix .js doesn’t matter?
    A: No idea; but it is a breaking change from the earlier version of webpack, no idea if it is fixable but I’m sure someone could dig into the new version of webpack and see… :slight_smile:

These are all questions that propel the discussion forward… :wink:

Nathanael A.


#14

@eric I want to point you towards this very nice community documentation that will definitely help me, and I hope you: How to decrease app size and release it using webpack and NativeScript - I’m sure plugin authors are happy to work with us users to make the plugins web-packable. Last time I tried this we had to tweak the DrawingPad and a few other plugins for PocketRave. I’ll be trying again (same app) in the near future and will document my process. Thanks for continuing to try to make our ecosystem better!