Startup sequence feels muddled, misleading

[peterflynn]

The sequence of operations during Brackets startup is a little confusing. It's poorly documented and feels somewhat error prone... and in at least a few cases, there may already be issues as a result:

• The last stage of project loading (restoring the working set) happens in parallel with loading extensions, which seems somewhat fragile.
• APP_READY usually fires after the working set is fully restored, but is not guaranteed to. But because in most cases it does happen later, people often rely on it despite being not guaranteed (e.g. AppInit.appReady fires before document is loaded #1526 was closed despite not being truly fixed; pull Simplified LiveDevelopment/main.js #1880 relies on it always being fixed).
• Our "Application Startup" performance metric stops timing before any extensions have been loaded (including core, aka default extensions).

It seems like some of the weirdness is due to loading extensions after (mostly) opening the initial project. It would be cleaner if we load all extensions first, then load the initial project. But that runs afoul of #968 -- a problem loading extensions would prevent Brackets from loading the initial project, which at least in the past left it pretty much hosed. However, there are some ways we could address that: catch exception errors more robustly (see early work and later suggestions); or add a timeout (#1029) to ensure the next phase of startup always runs; or make Brackets robust to launching with no initially-open project.

Another thing we could do to help here is improve documentation, both on the wiki and in brackets.js, to more clearly describe the order of events during startup.

[DennisKehrig]

There is something to be said for first restoring the project, etc., and then loading the extensions (it just feels safest).

But there's indeed also something to be said for loading the extensions first, since then we can potentially influence more fundamental parts of Brackets. For instance, my whitespace extension monkey-patches CodeMirror and then triggers a refresh in visible editors, causing a visible delay between displaying the file and highlighting the whitespace in it. If I could patch CodeMirror before it was first use, it would look less like a hack.

[pthiess]

Reviewed, @jasonsanjose we should document

• and later move the other improvement stuff to the backlog to be prioritized.

[peterflynn]

Re "runs afoul of #968": due to pull #1968, we can now be much more robust to errors that occur during extension loading. That frees our hand to make extensions load sooner, if we so desire.

[DennisKehrig]

Please see commits e291103 and 15fa7bb in the dk/less-refactoring branch.

[dangoor]

Is there anything left for this bug, or are we done here?

[DennisKehrig]

Haven't tested this, but since my two commits are in there, a careful go from me.

[jasonsanjose]

FBNC @peterflynn. I've also updated the wiki page with the latest sequence https://github.com/adobe/brackets/wiki/Brackets-Development-How-Tos.

[peterflynn]

Looks great! Thanks for updating the wiki too.

[njx]

Removing "for release note" label from this old bug.