scala.js scalajs-react

scala.js - Scalajs-reaccion VS Xored Scalajs-reaccion VS SRI



scalajs-react (3)

A partir de octubre de 2015:

  • También concluyo que xored/scala-js-react no está desarrollado activamente en este momento. El enfoque utilizado para las plantillas es mantener una sintaxis XML a la JSX, que me gusta de alguna manera, en particular porque hace que el código se parezca más a simple Reacción. ACTUALIZACIÓN: MxFr señaló un kanterov/scala-js-react con un poco de actividad.
  • No hay duda de que Scalajs-react está en desarrollo activo. El soporte para React 0.14 se acerca. El enfoque es utilizar una versión personalizada de lihaoyi/scalatags para lihaoyi/scalatags plantillas en lugar de una sintaxis XML. Esto tiene el inconveniente de hacer que el código parezca un poco extraño al principio, pero se acostumbra a él y proporciona un buen nivel de seguridad de tipos.
  • SRI es nuevo y quiere ser más una solución multiplataforma (web, Android, iOS). Hay una discussion sobre cómo hacer que SRI use Scalajs-react , y el autor de sri parece particularmente interesado en hacerlo basándose en esa conversación.

Sobre la base de lo anterior, la solución más atractiva en este momento es Scalajs-react , teniendo en cuenta que las cosas cambian rápidamente en este espacio.

¿Cuál es la diferencia entre estas bibliotecas Scala.js React.js y por qué debo elegir una sobre la otra?

  1. Xored Scalajs-react - El último compromiso fue hace 8 meses. Así que supongo que el desarrollo ya no está activo.
  2. Scalajs-react : muy activo y muy completo, y viene con un enrutador de URL personalizado. Pero los API parecen estar alejándose de la forma en que se escribe el código React de Javascript real y no hay soporte para React-native y la adición de Scalaz y Monocle engorda la biblioteca aumenta el tamaño de Javascript que el navegador tiene para descargar. El documento dice que Scalaz y Monocle son opcionales, así que supongo que, por defecto, ¿están excluidos Scalaz y Monocle? Personalmente, creo que esta biblioteca podría ser simplemente una fachada muy simple para el código React.js, lo que habría facilitado la actualización a la versión más reciente de React.js y no ser una fachada simple significa más código Javascript que se generará y más Código que el navegador tendrá que descargar. Puede que me equivoque aquí, por favor corríjame
  3. SRI : Newcomer y las fachadas se ven muy completas y tienen soporte para Web, Relay y React native, pero no tienen soporte de enrutador de URL ni DOM DSL. Las API de fachada se ven muy magras y muy similares a la escritura de código Javascript React.js. ¿Pero es bastante nuevo y puede que no esté listo para la producción?

Corríjame si me equivoco, ya que hay demasiadas opciones para elegir aquí y desearía que hubiera una forma de escribir el código React.js en Scala.js.

Con Sri puede desarrollar aplicaciones web y móviles donde, como scalajs-react / Xored Scalajs-react, están centrados en la web. Nunca usé Xored Scalajs-react, así que no puedo comentar al respecto. Ahora la pregunta es Sri-web vs scalajs-react

Sri-web vs Scalajs-React

Para cualquier aplicación web de Scala Rea necesitamos 3 principios básicos 1) una forma de definir Reaccionar componentes / elementos 2) Algunos componentes / primitivos / bloques de construcción incorporados 3) un enrutador

1) Definiendo los componentes / elementos de React :

Scalajs-react tiene un API ReactComponentB bien diseñado, pero se basa en el antiguo React.createClass , Sri tiene ElementFactory basado en la nueva clase React ES6 React.Component . En general, React.Component es más rápido que React.createClass , a partir de la versión 0.14, prefiero usar React.Component en lugar de React.createClass, a menos que U mal necesite la mixin. Dicho esto, estamos discussion sobre la combinación de ReactComponentB y ElementFactory en un proyecto común.

2) Bloques básicos de construcción / primitivos:

Scalajs-react viene con dom-dsl (tiene elementos / atributos dom completos para elegir). Sri también viene con los componentes dom dsl y react-native-web.

3) Enrutador:

Scalajs-react tiene enrutador basado en url. Sri tiene UniversalRouter, que funciona tanto en dispositivos móviles como en la web, pero no es compatible con las URL y un WebRouter basado en URL.

Ofc scalajs-react tiene muchos otros ayudantes y cosas geniales de PF. Si alguien no está de acuerdo con mis puntos de vista, siéntase libre de comenzar una discusión. Estoy más que feliz de saber cosas nuevas :)

Finalmente, espero que tengamos un proyecto básico común (1) pronto para que los usuarios puedan elegir / cambiar los renderizadores según sus papilas gustativas, al final del día scala.js debería ganar :)

Edición: por cierto soy autor de Sri :)

Edit2: la sección de enrutador actualizada como sri 0.4.0 tiene un enrutador web basado en url.

Edit3: se actualizó la sección de bloques de compilación ya que sri 0.6.0 tiene dom dsl ahora.

Soy el autor de scalajs-reaccion, por lo que mis comentarios sobre las otras dos bibliotecas estarán mucho menos informados, ojalá no estén equivocados, pero aquí vamos.

  • scalajs-react : el objetivo es proporcionar la mejor experiencia y seguridad de tipo para Scala. Viene con muchas golosinas de Scala, utilidades de rendimiento, soporte para FP, lentes, etc. (todo opcional). El enfoque es React para la web.

  • xored : el objetivo me parecía ser el uso más cercano posible a JSX en Scala.

  • Sri - Goal me mira para cubrir la mayor cantidad de JS (incluso Relay) y estar lo más cerca posible de JS.

Por supuesto, hay otros detalles (comente el scalajs-react mencionado anteriormente usando React.createClass lugar de extender React.Component pero ese es un detalle de implementación trivial que podría cambiarse en 10 min sin interrumpir la compatibilidad de Scala, no me preocuparía eso) , pero en lugar de los detalles, creo que la filosofía a nivel de proyecto debe ser su factor decisivo . Si quieres estar cerca de JS sin problemas, usa Sri; Si desea que la seguridad de tipos y la experiencia de Scala sean la prioridad, use scalajs-reaccion.

También scalajs-reaccion dividirá su módulo central en core y dom para que coincida con React. No contengo la respiración en un módulo nativo que se agrega a menos que alguien en la comunidad lo haga posible. Por otra parte, Sri ya tiene web y nativo, y sé que @chandu (uno de los autores de Sri) ha estado jugando con nativos durante mucho tiempo, por lo que debería recibir mucho apoyo y refinamiento a lo largo de la vida de Sri.

Personalmente, creo que esta biblioteca podría ser simplemente una fachada muy simple para el código React.js, lo que hubiera facilitado la actualización a la versión más reciente React.js

Sí, pero una fachada simple no es lo que quiero. Quiero una fachada en la que pueda confiar que mi código siempre funcionará. Muchas cosas pueden tropezar. Reaccionar, con el tiempo, todas esas reglas de letra pequeña y los problemas de tiempo de ejecución se incorporan a los tipos de fachada para que scalac pueda cuidarse.

(Además, la decisión de omitir la actualización a React 0.13 no se debió a la dificultad. Scalajs-react obtuvo el soporte de React 0.14 a los pocos días de su lanzamiento (actualmente en scalajs-react v0.10-RC1)).

no ser una fachada simple significa más código Javascript que se generará y más código que el navegador tendrá que descargar.

Sí, es cierto, pero probablemente solo estamos hablando de unos pocos KB aquí. El uso de Scala.JS agrega 150KB + y su optimizador es muy bueno para excluir el código que no usa.

¡Espero que ayude! La elección es algo bueno.