POC - Combining BW Clock and Desktop Launcher to spend less time "Loading..."

I think there's a bit of a worry with what you're doing with E.showMenu/etc. For a simple app that just shows the menu it's fine, but imagine something like https://banglejs.com/apps/?id=espruinote­rm where it's done something (opened a bluetooth connection in this case) and then shown a menu. Now when you want to switch apps you'll just move right on to the next app without clearing up.

That is why I tried to add the remove handler to the options given to E.show*. Apps then can cleanup after themselves if I decide to leave them when they are in a menu. The default is still not cleaning up and loading normally. See setting a remove handler for the scroller in launch to make fastloading out of it possible https://github.com/halemmerich/BangleApp­s/commit/74d0499976bbeb845ffda4a4fbb15ca­40884bc18.

This looks great as a proof of concept and it's really cool to have it on https://halemmerich.github.io/BangleApps­/ for everyone to use if they want to, but just to warn you that I think right now this is just too much to try and merge back into the default app loader.

I think we need at least a solution for the widgets not beeing updated correctly either in draw methods (multiple calls to Bangle.drawWidgets() => slow) or with update-methods in Firmware (part of what widgetupdate does). The rest I am completely fine with keeping separate.

For instance I just checked the messages app...

You can completely ignore that, there I just tried to have a look at how far I could go without completely borking everything. I will probably revert that completely since it is massively complex to even test every feature. Preferred solution to that would be an alternative implementation like is discussed in https://forum.espruino.com/conversations­/375794/.

If the function wrapping is to stop functions getting defined outside of scope, I think changing: function myfun(...) { ... } to let myfun = function(...) { ... } should have the desired effect.

Yes, tried that for some apps and works fine. Didn't think about the code reading/parsing implications of wrapping in a function.

I'm all for making Bangle.js faster, but I don't want to be in the position where I'm making it slower for everyone else just so that it can be faster for those that choose to install fastload.

No, fastload must be optional and as free of changes for all other stuff as possible. In the end normal loading will probably be the default for a long time. But stuff similar to fastloading will happen inside of apps (showing menus, scrollers and using setUI() for different parts of the app etc.) and I think we should have working cleanup for those scenarios.