You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
❤️ Replace the Rhino based JavaScript engine ❤️ #755
And will you implement via ports & adapters where users will be able to choose which engine to use, or will you completely switch to a new one?
Would be interesting to be able to hot swap the engine.
For example, if I know a page is not working correctly with Rhino (live scrolling for example), I could hot swap to the other js engine before loading the page, do what I need to do and then hot swap back.
Would allow for slow rollout as people would start using the new engine more and more as you work to refactor and integrate it while adding more js features and fixing issues.
Reacted by Penek and AzmainMahatab
Reacted by Rob Winch, Bruno P. Kinoshita and Alex VrV
This transpiler idea was suggested already in another issue, maybe i can add that feature based on the gist. There is also a special babel configuration for Rhino, this might also be helpful for that.
At the moment i more focused on Rhino because so many things are going on, the project really moves forward and there is some hope to get more major features done soon.
Reacted by Csaba Kincses, lingmu206 and duonglaiquang
At the moment the rhino project moves really fast - there is hope for spread and also class support. Therefore i like to stay with rhino and see how it processes during the next months.
Check the release notes to get an idea what has changed during the last months.
@rbri just curious if you have looked at https://github.com/roastedroot/quickjs4j
also out of academic interest when you say spread support, can you point me to a discussion etc. to get an idea of what the current gaps are
Activity
[-]Replace the Rhino based JavaScript engine[/-][+]❤️ Replace the Rhino based JavaScript engine ❤️[/+]skyhirider commentedon May 4, 2024
Which engine(s) are you considering?
And will you implement via ports & adapters where users will be able to choose which engine to use, or will you completely switch to a new one?
Would be interesting to be able to hot swap the engine.
For example, if I know a page is not working correctly with Rhino (live scrolling for example), I could hot swap to the other js engine before loading the page, do what I need to do and then hot swap back.
Would allow for slow rollout as people would start using the new engine more and more as you work to refactor and integrate it while adding more js features and fixing issues.
arjantijms commentedon Jun 18, 2025
Would it be an option to add a transpiler of some sort, to support newer js syntax?
kincsescsaba commentedon Jun 22, 2025
You can add a ScriptPreProcessor to do the transpilation to ES5: https://gist.github.com/kincsescsaba/a7f1b236c1be91e1529a9af8e31e4357
rbri commentedon Jun 24, 2025
This transpiler idea was suggested already in another issue, maybe i can add that feature based on the gist. There is also a special babel configuration for Rhino, this might also be helpful for that.
At the moment i more focused on Rhino because so many things are going on, the project really moves forward and there is some hope to get more major features done soon.
rbri commentedon Sep 16, 2025
At the moment the rhino project moves really fast - there is hope for spread and also class support. Therefore i like to stay with rhino and see how it processes during the next months.
Check the release notes to get an idea what has changed during the last months.
ptrthomas commentedon Sep 18, 2025
@rbri just curious if you have looked at https://github.com/roastedroot/quickjs4j
also out of academic interest when you say spread support, can you point me to a discussion etc. to get an idea of what the current gaps are
rbri commentedon Sep 18, 2025
@ptrthomas currently on vacation, will come back to this in a week