Improve editor loading time by loading code editor async

[Steve-Mcl]

TLDR
By my rough calculations, removing ACE from vendors and loading Monaco async is ~36% faster (perceived). In real world terms it is between 23%~36% faster.

Current State

• ACE is bundled into the main vendors bundle and loaded on every page, even if the user has selected Monaco as their preferred editor. This adds ~400kb to the initial load of the editor.
• Monaco bootstrap use document.write to load scripts. This causes the loading of the editor to be synchronous and block the UI until it is loaded.
  • In effect, Monaco is not loaded until AFTER vendors.js has loaded and executed (which is already delayed by the inclusion ACE in vendors)

Issues Loading code editor

1. ACE is still bundled into vendors (adding ~400kb to the vendors bundle) even when users choose Monaco
   • ACE should have a bootstrap to load it on demand, similar to Monaco
2. If ACE is the preferred editor but fails to load, there is no fallback.
3. Current monaco-bootstrap uses document.write to load scripts, which is not ideal (MDN marks it as deprecated - https://developer.mozilla.org/en-US/docs/Web/API/Document/write)

Recommended Changes

1. Instead of bundling ACE in the vendors bundle, it should be conditionally included in index.mst (via a mustache conditional which calls a bootstrap to load it) same as Monaco.
2. ACE and Monaco bootstraps should not use document.write to load scripts, but instead create script elements and append to the DOM. This will allow them to load asynchronously and not block the UI.
3. A basic fallback code editor should be implemented and used when the preferred editor fails to load, to ensure there is always a working code editor available.
   • This could be a simple textarea-based editor that is used until the preferred editor is loaded, at which point it can be replaced with the full-featured editor.
   • This will help when the network is slow and the async loading of ACE/Monaco is delayed.

Benefits

• Improved load times for the NR editor due to:
  • ACE only being loaded when selected as the preferred editor
  • Monaco / ACE loading asynchronously and not blocking the UI
• A fallback editor ensures users can still edit code even if the preferred editor fails to load (or is late to load)

Care points

• Some older nodes may use ACE via window.ace directly. By removing ACE from the vendors bundle, we may want to ensure that something is available on window.ace to prevent errors in those nodes.
  • This could be a simple stub that covers the basic API used by those nodes e.g. window.ace = { edit => { return RED.editor.codeEditor.basic.create } }

[Steve-Mcl]

To help visualise this, I have done some tests on a simulated 4G network connection (to exaggerate / reveal the current loading state)

Current Condition: Loading Monaco with ACE bundled and using document.write (sync loading)

Key points:

• Vendors is 1152kB (includes ACE)
• Monaco does not start until after vendors is loaded
• Monaco loads synchronously and delays loading of UI elements to the 11 sec mark

Proposed condition: Unbundled ACE and allowing Monaco to load async

Key points:

• Vendors is now 742kB (410kB less) (excludes ACE)
• Monaco still does not start until after vendors is loaded (this could also be improved by moving monaco into index.mst but that has some consequences if loaded before its lang pack)
• Monaco loads asynchronously and does NOT delay loading of UI elements which now start at the 7 sec mark

---

The code for this branch will be pushed shortly for anyone to review.

[Steve-Mcl]

By my rough calculations, this represents ~36% faster loading (at least perceived)
In real world terms it is ~23% faster by the time everything is loaded.

[Steve-Mcl]

FYI: There are 2 branches to accompany this:

1. design-88-editor-loading
   • This implements the changes in the discussion
2. design-88-editor-loading-with-preload
   • this adds a link tag with preload to make the monaco editor preload with other resources.
   • in theory this should be quicker than loading after the vendors file, however, in testing, it was the same or slower. This is likely due to more parallel processing (its a balancing act - future changes may impact this and it may become more relevant!)