Open mojavelinux opened 10 years ago
Here's a repository that contains a prototype: https://github.com/lordofthejars/asciidoctorjs
Asciidoctor.js is also being used in the AsciidocFX project: https://github.com/rahmanusta/AsciidocFX/blob/master/src/main/java/com/kodcu/service/AsciiDoctorRenderService.java
I am going to start working on this on Monday. I will start with nashorn so we avoid adding a new dependency. But of course I would implement with dynjs to compare performance
Enviat des del meu iPhone
El 22/08/2014, a les 10.28, Dan Allen notifications@github.com va escriure:
Here's a repository that contains a prototype: https://github.com/lordofthejars/asciidoctorjs
Asciidoctor.js is also being used in the AsciidocFX project: https://github.com/rahmanusta/AsciidocFX/blob/master/src/main/java/com/kodcu/service/AsciiDoctorRenderService.java
— Reply to this email directly or view it on GitHub.
I think you could help encourage collaboration on this integration if you started a branch in the upstream repository. Perhaps just call it asciidoctor.js-integration or something.
I have just created one, i have refactored almost all code in next says i will sent you a summary and if we agree the contract then integrating asciidoctorjs will be really easy
Enviat des del meu iPhone
El 27/08/2014, a les 4.12, Dan Allen notifications@github.com va escriure:
I think you could help encourage collaboration on this integration if you started a branch in the upstream repository. Perhaps just call it asciidoctor.js-integration or something.
— Reply to this email directly or view it on GitHub.
Nice!!
I did some quick benchmarks against the last two EA builds of JDK8. My typical benchmark is the AsciiDoc Python user guide, which converts after warmup on my machine in 0.18s. Here are the results running Asciidoctor.js on Nashorn using jjs to give you an idea of where we stand performance wise.
.8u40-ea-b15
- Load scripts: 4.818s
- Run #1: 36.266s
- Run #2: 19.389s
- Run #3: 13.575s
- Run #4: 10.865s
.8u40-ea-b18
- Load scripts: 4.649s
- Run #1: 27.47s
- Run #2: 16.654s
- Run #3: 10.793s
- Run #4: 11.314s
It seems like Asciidoctor.js on Nashorn is about 50 times as slow as Asciidoctor Ruby (MRI or JRuby). That's not completely terrible, but not great. We should look keep an eye on improvements in both Nashorn and Opal to speed this up.
To provide some comparison, SpiderMonkey takes 3s and V8 takes 2.5s. However, unlike Nashorn, the native JavaScript implementations don't perform better on subsequent runs.
+1 for this, jruby stack has some issues in some env and js would be easy to support and a valid solution (workaround maybe but at least it "unblocks" on the user land)
I believe that's what this project is all about: https://github.com/mogztter/asciidoctorg It's not integrated directly into AsciidoctorJ yet, but that is the plan, as I understand it.
@mojavelinux my understanding is different, there are two steps in java/js integrations: 1. use a jsr223 ou v8 engine, 2. use graalvm which can have impacts on the JVM itself - it is not guaranteed that the graalvm new portability API works without running on graal itself AFAIK. Guess 1 is desired quickly, 2 is a nice to have for later IMHO.
I could be wrong, but my understanding is that going forward, there is no other option for running JavaScript on the JVM than GraalVM because Nashorn is being removed (and Rhino is woefully outdated). Are you aware of another strategy?
Yes, using v8 (https://github.com/eclipsesource/J2V8 - or https://github.com/flier/jav8), maybe one nashorn fork?, or even use frontend-maven-plugin core module to just run in node. I also confirm the project you mention does not work when not ran with graalvm so not that much an option yet :(.
Allow Asciidoctor.js to be used as an alternate Asciidoctor implementation in AsciidoctorJ. The focus here is on hiding the implementation behind the Asciidoctor interface and allowing the Factory to select implementation when the Asciidoctor object is instantiated.
There's no need to support Rhino. We should focus on Nashorn and dynjs. Between the two, we shouldn't show a favorite in AsciidoctorJ.