I have a domain-specific Windows application that uses Google's V8 engine for hosting user-written scripts. It hasn't been upgraded for several years, and when I recently took a look at updating the V8 version it's linked with, I was dismayed at how bloated and complex V8 has become. Seems like it can't be compiled down to a single DLL anymore, at least not without turning the compilation into a miniature research project in itself.
So there's definitely a need for more lightweight contenders in this space.
Ideally someone would just do an "stb"-style JavaScript interpreter that would fit into a single .c or .h file. This is closer to that ethos than most other candidates, and as others have noted, Fabrice's credibility as a '1337 h4x0r gives it an instant leg up on the competition. I don't have an urgent need to switch away from V8 right now, but I'll be watching this project with moderate interest.
Does the the application basically pass data to a user script (the user knows JS so it is useful for them?), and then the JS returns the data after processed?
Amusingly I asked the question and remembered that I actually worked on (supported) a hardware product that did this to some extent. It was a disaster as the scripting language would eat memory / cpu and crash the box ;)
Correct, the application acquires data from hardware and allows the user to access it from their own JavaScript code. This is useful for automated test, report generation, debugging, things like that. Crashing is bad for customer relations. :) V8 has performed well in that regard, no complaints there. I just don't see why it has to be so massive.
You have a C app, and want to allow to script parts of it via JS easilly. I use engine like this inside the milter daemon for my postfix mail server, to process mail during reception.
What would someone....do with this?
Use it to run JS on some embedded device where you can run C?