- Type declarations
- Classes / Traits / Case-Classes
- Code modularization
- IDE support
Github repo: https://github.com/lampepfl/scala-js.
And more info here.
- Covers the whole Scala language
- Covers a good part of the Scala/Java library
- Can re-use existing Scala SBT projects
- Generates source-maps for Scala
- jQuery and DOM (statically-typed) wrappers available
- It’s a LAMP EPFL initiative, endorsed by M. Odersky
Github repo: https://github.com/nau/jscala .
- Trivial to set up
- Generates code quickly on the fly
- Easily integrated in existing Web Frameworks (e.g. Play)
- Covers only a subset of Scala</span>
- Covers only basic parts of the library (relies on JS for the rest)
- Not trivial to modularize/share code
- Cryptic macro-expansion error messages
Note that although listed as a disadvantage, the fact that it only covers a subset of Scala and its library might be one of the reasons why code generation is so fast and clean. Being lightweight has its advantages.
Why can’t they collaborate?
This is one obvious question to arise when reading about these two frameworks. It would seem that the project leads are duplicating effort… But in the words of Sèbastien Doeraene, creator of Scala.js:
So all in all, the job of our respective translation phase is actually very different: not the same input, not the same output!
[…] So, I’m afraid we live in worlds that are too different, and that, despite the seemingly related job, we cannot share code effectively.
Which one to use?
This is something very subjective. The first thing I would say is: use whichever approach you feel more comfortable with, and what best suits your needs. My personal opinion would be to use: