That's very interesting. I am guessing ClojureScript generates a lot more code that runs through interfaces that sophisticated JITs can partially evaluate away.

For us, the performance difference was an order of magnitude, to the point that we were too slow in cases for search engines. We were investigating building an external Node proxy instance to prerender pages.

I sincerely hope there's no flag or simple tweak we were missing. It's possible the instances were starved for memory, for instance.

It wasn't discarded, just delivered separately. Unlike Swing/AWT, JavaFX is not part of the Java SE standard, so vendors don't have to include it, but users can use it like any library.

Burdening all five users of FX or Nashorn with the one time act of dependency management setup is a much lower cost for java popularity than burdening all other users of java with the repeated minor annoyance of JRE bloat. As a bonus, both have a much better chance of seeing continued development outside of the stifling rigidness of the JRE development process.

The team at Oracle can't be responsible for maintaining such a large set of complex and sometimes niche dependencies - it just isn't realistic or reasonable.

These project operate at a much different pace than the JDK. Actually, it makes everyones life easier: any sane project at scale already uses a dependency management tool, and it's just another entry there. Also, it makes it possible to nail down the JavaFX version that is used. It's one moving target less that varies by JRE version at deployment time and can ruin the show.

> (Maybe you want to add scripting? Maybe you want to use a JS lib? Really sort of depends on the circumstance)

I used it to add Markdown to a Java app, because JS-based Markdown libraries were better than Java-based ones.