It is explained in the article, but not very clearly: > The JWST isn’t running a web browser where JavaScript directly controls the Mid-Infrared Instrument — i

It is explained in the article, but not very clearly: > The JWST isn’t running a web browser where JavaScript directly controls the Mid-Infrared Instrument — it’s more like when a manager is given a list of tasks (in this example, the JavaScripts) to do and delegates them out to their team. The way I interpret this is that JavaScript programs are used to coordinate missions - meaning, in the script, it is specified what instruments to use and how to configure them. Maybe even a `for` loop to sweep an instrument across a range. But the instruments themselves don't run JavaScript. Since it's a simple language (at least, compared to the embedded languages the instruments actually run) it presumably makes it easy and safe to configure the satellite. Think of it more as a configuration file written in JavaScript. You could compare this to video games written in C++ that expose to the user a Lua scripting engine such as World of Warcraft or Garry's Mod. This comment links to a paper with more info: https://news.ycombinator.com/item?id=19738151 https://news.ycombinator.com/item?id=19738151 > ScriptEase JavaScript allows for a modular design flow, where on-board scripts call lower-level scripts that are defined as functions. > The script interpreter is run by the flight software, which is written in C++. The flight software operates the spacecraft and the science instruments. > The flight software will execute the command sent by the calling on-board script and return telemetry, which will be evaluated in real-time by that on-board script. The calling script will then send status information to a higher-level on-board script, which contains the logic to skip forward in the observing plan in response to certain events