This is confused because Asobo added WASM/SimConnect to help migration of FSX C++ gauge code, so FSX devs (probably still the majority of MSFS devs) tend to concentrate on the WASM support even though it has significant limitations in MSFS.
There are three apiās that work as intended on MSFS:
(1) The Windows compiled .exe simconnect programs. These can be written in C++ or C#, have full control over the usersā PCās, and interact with the sim across a protected inter-process boundary exchanging information via reading and writing simvars that either affect the sim engine directly or can also be read and written by gauge code. An error that crashes your Windows .exe simconnect program will typically have no effect on the sim at all. The excellent integration with the userās PC comes with a trade-off of less integration with MSFS, i.e. you are limited to variable value exchanges via the simconnect API.
(2) Model Behavior XML - this uses an unusual proprietary programming language defined partly as a reverse-polish stack based language supporting variables with basic arithmetic, if-then-elseās and simple math functions, and also a scripting language defined in XML itself, with special tags used for procedure calls, switch statements and argument passing. This code is closely tied to the sim update cycle and designed to be mostly linear (i.e. no loops) and so very fast. An error in the XML will typically cause MSFS to CTD as soon as the aircraft is loaded, but valid XML that loads ok is then very unlikely to crash the sim. For simple gauges than only move animated parts (e.g. an ASI) this API works fine.
(3) The HTML/JS gauge system. This runs in a separate thread but is closely tied to the sim with a comprehensive API allowing access to all simvars, user interactions including ātouchā and higher-level APIās such as the map, flightplan and flight services at airports. The HTML is mostly optional (i.e. a module can be written in JS with no direct interaction with the pilot) but the HTML allows arbitrary digital content to be rendered onto texture surfaces in the aircraft and user interactions with that area can be passed back to the gauge code. The HTML is particularly suited to flat-panel instruments, and also the background dials of analog instruments so those can be adjusted according to user preferences (i.e. imperial/metric, or light/dark options). JS has very similar syntax to C++ but also has standardised ways of rendering digital data (i.e. svg/html/css) and asychronously receiving user events so there is widespread experience of those (i.e. web development).
Note that none of these options are C++/WASM, which allows you to take older C++ code that used the SimConnect interface, and compile it into a Javascript subset (WASM) that runs in the same protected enviroment as the HTML/JS gauge code and can write digital data to in-cockpit textures using a 2D/3D library, but has no access to the external PC or the various gauge APIās making it a distant second choice for new gauge development in MSFS.
There is no relevant performance difference in MSFS between JS and WASM for normal cockpit content in a complex aircraft. The Volocity Volocopter developers DID write a complete replacement flight simulation engine in C++/WASM to replace the engine inside MSFS and that was definitely faster than JS, but that code has no UI/interaction. The canonical instrument which you would have performance concerns for would be the large modern PFD and MFD displays and these are being most successfully developed in HTML/JS. WASM doesnāt run at all on the XBox at the moment, and some developers are lobbying to get that implemented, but even then there is no chance those simconnect programs will have access to the userās device (PC or XBox) so the simconnect programs are still a limited choice to the JS APIās, unless youāre porting a whole load of existing Windows C++/simconnect code.
Unless you are porting an existing C++ XPNDR gauge from FSX then HTML/JS would be a far more mainstream choice for a new gauge in MSFS.