asciidoctor / asciidoctorj

:coffee: Java bindings for Asciidoctor. Asciidoctor on the JVM!
http://asciidoctor.org
Apache License 2.0
627 stars 172 forks source link

Allow Asciidoctor.js to be used in AsciidoctorJ #189

Open mojavelinux opened 10 years ago

mojavelinux commented 10 years ago

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.

mojavelinux commented 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

lordofthejars commented 10 years ago

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.

mojavelinux commented 10 years ago

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.

lordofthejars commented 10 years ago

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.

mojavelinux commented 10 years ago

Nice!!

mojavelinux commented 9 years ago

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.

mojavelinux commented 9 years ago

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.

rmannibucau commented 5 years ago

+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)

mojavelinux commented 5 years ago

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.

rmannibucau commented 5 years ago

@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.

mojavelinux commented 5 years ago

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?

rmannibucau commented 5 years ago

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 :(.