The James Webb Space Telescope Runs JavaScript, Apparently | Hacker News Reader

The James Webb Space Telescope Runs JavaScript, Apparently

theverge.com

115 pointsandrew_85 comments

I got to visit the control centre while it was under construction back in 2016 (I think: I was one of the guests at an SF convention, hence the special group tour). One factoid that stuck with me was they also considered micro-Python, but Javascript won because it supported floats. They were looking for an embeddable scripting language that astronomers could reasonably be expected to learn or already use for directing observations, so it had to be compact, very popular or ubiquitous, expected to remain so throughout the working life of the telescope, and easy to learn. (It was to be used not by CS grads but by astronomers.)

It's a cut-down subset of the language and bolted down to prevent idiots installing random packages off the internet on an irreplaceable $10Bn instrument.

> It's a cut-down subset of the language and bolted down to prevent idiots installing random packages off the internet on an irreplaceable $10Bn instrument.

Webb-pack? Amirite?! Heyoh!

It seems that the choice of what would work reasonably on the hardware while being orbit-programmable and not esotheric boils down to JS, Lua, Scheme, and Forth. The latter two have a steeper learning curve. Between JS and Lua, the former has more implementations, and by far more widely known.

As far as I'm aware, JS was chosen long before Micropython or node existed.

Is there a document describing the language subset they picked?

A superset of ECMA-262, 3rd edition (1999).

<https://brent-noorda.com/nombas/us/devspace/manual/c/html/TH...> (full docs: <https://brent-noorda.com/nombas/us/devspace/manual/c/html/in...>)

Moar:

- <https://arc.aiaa.org/doi/pdf/10.2514/6.2006-5747>

- <https://brent-noorda.com/nombas/history/HistoryOfNombas.html...>

Thanks! Those are good links.

Unfortunately the manual is rather vague; it’s not clear what the ScriptEase language extensions to JavaScript are, versus adding more objects and methods, which I wouldn’t consider to be changing the language.

I am not sure what they are talking about with this page about lifetimes: <https://brent-noorda.com/nombas/us/devspace/manual/c/html/TH...>

Not sure (but probably yes): I seem to recall ECMAScript was mentioned, not sure what version number.

Yes, in the article it says "Nombas ScriptEase 5.00e"

If there has to be a scripting runtime on a device that sits at a Lagrange point, I’d much rather have it be JavaScript than e.g. Python or Ruby.

JS runtimes are so widely used that they’re extremely well debugged and very fast. The language standard library is tiny, which means much less surface for bugs compared to the hulking default dependency monstrosities of those other languages.

As long as you don’t use anything from the Node or web browser ecosystems, JavaScript is a great embedded scripting language. (Of course everything goes to hell if you bring in node_modules or try to support the bad APIs from browsers.)

As a former V8 engineer, I was actually relieved that they were not running V8. V8 would be overkill for their needs.

> JS runtimes are so widely used that they’re extremely well debugged and very fast.

This would be true if these systems weren't constantly changing, both because the language keeps evolving and the runtime techniques keep evolving.

The truth is that JS runtimes are extraordinarily complicated pieces of software, and they have bugs, sometimes very subtle ones. Sometimes bugs have been hiding for years, and sometimes they are new. This despite being developed by some of the best engineers I have ever worked with, being daily pounded on by billions of people, and fuzzers with thousands of cores.

> This would be true if these systems weren't constantly changing, both because the language keeps evolving and the runtime techniques keep evolving.

Seconded as a former SpiderMonkey engineer. As a safety guy, trusting an optimizing JIT is the stuff of my (professional) nightmares and the fact that the language keeps evolving, has semantics that very few people on Earth actually understand fully and that (very smart) developers keep cramming new optimizations within them.

Oh, and add to that the fact that they're pretty much all written in C++, which is already the stuff of nightmares for safety professionals, and that they rely on garbage-collectors that need to walk both JavaScript and C++ heaps.

I would trust a small, certified, non-optimizing implementation of a JS runtime much more than any of the juggernauts out there.

Digression, just curious-- what do you think of Bellard's QuickJS?

I'm not the v8 engineer, but I do maintain software that embeds v8. quickjs is a breath of fresh air compared to using v8. it's missing some features that v8 has (isolates, etc), but has an extremely fast startup, an api that doesn't change constantly, and is much much much smaller/easier to build.

I think it is running a very old proprietary interpreter based on some old engine called ScriptEase.

These systems were decided upon in 2003 according to the article, so that's a very different landscape when it comes to "well understood and debuggable" and the language features of the day. As for speed, yeah, that wasn't a feather in JS' cap in 2003. It was notoriously slow and awful in even cases where the script engine was embedded into decently written compiled code.

V8 wasn't an option because it couldn't have been for another five years.

Regarding the standard library being small, that's not really about the language but about the deployment of it. V8 offers standard library features you don't get in browser-based JS, you get different things in .NET Core vs .NET Framework, you get a different experience compiling C++ on glibC vs MSVC++'s STL, OpenJDK vs Oracle JDK, etc., etc. Those aren't strictly language features.

You could take Python and rip out all of its standard library in order to have a more "pure" language approach.

Clearly it met specific requirements that the engineers had as a scripting language than others, so it's getting the job done. I just don't think your overall points are actually based in the reality of Javascript as a language in 2003.

Lua might be a good choice for this application. I'm just glad there's a scripting environment at all instead of a bunch of custom compiled 16 bit C code.

Except they are using an ancient, bespoke runtime.

JS sucks, but V8 is an incredible piece of engineering. That is true. But they aren't using V8.

V8 is a bloated hog that basically changes every time you blink. A maintenance nightmare in any sense of the word.

> As long as you don’t use anything from the Node or web browser ecosystems

So what are you using then?

JS, particularly in the era discussed here, only came with a small number of standard objects. The Host was expected to provide a series of Host Objects. In a browser these might be things like Window, Document and XMLHttpRequest. Scanning the linked article on the JWST it seems these might be things like Command and Telemetry, that would be written in C++, and then scripted in JS.

Having worked on an embedded script engine that was JS-based at the time, this is exactly what we were doing. Basically the script host (C++ code) offered up specific sets of available objects to the engine that you could interact with and essentially trigger the C++ functionality from, passing in data, and such.

It wasn't a fantastic experience at the time but luckily for us the stakes were pretty low as we were working on interactive mall map kiosk devices.

Yea, me too. Sounds like we've chewed some of the same, "programming dirt".

You can write custom JS bindings for C++ with V8. So you could expose some functionality that way and then implement routines in JS.

Either custom embedding in a native app (JavaScriptCore or V8 directly, or a runtime wrapper abstraction like FB's JSI), or plain Node with extreme prejudice against anything from the npm pits of hell.

Do we need the constant npm/node_modules hyperbole? HN has an obsession with dogging the ecosystem and it's usually from those who have never shipped a large JS project, let alone understand how or why things are the way they are.

> it's usually from those who have never shipped a large JS project

What do you have to say to those who have?

I have worked in large JS codebases that predate NodeJS's cannibalization of JS, and it's precisely why I deride the former—because I know from firsthand experience that it doesn't have to be the way that it is, and there are tons of people (too many) operating on the misconception that JS=Node (and inducing others to make the same mistake). Even this article from The Verge contributes misdirected scorn by linking, of all things, to... Maciej Cegłowski's talk about "The Website Obesity Crisis" (wat).

It would be one thing if the person you were replying to had shown up to write "lol leftpad good luck", but that's not what's going on. It's the opposite of that.

You completely omit (conveniently) how browsers have evolved over the past decade, how business requirements have changed (and become more complex) and how npm itself (you could argue the entire JS ecosystem, along with language changes) has changed.

Cool, things use to be easier when you were working pre-Node dominance but you weren't shipping the complex interaction patterns that have resulted in the ecosystem we have today.

So frustrating to have conversations with those who have no perspective or context on the why and rest on their laurels of old when "things were easier". Good grief.

> You completely omit (conveniently) how browsers have evolved over the past decade

Why would I talk about that? The article is about the James Webb Space Telescope, not the James Webb Browser. Aside from that, this is rooted at the mention of "node_modules", which is a NodeJS-ism; browsers don't even run NodeJS modules (unless you recompile them to standard JS), so browsers are doubly irrelevant...

> and how npm itself (you could argue the entire JS ecosystem, along with language changes) has changed

I didn't omit that. I was very explicit about NodeJS cannibalizing JS.

> So frustrating to have conversations with those who have no perspective or context on the why and rest on their laurels of old when "things were easier".

You seem to have me confused with someone else. (Talk about "context"!) Where does that quote from? It looks like you made it up.

In 2008 I adapted an ecommerce web app working only in IE6 to work on Firefox, it used plain XMLHttpRequest with XML api, no json. Parsing XML was a pain. In 2012 I wrote a Bill Of Material web editor for fashion products, 8k lines of pure javascript, embedded in a monstrous legacy web application, still running. Or a datagrid that had to work with IE10 loading 10k rows with client side filtering because the client requested so. Not enormous projects, but things have been complex for a long time, now they are often overengineered, I wouldn't touch FE dev env with a ten meter long pole. Things were much easier with JSF, especially for pure b2b stuff.

Exactly right. The anti npm crowd also forgets that many developers don't choose their dependencies. I work at BigCo and we have a React Native app. I can either:

1. Use npm.

2. Not feed my family.

I guess I'll use npm.

So you're saying that the only good thing about npm is that you don't get fired for using it, but people who don't like it are wrong?

Or accept another job at not BigCo and work with a leaner tech stack.

False dichotomy between 1. and 2..

If you're a frontend dev, explain where to go for a "leaner stack"? How many Reason jobs are there? How many Scala.js? Are you for real?

What are you trying to say? Yes NPM is bad. Yes it could've been better. Yes it sucks you have to use it.

agreed on the runtime, but for non-engineers to write scripts in, Ruby would have been a better choice IMO; I also wouldn't call the Ruby runtime a hulking monstrosity (Python I agree is much more extensive)

But JS bad!!!

No, actually. JS wasn't designed to be generally and minimally embeddable, it was a hack designed to be a embedded in a proprietary program with lots of bells and whistles. You can say that a thing doesn't have to be designed for something to do it good if the users are crafty enough, but then what's the point? Python or Ruby would have equally served the role, none of the 3 languages were designed to be lightweight embeddable. The point about JS runtimes having more eyeballs and corporate support than most other language is fair, but the actual facts in OP make it moot : JS is used because of, what else?, legacy reasons. The decision was made in 2003-2004. That's, I think, barely after or during the first standard of JS, and when all the runtimes available were very buggy and divergent in behaviour.

In reality, there are plenty of interpreters you can embed and be very sure you're not making a mistake. Lisp and Forth are the top of that list, forth far ahead of lisp (literally designed to be used in embedded systems, and much simpler and lower-lever than most lisps). After that, there is Lua and Tcl, both explicitly designed to be embedded and extended, and lua specifically pushing words like "portable" and "lightweight" to the extremities. After that, you have Java (which runs on 3 billion devices!) and even Python, which has micro-variants running on higher end embedded Linux devices. JS is at around this tier.

I was going to ask about Lua and Tcl. Though I have nothing against JavaScript. I'd like to see a document about how they chose JavaScript against the others considering those embedded languages available at the time is was chosen.

I generally agree with you.

However, note that JS, with all its warts, has the benefit that its security model has been studied in the harshest conditions for 20+ years. I can't think of any other scripting language that has been battle-tested nearly as much.

Not particularly relevant to this use case.

Fair enough, I should have written "safety" instead of "security".

Because you really don't want a script written by a end-user to crash down your $10B / 20 years of planned mission hardware.

As nobody reads TFA these days, I have to supply the money quotes myself.

> I mean that the actual telescope, arguably one of humanity’s finest scientific achievements, is largely controlled by JavaScript files. Oh, and it’s based on a software development kit from 2002.

> According to Nombas’ (now-defunct) website, the latest update to ScriptEase 5.00e was released in January 2003

> next time you’re cursing the modern web for being so slow and wishing that someone would just blast JavaScript into space, you can remember that NASA has, in fact, done that.

I read it, and all that quote illustrates is that the author doesn't know a great deal about NASA's development process. ScriptEase is not large, and purchasing it 17 years ago means that they had plenty of time to fully vet it individually, write their Host Objects and then another 15 years or so to test it.

If you're curious about how NASA develops software - https://www.fastcompany.com/28121/they-write-right-stuff

For a low level view, as how the code actually should look like, I found the JPL C coding guidelines very useful. It had an effect on me on how I wrote C after reading it.

Here's a github hosted version https://github.com/stanislaw/awesome-safety-critical/blob/ma...

> 23. Place #else, #elif, and #endif in the same file as the matching #if or #ifdef.

Oh my. I bet that one has an interesting history! That thought has never even crossed my mind, and I did some fun stuff like include a header twice with different definitions to get a C++ mixin.

I am interested, ty.

Bit offtopic but I'm interested because I've never seen the answer.

Does JWST's imaging censors are 20 years old tech, or the team could used a modern sensor that fits the 20+ years old design specification?

the imaging equipment that goes into space is definitely state of the art, though the requirements for it would have been locked for some time.

It's not like the JWST folks said "we're going to fly a canon 5D!" and then were 20 years out of date when the JWST flew. Pretty much all of the sensors are built from scratch, using very advanced/specialized techniques. Given that the tech is all custom, including some stuff that probably had to be invented or otherwise figured out to begin with, it's hard to say the "tech is old," given it's just now flying.

In other ways, some of it looks old: one of JWST's main sensors images at 1024x1024. There might be other constraints at play here—how much data you get per pixel is directly related to your telescope's angular resolution and sensitivity of sensor.

Here's a page that discusses the JWST's sensors:

https://webb.nasa.gov/content/about/innovations/infrared.htm...

The journal article linked at the bottom of that page is also quite interesting as it talks about the science of the sensor technology and also the background of astronomer's requirements too. You can find it easily on google with a `filetype:pdf` filter.

Even more offtopic: I would be interested in how it's handled in general. So for long-running projects (10-15years)...do they redo outdated parts? Wait until the last minute and don't plan "obviously useless" parts in advance? For example big construction projects that are in a limbo for some years, have they already detailed plans entirely on outdated equipment (from security to elevators) or just kept em blank?

There's a big construction project near me where the architect was chosen 20 yers ago and now the costs explode, i was thinking whether this is a cause (outdated plans because one didn't follow through immediately).

Tangential (and not my area of expertise), but I do know that the Ingenuity helicopter uses an off-the-shelf Snapdragon 801 SoC. As I understand it that is very unusual for any projects like this, let alone something like the JWST.

https://en.wikipedia.org/wiki/Ingenuity_(helicopter)#Design

It has always been a specific goal of the Mars rovers since the very first one, to use a faster/cheaper design and production process than traditional Nasa projects.

In essense, using more off the shelf parts for the Mars rovers is part of the science experiment.

This was true of the first rover (Pathfinder ‘97) but really hasn’t been true of rovers since then. Ingenuity was an exception re: COTS parts since it was experimental.

Pathfinder cost <$300M. “Better cheaper faster” became Discovery class missions, “capped” at $500M. Curiosity and Perseverance cost about $2.5B each. Not in the same category.

NASA has teams of engineers focused on supply chain and reliability.

Supply Chain Risk Management, https://sma.nasa.gov/sma-disciplines/supply-chain-risk-manag...

“NASA’s Reliability and Maintainability (R&M) program ensures that the systems within NASA’s spaceflight programs and projects perform as required throughout their life cycles to satisfy mission objectives.” https://sma.nasa.gov/sma-disciplines/reliability-and-maintai...

Changing the sensors would make it very hard to evaluate under the very strict condition they were tested. The system integration would be very hard.

The sensors on JWST have are outdated and do have some issues. For instance, some of the microshutter on NIRSpec are stuck (they knew before launching). The MIRI has some image artifacts due manufacturing techniques.

The sensors were bespoke, even nowadays, we can't get sensors like the on on JSWT off the shelf. There isn't much use case for most of them outside space telescope. But we could do better with today technology.

I don't think this answers your question directly, but you can learn more about the camera and sensors used in this link

https://www.nasa.gov/mission_pages/webb/instruments/index.ht...

This isn't as crazy as you think, it makes sense for scientific spacecraft which are intended to be controlled by non-engineers.

Hubble Space Telescope can also be controlled with a custom DSL directly by researchers, with the only difference being the sandbox location - it's compiled and verified on Earth before being sent to the spacecraft. With JWST, they wanted to modernize things and make scripting more accessible. Of course now the variant they use (ScriptEase) is two decades old already.

I just updated our "Nombas doesn't exist anymore" page, for readers of this nice and mostly-accurate article, with a little more background on why I think NASA chose it (tl;dr "robust and predictable"). <http://brent-noorda.com/nombas/us/index.htm>

BTW, it just occurred to me after writing that that one of the first customers to ever license our software, over the dozen years we were in business, used it to control a camera, while possibly our last customer (NASA) also used it to control a (much bigger) camera. JavaScript: it's a language for taking pictures.

This is awesome! How does it feel to have contributed to a massive advancement in space exploration? Did you develop ScriptEase with this use case in mind (cameras)? Why did ScriptEase development stop? Do you think ScriptEase would be useful in cameras today?

Thank. Yes, it feels very satisfying having it finally be deployed and operational, like a big sigh of relieve after holding in a small bit of breath (one alveoli's worth) for 20 years. ScriptEase started when I began working alone on a project, instead of with big teams, and needed a faster program paradigm so that I alone could be as productive as a big team. It turned out to be generic enough that it was useful for a lot of types of projects, not just mine (which was to be an infinite backup product) or cameras (nothing on my mind at the time at all) but pretty much any software who's core libraries needed easy modification--also turned out to be useful in web browers, although I didn't know it at the time, because I didn't know there was such as thing yet as browsers or the web. The development stopped because by early 2000 times were really changing--people were getting less into paying for software libraries and more into getting free stuff; but it was 9/11 that really killed it, because our customers stopped paying us (because their customers stopped paying them, and so on). The final nail in the coffin was a big snowstorm on the day someone offered to acquihire us and move us to California where we'd never have to shovel snow again.

Finally, ScriptEase itself would have too many legal troubles being used by anyone, but I do believe just about everything needs a script language so it can be altered and customized and personalized and applied to infinite new purposes (and not a new one invented every week, just something boring and stable).

If I were to revive something from ScriptEase, I've often thought it should be the ideas behind the test environment around it. Where everything that can go wrong will go wrong and it must still survive.

Thanks for the reply! Were you aware NASA was using ScriptEase? And was(is?) ScriptEase open source?

NASA licensed one $3 copy, but we didn't know why until ~a year later (just a guess how long it was) then found they'd had a team analyzing lots of software options, so by 2003 or so we knew it was for a next-gen telescope.

SE was never "open source" in the standard sense, although almost everyone who licensed it got the source. In the very early nineties I was contact by people to say that what I'd been working on should be "open sourced" in the "free beer" context. I needed money to pay rent, put shoes on the kids' feet, and stuff like that, so didn't understand how to get paid for free software. They said "people will pay you to customize it, or to fix bugs" and I said "it's already ultra-customizable and I don't release software with bugs". I kind of get it now, and if I could talk to my old self I would tell self to open-source at least parts so that there was no reason for anyone NOT to use it. So now I'm working on inventing a time machine to go back and tell myself that and A LOT of more important things, but the time-machine work is going very very slow.

Hey, thanks for the hint. I didn't know about Nombas at all.

Did you see the Espruino Engine? https://www.espruino.com/

Would it be possible to get some examples of these scripts?

No real mention of why. So, why?

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

> 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

None of that explains why JavaScript.

Because JavaScript happened to be the language we at Nombas implemented in our "robust and predictable" engine. If a, e.g., python or TcL engine were as solid at the time for a can't-fail embedded engine, they could have happily used that.

Thanks for replying! I looked on your website, where there’s more information.

Half of my question was surprise, because I would have thought something like Common Lisp, Erlang, Chez Scheme, Guile Scheme, Chicken Scheme would have been interesting choices. Despite being compiled they have various support for interpreters, embedding, and live update / hot reload of code.

The other half was curiosity because I just didn’t know why JavaScript would be chosen and would like to know. (Hence my question.)

You should post here as your own post about the project. That would be interesting.

And congratulations on having some code running on JWST. It’s gotta be uniquely thrilling.

Why not? They aren't using npm, so security/stability isn't an issue. I guess it was either lua or js, and the devs didn't like 1 based indexing.

They had delays, a rapidly looming deadline and not enough personnel, so NASA had to resort to hiring React developers.

Because JavaScript is a really widespread scripting language, so it's very well suited for this task?

No, in 2002 it wasn't.

This was before reliable XMLHttpRequest cross-browser support and several years before Ajax started to push Javascript's popularity.

i don't think they'll be doing any browser related tasks on JWST

The argument was that Javascript wasn’t a popular and widespread programming language back then.

Do you have a link to where you found that explanation for the reasoning? Just curious to read a bit more deeply why.

I somehow feel personally validated that they decided to use JavaScript as it was in 2002.

I feel there is a lesson here...perhaps this is what you do when money isn't your incentive.

Dev 1: I wouldn’t touch JavaScript with a ten foot pole.

Dev 2: hold my beer

As inane as this sounds, it just hit me that the JWST is some 5 light seconds away. And for some reason, that boggled the mind, that we do these things.

Don't use document.querySelectorAll unless you're prepared to wait a while...

Conttary to plenty of people, I love javascript. Having programmed 5 years in it makes me value and love golang much more. And it's always nice to have your competitor startups running js and lose time with console log debugging and handling SPA complexity.

console log debugging? I guess you never seriously wrote something in JavaScript. I learned many programming languages during my 15 years in this job. The Chrome / V8 Dev "Tools" are a dream to many devs. Even those who work with Visual Studio Pro. (not VS Code, thought)

No JWST != JWT

JWST dependent on leftpad is simultaneously funny and terrifying !

https://xkcd.com/2347/

This is likely running JS in the same way that some embedded GSM modules "run Python". It uses the language syntax and semantics, but uses a different, small runtime with very limited features. Probably there are some host objects (like Window in the browser world — likely stuff like Camera) and JS is just used as a convenient language to write the logic in.

Which is all to say it's really far removed from left-pad and the rest of the npm cluster**.

Reply on news.ycombinator.com