And apparently the astronaut !touchscreen! GUI is written in Javascript (not a joke).
At the time, some very good flight software engineers had been working diligently on a new UI framework that was written in the same code style and process as the rest of our flight software. However, I noticed a classic problem - we were working on the UI platform at the same time that we were trying to design and prototype the actual UI.
I made some observations:
1) We can create a prototype right now in Chrome, with its incumbent versatility.
2) The chip running the UI can actually reasonably run Chrome.
3) Web browsers are historically known for crashing, but that's partly because they have to handle every page on the whole Internet. A static system with the same browser running a single website, heavily tested, may be reliable enough for our needs.
4) We can always go back and reimplement the UI on top of the space-grade UI platform, and actually it'll be a lot easier because we will know exactly functionality we need out of that platform.
The prototype was a great success; we were able to implement a lot of interesting UI in just a week.
I left SpaceX before Crew Dragon launched, so I'm not sure what ended up launching or what the state of affairs is today. I remember hearing some feedback from testing sessions that the astronauts were pleasantly surprised when we were able to live edit a button when they commented it was too hard to reliably press it with their gloved finger.
As for reliability, to do a fair analysis you need to understand the requirements of the mission. Only then can you start thinking about faults and how to mitigate them. This isn't like Apollo where the astronauts had to physically reconfigure the spacecraft for each phase of the mission -- to an exceptionally large extent, Dragon flies itself. As a minor example of systemic fault tolerance, each display is individually controlled by its own processor. If a display fails, whether due to Chrome or cosmic radiation, an astronaut can simply use a different display.
Also, as a side note regarding "touchscreens" -- I believe some (very important) buttons did launch with Crew Dragon, but buttons and wiring are heavy, and weight is the enemy. If you're going to have a screen anyways, making it a touchscreen adds relatively trivial weight.
Updates keep us secure. /s
Please tell me you have a blog
But if it's implemented correctly, it probably won't get out of sync.
I am always amazed how HN doesn't realize many mission & life critical systems are powered by JS - especially as a front end through a browser.
I am always amazed how some people believe that adding more levels of abstraction leads to safer systems. /s
As long as the risks are acceptable (single non mission critical display out of many may rarely crash) then it's fine imo.
Still get a familiar development experience, live updates, and able to run on constrained devices.
why would that be mistaken for a joke?
(Maybe this is a good place to ask, anyone have a recommendation for static testing of JS?)
People also point out stuff like `[]+[]` where Array addition operator is not overloaded to handle it at all because the correct way is to use `.concat` so I think by default duck typing comes into play and in most cases with that in JS the preferred type is string.
I do wish that there was a "cleaner" spec of JS that wasn't as backwards compatible but fixed all of the gotchas and filled in every gap but there doesn't seem to be much call for it atm.