18

What is the difference between these Scala.js React.js libraries and why should I choose one over the other ?

  1. Xored Scalajs-react - Last commit was 8 months ago. So I'm guessing the development is not active anymore.
  2. Scalajs-react - Very active and very complete and comes with a custom URL Router. But the API's seems to be stepping away from the way actual Javascript React code is written and there is no support for React-native and the addition of Scalaz and Monocle fattens up the library increases the size of Javascript that browser has to download. The document says Scalaz & Monocle are opt-in, so I'm guessing by default Scalaz & Monocle are excluded ? I personally feel that this library could just be a very simple facade to the React.js code which would have made it easier to update to newer version React.js and it not being a simple facade means more Javascript code that will get generated and more code the browser will have to download. I may be wrong here, please correct me ?
  3. SRI - Newcomer and the facades looks very much complete and has support for Web, Relay and React native but have no URL Router support and no DOM DSL. The facade APIs looks very lean and very similar as writing Javascript React.js code. But it is fairly new and may be not production ready ?

Please correct me if I am wrong as there are too many options to choose here and wish there was one way to write React.js code in Scala.js.

user794783
  • 3,619
  • 7
  • 36
  • 58
  • 1
    There is a fork of the xored project that shows some dev activity [kanterov/scala-js-react](https://github.com/kanterov/scala-js-react). – MxFr Oct 15 '15 at 13:46

3 Answers3

18

As of October 2015:

  • I also conclude that xored/scala-js-react is not actively developed at the moment. The approach used for templating is to keep an XML syntax a la JSX, which I do like in some ways, in particular because it makes the code look more like plain React. UPDATE: @MxFr pointed to a fork with a little bit of activity.
  • There is no doubt that as japgolly/scalajs-react is under active development. Support for React 0.14 is coming. The approach is to use a custom version of lihaoyi/scalatags for templating instead of an XML syntax. This has the drawback of making the code look a bit weird at first, but you get used to it and it provides a good level of type-safety.
  • chandu0101/sri is new and wants to be more of a cross-platform solution (web, Android, iOS). There is a discussion about making chandu0101/sri use japgolly/scalajs-react, and the author of sri seems particularly interested in doing so based on that conversation.

Based on the above, the most attractive solution right now is japgolly/scalajs-react, keeping in mind that things change quickly in this space.

Community
  • 1
  • 1
ebruchez
  • 7,760
  • 6
  • 29
  • 41
16

I'm the author of scalajs-react so my comments about the other two libs will be much less informed, hopefully not wrong, but here we go.

  • scalajs-react - Goal is to provide the best Scala experience and type-safety. Comes with many Scala goodies, performance utils, support for FP, lenses etc. (all optional.) Focus is React for the web.

  • xored - Goal looked to me to be usage close as possible to JSX in Scala.

  • Sri - Goal looks to me to be covering the most JS ground (even Relay) and being as close to JS as possible.

There are other details of course, (comment above mentioned scalajs-react using React.createClass instead of extending React.Component but that's a trivial implementation detail that could be changed in 10 min without breaking Scala backward-compatibility - I wouldn't worry about that), but rather than the details, I believe the project-level philosophy should be your deciding factor. If you want to be close to JS without fuss, use Sri; if you want type-safety and the Scala experience to be the priority, use scalajs-react.

Also scalajs-react will split its core module into core and dom to match React. I wouldn't hold my breath on a native module being added unless someone in the community makes it happen. On the other hand, Sri does web & native already and I know @chandu (one of the Sri authors) has long been playing around with native so it should get much support and refinement over Sri's lifespan.

I personally feel that this library could just be a very simple facade to the React.js code which would have made it easier to update to newer version React.js

Yeah but a simple facade isn't what I want. I want a facade that I can trust my code will always work - many things can trip up React, over time all those fine-print rules and runtime issues get embedded into facade types so that scalac can watch out for us.

(Also the decision to skip upgrading to React 0.13 wasn't due to difficulty. scalajs-react got React 0.14 support within days of its release (currently on scalajs-react v0.10-RC1).)

not being a simple facade means more Javascript code that will get generated and more code the browser will have to download.

Yes, true, but we're probably only talking about a few KB here. Using Scala.JS at all adds like 150KB+, and its optimiser is very good at excluding code you don't use.

Hope that helps! Choice is a good thing.

Golly
  • 1,319
  • 8
  • 18
11

With Sri you can develop both web and mobile apps where as scalajs-react/Xored Scalajs-react are web centric.I never used Xored Scalajs-react so can't comment on that.Now question is Sri-web vs scalajs-react

Sri-web vs Scalajs-React

For any scala react web app we need 3 core principles 1) way to define React components/elements 2) Some inbuilt components/primitives/building blocks 3) a router

1) Defining React components/elements :

Scalajs-react has well designed API ReactComponentB but it's based on old React.createClass ,Sri has ElementFactory based on new React ES6 class React.Component. In general React.Component is faster than React.createClass, as of react 0.14 i prefer to use React.Component over React.createClass unless u badly need mixin's. That being said we're discussing on combining ReactComponentB and ElementFactory in common project.

2) Basic building blocks/primitives :

Scalajs-react comes with dom-dsl(you have entire dom elements/attributes to choose from). Sri also comes with dom dsl and react-native-web components.

3) Router :

Scalajs-react has url based router. Sri has UniversalRouter which works both on mobile and web but it doesn't support urls, and a URL based WebRouter.

Ofc scalajs-react has many other helpers and cool FP stuff.If any one disagree with my views please feel free to start a discussion i am more than happy to know new things :)

Finally hope we'll have a common core project (1) soon so that users can choose/switch renderers based on their taste buds, at the end of the day scala.js should win :)

Edit: btw i am author of Sri :)

Edit2: updated router section as sri 0.4.0 has a url based webrouter.

Edit3: updated build blocks section as sri 0.6.0 has dom dsl now.

invariant
  • 8,758
  • 9
  • 47
  • 61
  • 1
    Just a nit: On SO it is customary to disclose affiliations to relevant projects. So it would be good to mention that you are the author of Sri (especially since this is not obvious from you SO name). – gzm0 Oct 15 '15 at 09:17