And I couldn’t agree more with you! I’ve kept explaining my customers over the years 80% of the computation in their airliner add-ons are graphics related, not system simulation related in general, and most complaints for add-ons taking so much resources in the simulator has to be found most likely in the graphics APIs these add-ons are using. When I was coding the A320 simulation, it was capable rendering 6 EFIS, 2 FMC, all the other gauges, and executing the simulation of the entire set of A320 computers in about 5ms on a Core2 Duo 2Ghz. The systems were just a tad under 1ms and all vector drawing graphics done entirely on the CPU at that time (Airliner XP for those remembering*).
Besides, I have used “computation” as a broad term for non-developer audience, but what I meant was the capability to move and treat bytes the closest to the metal as possible (NB: it might be language barrier: calculation and computation have two different meanings to me). They do have different perf/cost benefits in any case, and none is better, just different and a possible strategy for 3rd parties is indeed to balance the use of both techs for what each is better at.
It is clear to me Just-in-time compilation of JS code is very efficient and JS is offering objectify-ing of the code in ways C++ could only dream of, but there are use-case where bare-to-the-metal C++ is giving access to the metal in a way, when you know how to take advantage of it, can lead to much better performance, or can produce results in a way not as easily achievable otherwise. In the end, whatever the technology, you can use it efficiently or poorly. Using known best JS coding practices, with known CoherentGT do’s and don’ts, will most likely beat a lot of 3rd party C++ coded add-on in may ways, and as a matter of fact, I’ve kept asking Asobo, in the 3rd party dev forum, they consider forgoing the legacy SDK bridge/interfaces they’ve built so that more focus goes into the more advanced JS/HTML layer. Because it is also clear to me the new layer is offering more profound capabilities than what is on the surface, and it is not just properly documented and exposed.
However, I shall add the newest JS/HTML layer doesn’t change some of the fundamental architectural limitations which have always existed in the FS SDK, and which are inherited from the legacy constructs and concepts still found at the root of the modern JS/HTML layer. I’ve been working in this industry full time for the last 20 years, offering categories of products which are touching these very limitations, which other developers aren’t usually confronted with nor are concerned about directly, yet which are imposing on them in one way or the other.
As an example, you’ve implemented the CJ4 AP in the form of a user facing logical view and an inner controller repurposing the available HDG/VS modes, because there is no real flight director overriding capability and this rings a bell to me. In effect, it is no different than our first GPS product implementations 20 years ago, due to the same kind of limitations we’ve been dealing with ever since and up to P3D5. However we’ve been able to address this problem in directly taking control of the AP flight director because we were not prevented to do so by any sandboxing (and to me it is clear you’d still need an AP mode for the FD bars in FS2020 - I wouldn’t even be surprised it is still implemented based on the same exact C function I can find untouched, from FS9 to P3D5, bits for bits).
Complex Airliners are certainly a possibility right now with the current JS/HTML layer and as long as the add-on is considered as a self-contained entity sufficient by itself. However the current SDK foundations are limiting expanding further on this “container” concept whenever you’d want, or need, to mix and merge add-ons together and this is what we’re dealing with for the last 20 years, and what is not yet changing in FS2020 either. Based on my experience building the same products for both Flight Simulator and X-Plane ecosystems for decades, I find the X-Plane SDK is based on a different design and is offering some interesting constructs and features, some of which could help solving some of the hurdles 3rd party developers are having with the FS2020 and which I find worth looking at and considering, but this is a topic in itself I could easily spend hours writing about and I’ve written enough for now! 