The recent SpaceX Dragon launch brings JavaScript to space. Leveraging Chromium and JavaScript, significant portions of the user interface rely on web technologies.
While there was significant humor present in the related discussion on Twitter and a Reddit AMA session with members of the SpaceX software team such as "Are node_modules really the heaviest module in space, maybe?", JavaScript supports a modern touchscreen-based UI for the SpaceX Dragon spacecraft.
As explained by NASA Astronaut Christina Koch at the recent OpenJS World conference, SpaceX has very modern displays. The Dragon is the first spacecraft with touchscreens. Astronauts aboard the Dragon wore special spacesuits with gloves to support touch screen access in incredibly harsh environments. The user experience has just a few buttons for very mission-critical operations and access to redundant systems.
Koch explains that the team leverages many web-based applications on the space station, but all via tablets, which live on a separate network from all systems powering the space station. The teams at the space station leverage web-based scheduling software and procedures, and regularly leverage web properties such as YouTube for professional and entertainment purposes.
NASA is currently working on the Orion vehicle for missions to the Moon and eventually Mars. For the first time, NASA has designed the crew interfaces via a rapid prototype lab focused on user-driven needs rather than top-level down requirements. While Orion is not currently touch-driven, there are plans for many programmable buttons and procedures updating display for efficient flight experiences.
On Dragon, the interface makes extensive use of web components and a custom reactive framework. As explained by SpaceX software engineer Sofian Hnaide during the Reddit AMA,
The use of Chromium and JavaScript in mission-critical environments is a popular question. In order for me to answer this question clearly, we have to understand that Chromium in this context is used as a UI rendering engine only. The Flight Software interaction layer with the displays and the fault tolerant is well defined and resides outside the displays boundary. That said, we follow the same development process for all vehicle code regardless of the technology stack. We cross train our developers to write vehicle code in C++ and to carry the same mentality toward writing reliable software. We take reliability & performance very seriously, and just like other vehicle software, we test extensively under different conditions to understand all failure modes. We have alerts & procedures in place to act on those failures in case we encounter them. All of that added to hundreds of hours of sims that we run on flight hardware to train the crew.
While we faced many challenges along the way, we are very happy with our displays and most importantly our two customers (so far) are too. Starship ground software is already using the crew displays tech stack and it won't be too long before we start designing human interfaces for Starship. Make sure to apply!
Wendy Shimata, manager of the SpaceX Dragon software team, adds:
You'll also notice in certain images too that there still exist some hardware buttons in the capsule right below the displays; this is also to ensure that in case the displays are unusable for whatever reason, the astronauts can still use hardware buttons to initiate critical actions, such as responding to a fire in the cabin.
Given the significant importance of reliable software, the team leverages extensive approaches to testing. As explained by John Dietrick, SpaceX team lead for Demo-2:
Every way we can think of! Unit tests, containerized integrated tests (you can run these on your own machine with a full physics simulation), and full-up "HITL" (hardware-in-the-loop) tests on real flight hardware – again, with full simulation. Mating the flight software up against the simulator is the most powerful tool we have, especially when it's run on the real hardware. We can simulate an entire mission, and even many detailed fault scenarios, with the vehicle hardware just sitting on a table in the lab. On the vehicle, this is pretty easy. For getting it down to ground, we have some great communications links and ground-side networking that allows us to get a lot of data back from the vehicle, very quickly.
The project began as a simulator prototype to showcase the design vision to NASA. The team then ran it on flight hardware with modifications and had some early success. The SpaceX team gained more confidence in the web-based approach as they developed the prototype. As explained by Hnaide,
We liked all the modern features that comes in with browsers out of the box, we also liked having access to talent that is already trained in that stack. Perhaps we are not afraid of doing things slightly differently here in SpaceX. We like taking a first-principles approach to problem solving, as opposed to just relying upon industry standards.
In a lengthy Twitter thread about this news, original JavaScript creator and Brave CEO Brendan Eich provided both humorous JavaScript in space comments and more seriously responses on how to leverage type safety of TypeScript, Flow, or Hegel to ensure that TypeScript is safe for space.
Clearly, JavaScript now actually is rocket science.
