Is there any future plans about improving the JavaScript Engine?

General JUCE discussion
21

That’s good news, we had a lot of problems integrating QuickJS in JUCE and have it fully cross platform (windows/MSVC is still not that well supported).
I’m really interested in your development @ncthom ! Will follow this here then :wink:

22

I’d recommend https://github.com/pybind/pybind11 to corporate with cpp.

23

Made some progress on the refactoring. I’ve just added an EcmascriptEngine class to the Blueprint module. The interface is very similar to JUCE’s JavaScriptEngine, and you can see it here: https://github.com/nick-thompson/blueprint/blob/master/blueprint/core/blueprint_EcmascriptEngine.h#L21

There’s a little more to do, but the bulk of it is in there. Tomorrow I’ll attempt to cover the rest:

  • Implementing the property setters and the invoke method
  • More tests
  • Add a fatal error callback

Some basic usage examples here in the test file: https://github.com/nick-thompson/blueprint/blob/master/blueprint/tests/blueprint_EcmascriptEngineTests.cpp#L19

The goal of this interface is that it should be easily implemented by one of the several embedded interpreters out there, so if anyone wants to take a stab at swapping V8 in there, it should be pretty easy to just add a preprocessor check to see which cpp file to load, then see if you can get the test case passing in the testrunner example project

24

One more update– I’ve implemented the rest of the interface except for fatal error handling, which is in progress. But you can definitely use it already, check it out on the master branch of Blueprint. Let me know how it goes!

3 Likes
25

That’s great ! Thank you very much, we will definitely give it a try. I honestly don’t know when since our focused session has just finished, but I’ll post some feedback as soon as we tested that.

26

Hey,
getting back to that after a while :slight_smile:
The link to your ecmascriptengine seems dead… is it just moved or have you chosen another developping path ?

I think going V8 could be the way, although I’m curious about your experience with duktape : I’m looking to upgrade the engine in my software Chataigne ( Chataigne | Chataigne ) currently using a slightly modified version of the juce javascript engine.
No need for full blown crazy features, but the users are now asking for a more “complete” javascript environment and I’m especially interested in the ability to use include()/require() functionality so people can use external libraries.

27

There are two js engines supported now, Duktape & Hermes

I’ve used the JS engine in two projects. I stuck with Duktape since it’s easy to build and is fast enough and has enough features for my needs. It’s only ES5 which is quite dated now. I may look at Hermes in future, but it’s low priority. I did need to make a few changes in the wrapper to support calling class methods in C++ and a few other things.

28

@jules Choc library has a new Javascript engine which you might want to take a look at. It looks like it wraps Duktape. If you have Tracktion, then you already have Choc.

29

Thanks for notifying me to tell me that, though I was kind of aware of it, given that I wrote choc!

FYI The choc one can now use either duktape or QuickJS, behind the same API. And it’s all header-only to build.

I’m using it with the QuickJS engine, which seems as fast as duktape but with modern syntax, but if anyone wanted to add a choc wrapper for Hermes, it’d probably be easy enough to fit into the same API framework.

2 Likes
30

I’ve wondered about that too. though I think the intention was more like @jules 's Choc…

31

Yes why not have another c++ library that does a bit what JUCE does already by the creator of JUCE himself… why?

1 Like
32

This is also raising the question for me as why is it not integrated into the JUCE framework then ? It seems that everything’s pretty much in place, it would obviously need some adapting, but would it be a lot of work ?