TeaVM

[Thomas Bilk]

Hi All.

How does ScalaJS compare to TeaVM?

Couldn't I compile my scala code to bytecode and then the bytecode to javascript? For me this seems quite usefull since I could also use Java libs like Joda in JS.

So what do you think about this?

Thanks.

[Sébastien Doeraene]

Hi,

I didn't know about TeaVM. This is the first time I hear about it. So everything I say here is drawn for 30 minutes of reading about TeaVM without trying it out.

Community

Even before talking about the technical comparison, I would highlight Scala.js' community. At first glance, it seems TeaVM has a very small community: 14 threads on the mailing list, that's about everything I could find. Scala.js has a very active community, notably on Gitter [1]. The community also develops many very good libraries besides just the compiler and the JDK, which help for front-end development in general and client/server communications. The community and ecosystem is what makes a different between a usable compiler and something on top of which you can actually build a project.

Technical side

At a first approximation, on the technical side, I would say that Scala.js' major advantages over TeaVM will be related to the fact that Scala is much closer to JS than Java is. Scala.js' interop with JavaScript is very natural because of that. The double OO and Functional paradigms are shared, not to mention the tendency to use asynchronous stuff such as Promises/Futures. There is even js.Dynamic for dynamically typed interop with JS, which I doubt you can achieve in Java. Moreover, primitive data types such as Ints and Strings are represented directly as primitive JavaScript values, and there is no boxing when they are put in generic data structures, which helps interop and performance.

Performance-wise, I can't tell anything for real without explicit benchmarks of Scala.js vs TeaVM. But reasoning about it, I can say a few things, Scala.js supports the Scala standard library, and there are adaptations to it that make it more efficient on the JavaScript runtime (or make it work at all, in some cases), which you won't have if you use the Scala std lib with TeaVM. Scala.js also has a very good optimizer which is Scala-aware, so it will optimize Scala code much better than TeaVM ever could. In particular, higher-order methods are typically inlined away as while loops.

In general, Scala.js is tailored for Scala, and for JavaScript. You will get the most of your Scala with Scala.js.

True, you don't get to reuse Java source code directly. This is an unconditional advantage of TeaVM over Scala.js.

That's about all I can say with such short knowledge of TeaVM, I think. But if you have more specific questions, I can probably answer as well.

Cheers,

Sébastien

[1] https://gitter.im/scala-js/scala-js

--
You received this message because you are subscribed to the Google Groups "Scala.js" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-js+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/scala-js/bab49d46-142a-4852-93d1-366d44a29b30%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Marius Kotsbak]

Regarding Jodatime, have you seen Soda time: https://github.com/mdedetrich/soda-time?

[Thomas Bilk]

Thank you Sébastien and Marius for your insights. I still find the idea interesting to convert the bytecode to javascript. On the other hand having the source code and being able to convert meaning also has it's plus sides.

I think for now I will go with scala-js but will keep an eye on the teavm people.

[Alexey Andreev]

I spent some time learning TeaVM to understand Scala. In fact, I had just to implement several JDK classes. Now TeaVM is capable of compiling Scala applications. Here is example, and its source code.

Well, I haven't written in Scala before today and I wanted to learn Scala. So I wrote a simple parser combinator (instead of using standard one), which is quite naive, with lots of non-tail recursion. Now we have something to compare to Scala.js. Can you guys rewrite this project for Scala.js (I believe, only DOM-specific code should be rewritten)? Can you propose any benchmark so that I could rewrite it for TeaVM?

 

Community

Even before talking about the technical comparison, I would highlight Scala.js' community. At first glance, it seems TeaVM has a very small community: 14 threads on the mailing list, that's about everything I could find. Scala.js has a very active community, notably on Gitter [1]. The community also develops many very good libraries besides just the compiler and the JDK, which help for front-end development in general and client/server communications. The community and ecosystem is what makes a different between a usable compiler and something on top of which you can actually build a project.

 Yes, that's a problem. However, building a community is not a technical task. As a purely technical guy, I have no idea how to build community. May be you tell me? :-) Yet TeaVM is not completely unknown. For example, CodenameOne guys ported their CodenameOne to JavaScript.

Technical side

At a first approximation, on the technical side, I would say that Scala.js' major advantages over TeaVM will be related to the fact that Scala is much closer to JS than Java is. Scala.js' interop with JavaScript is very natural because of that. The double OO and Functional paradigms are shared, not to mention the tendency to use asynchronous stuff such as Promises/Futures.

BTW, TeaVM does not need anything like promises/futures, since it can generate coroutines and emulates threads upon them.

There is even js.Dynamic for dynamically typed interop with JS, which I doubt you can achieve in Java. Moreover, primitive data types such as Ints and Strings are represented directly as primitive JavaScript values, and there is no boxing when they are put in generic data structures, which helps interop and performance.

TeaVM has its own interop library called JSO, which is very thin as well. In most cases it does not generate any wrappers, etc. So when you write window.getDocument(), you get window.document in JavaScript. However, strings are still wrapped unless they are string literals.

Performance-wise, I can't tell anything for real without explicit benchmarks of Scala.js vs TeaVM. But reasoning about it, I can say a few things, Scala.js supports the Scala standard library, and there are adaptations to it that make it more efficient on the JavaScript runtime (or make it work at all, in some cases), which you won't have if you use the Scala std lib with TeaVM.

Sorry, I can't understand this. Do you mean you've rewritten Scala libary so that in runs fast in JavaScript?

 

Scala.js also has a very good optimizer which is Scala-aware, so it will optimize Scala code much better than TeaVM ever could. In particular, higher-order methods are typically inlined away as while loops.

You mean lambda inlining? Well, sometimes I'll optimize them. 

[Sébastien Doeraene]

Hi Alexey,

On Sat, Oct 3, 2015 at 8:37 PM, Alexey Andreev <konsol...@gmail.com> wrote:

I spent some time learning TeaVM to understand Scala. In fact, I had just to implement several JDK classes. Now TeaVM is capable of compiling Scala applications. Here is example, and its source code.

Those are great news! Congratulations :-)
 

Well, I haven't written in Scala before today and I wanted to learn Scala. So I wrote a simple parser combinator (instead of using standard one), which is quite naive, with lots of non-tail recursion. Now we have something to compare to Scala.js. Can you guys rewrite this project for Scala.js (I believe, only DOM-specific code should be rewritten)?

Sure: there it is: https://github.com/sjrd/scala-js-teavm-examples

For your Scala fu, I have done some reformatting to more closely match generally accepted Scala coding guidelines.

 

Can you propose any benchmark so that I could rewrite it for TeaVM?

Our benchmarks are here: https://github.com/sjrd/scalajs-benchmarks They are ports of some of Octane to Scala.js, and we compare against the original, hand-written JS code.

To run them, you'll need a `node` or a `d8` on your PATH, and run

$ ./run.sh

Yes, that's a problem. However, building a community is not a technical task. As a purely technical guy, I have no idea how to build community. May be you tell me? :-) Yet TeaVM is not completely unknown. For example, CodenameOne guys ported their CodenameOne to JavaScript.

We were very lucky in that respect. After throwing some enthusiasm about Scala.js at Scala Days and later Scala eXchange 2013 myself, Li Haoyi stepped up and bootstrapped the community. Both by writing essential core libraries and testing frameworks, and by giving entertaining and compelling talks. Then it grew from there. I am not responsible for most of what's happened to the community ^^

Sorry, I can't understand this. Do you mean you've rewritten Scala libary so that in runs fast in JavaScript?

Parts of it, yes. The source files in https://github.com/scala-js/scala-js/tree/master/scalalib take precedence (override) those in the original Scala standard library. The structure is hierarchical, on Scala 2.11.5, for example, the files are picked by decreasing order of priority from overrides-2.11.5, overrides-2.11, overrides, and finally the original std lib. In some cases, the special changes are made in combination with dedicated optimizer intrinsics for ultimate power, for example https://github.com/scala-js/scala-js/blob/master/scalalib/overrides/scala/collection/mutable/ArrayBuilder.scala

Scala.js also has a very good optimizer which is Scala-aware, so it will optimize Scala code much better than TeaVM ever could. In particular, higher-order methods are typically inlined away as while loops.

You mean lambda inlining? Well, sometimes I'll optimize them.

I mean many things, including lambda inlining, yes. For example this code:

def doubleArrayElems(l: Array[Int]): Array[Int] = l.map(x => x * 2)

becomes:

$c_Lcalculator_Calculator$.prototype.doubleArrayElems__AI__AI = (function(l) {
  var t = $m_s_reflect_ManifestFactory$IntManifest$();
  var elems$2 = [];
  var i = 0;
  var len = l.u["length"];
  while ((i < len)) {
    var idx = i;
    var arg1 = l.u[idx];
    var elem = $imul(2, arg1);
    elems$2["push"](elem);
    i = ((1 + i) | 0)
  };
  return $makeNativeArrayWrapper($d_I.getArrayOf(), elems$2)
});

You can have a rough idea of the most important optimizations in this talk, which I gave at the VM Meetup 2015: https://www.youtube.com/watch?v=IvB1APFZK5Q

Cheers,

Sébastien