Hacker News Reader

Comment by pavlov | Hacker News Reader

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.)

View on HN

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?

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.

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.

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.

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.

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?

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 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.

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.

Reply on news.ycombinator.com