I will check this JavaScript::Duktape out , at first it looks like by prefixing all the key words with "duck_" you can part away from from mozjs (aka spidermonkey) itself; is this ducktape library worth the swap ?

there are a multitude of packages interpreting javascript, which is quite mind bugling. diversity is ok, and blogs like this can help to find a way and engaging into the right path. hence my questions.

JE seems to be used a lot.

WWW-Mechanize-Firefox-0.79, looks promising.

so it takes a lot of time to evaluate those packages particularly when they fail their dependencies, internal tests, and got neglected. but who knows what would it become in a few years, but one is sure javascript is not dead yet.

I have only looked briefly at JavaScript::Duktape and patched it to also work on Windows, but I haven't had the need to use it in a more involved way.

I also haven't used JE, but as it is an implementation running in pure Perl, it is really slow.

I have used (and written) WWW::Mechanize::Chrome and WWW::Mechanize::Firefox, but if you don't need a browser+DOM, they are vast overkill and likely much more fragile than an embedded VM.

I am dazzled, this busyness has fast evolved. We are such small things. Anyway is it right to seeing two trends to bridge javascript-html and perl :

• connect directly to the guts of a browser process, using WWW::Mechanize::"my_amazing_browser" and its many engines.
• interfacing a virtual javascript/ECMA engine within JavaScript::"the_bestest_JS" and then plug it in WWW::Scripter stuffs.
...?

and got to say I am impressed by this JavaScript::Duktape looks quite clean, furnished with thorough tests and lush documents, and did installs at first shot, using duktape v2.0 on my debian system (except for this: "CAUGHT ERR: Error: oh boy! at t/nested.t line 18." !).