イベントの順番が大切な場合は、実行順が保証されないのはあると思いますが、
大規模かつ多人数による開発なので、勝手にreadyへセットしてしまうとどこで何をやっているのか把握しきれなくなるという面が多いと思います(技術的な副作用というより、コード管理の面での問題です)。
readyを1箇所にして、なおかつ動かすものを具体的にコードで書き表すことで、「このページで動いているコードはこれだけある」と明確にするための施策だと判断しました。
複数人で開発する際に、readyイベントがとこで何をやっているかの
複数人で開発する際に、readyイベントがとこで何をやっているかの 見通しがよくなりそうですね。ありがとうございます。
DOMContentLoadedイベントに記述する内容はWEBページの初期化が主だと思います. DOMContentLoadedイベントにコールバックを複数登録することは, 初期化シーケンスの分散管理にほかなりません.
DOMContentLoaded に限った問題ではないと思いますが、UI Eventsではイベントリスナーは登録した順番で実行されることが保証されています。
勿論、実際にはどちらかが先に発動するように設計されているはずですが、ドキュメントに説明がない以上は、将来的に挙動が変更される可能性も否定出来ません。
先述の通り、これは DOMContentLoaded に限った問題ではなく、同じ要素ノードに複数のイベントハンドラを登録した場合にも適用されます。
ある要素ノードにハンドラAとハンドラBを登録する場合、次の2パターンの状況が考えられます。
ハンドラA、ハンドラBはどちらが先に発動しても問題がない(各々ぎ独立した機能、もしくはハンドラA,Bに関係性はあるが、どちらが先に発動しても整合性がとれるように設計されている)
readyの場合は、保証されていない、、と。それは知らなかったです。モジュール化もできるようになってきているので集中管理したほうが良さそうですね。