Improve async/await usage, and sort init calls in index.js

[wxiaoguang]

The usage of async/await in some cases are incorrect. This PR makes the async/await more clear and sort the initXxx calls in index.js as planned in #17315 .

This PR only moves code, renames some functions, and processes async/await. No change to logic (hopefully)

==

Background for async/await in JavaScript:

async function foo() {
    func1();
    await bar();
    func2();
}
// equals to
function foo() {
    func1();
    return Promise.resolve(bar).then(() => {
         func2();
    });
}

So, many async/await in old code have no effect, and won't do parallel init of async loaded features, these functions are still executed one by one because JavaScript engines in browsers are single-threaded. Removing these async keywords makes the init logic more simple.

[codecov-commenter]

Codecov Report

Merging #17386 (30a30f9) into main (db89504) will increase coverage by 0.11%.
The diff coverage is 64.16%.

❗ Current head 30a30f9 differs from pull request most recent head c461672. Consider uploading reports for the commit c461672 to get more accurate results

@@            Coverage Diff             @@
##             main   #17386      +/-   ##
==========================================
+ Coverage   45.16%   45.28%   +0.11%     
==========================================
  Files         784      788       +4     
  Lines       88229    88415     +186     
==========================================
+ Hits        39849    40035     +186     
+ Misses      41908    41905       -3     
- Partials     6472     6475       +3     

Impacted Files	Coverage Δ
cmd/serv.go	2.46% <0.00%> (ø)
models/db/engine.go	31.25% <0.00%> (ø)
modules/cron/tasks_extended.go	70.16% <0.00%> (ø)
modules/csv/csv.go	73.21% <0.00%> (-2.72%)	⬇️
modules/updatechecker/update_checker.go	0.00% <0.00%> (ø)
routers/common/middleware.go	64.70% <0.00%> (ø)
routers/install/routes.go	45.76% <0.00%> (ø)
routers/web/admin/admin.go	11.34% <0.00%> (ø)
routers/web/base.go	18.00% <0.00%> (ø)
routers/web/repo/projects.go	16.00% <ø> (-0.32%)	⬇️
... and 31 more

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 23d3692...c461672. Read the comment docs.

[silverwind]

these functions are still executed one by one because JavaScript engines in browsers are single-threaded. Removing these async keywords makes the init logic more simple.

These functions do run concurrently and there's certainly a speed benefit of long-running operations like chunk loading.

I think not awaiting an async function is an anti-pattern because it breaks the linearity of code execution. Async function immediately return a promise and then continue to execute their code, which in itself can be a source of bugs.

[silverwind]

Again, function will return before editor is initialized, I don't like it.

[wxiaoguang]

I need the real reasons why it doesn't work. There should be no dependency between modules.

Most modules (features) should be able to be initialized at any order.

If there was a dependency, we should make it clear now. I can not bear the noodle-like logic.

[wxiaoguang]

these functions are still executed one by one because JavaScript engines in browsers are single-threaded. Removing these async keywords makes the init logic more simple.

These functions do run concurrently and there's certainly a speed benefit of long-running operations like chunk loading.

How do they run concurrently and how it improves speed? I didn't see any difference with the old code. There is no long-running operations in index.js or the init functions. Every init function can do its private long-running operation inside, but not in a global $(document).ready().

If there were some benefits, we need real examples and evidences.

I think not awaiting an async function is an anti-pattern because it breaks the linearity of code execution. Async function immediately return a promise and then continue to execute their code, which in itself can be a source of bugs.

What it breaks, I do not find the breakings you worried. When I remove async I also remove unnecessary await. In fact, in old code, there are async functions called without await. I just made things more clear.

About Async function immediately return a promise: it's not true. async functions only return the promises when an await call occurs. In our code, in most cases, async or not doesn't have difference.

In my mind, every function in $(document).ready() should be as fast as possible, no await should be in used in the global init stage.

[wxiaoguang]

@go-gitea/maintainers I think we should move on for the frontend refactoring, need your suggestions.

[delvh]

I lack the JS knowledge to be able to argue whether or not these changes make a difference.
But to me, they seem pretty idempotent.
Hence, if the same thing can be done with less code, which it looks like for me, I'm all for it.

[wxiaoguang]

OK, it seems that the Clean up in old title makes some people confused.

I changed the title to Improve async/await calls, I understand the async/await correctly and just improve the usage and make code more clear and correct.

[silverwind]

Will have another look soon.

[wxiaoguang]

@silverwind need your help.
@go-gitea/maintainers any more advice?