GWT vs Dart: ¿cuáles son las principales diferencias? ¿Dart es un reemplazo potencial de GWT?
(4)
Intento entender cuál de los dos usar, teniendo cuatro criterios principales
- Escritor mejor, código JavaScript de cliente mantenible, con facilidad de IDE moderno (mejor asistencia de contenido, mejor depuración)
- Navegador Cruzado
- Menos lock-in, puede leer el código
- Tecnología que es más probable que sea compatible en el futuro (más difícil de decir)
¿Cuáles son las principales diferencias entre las dos tecnologías?
Ambos parecen tener casos de uso similares, y la misma comunidad potencial de desarrolladores
¿Parece que GWT eventualmente será reemplazado por Dart? ¿Alguno signes sugiere esto?
¿O me estoy perdiendo algo y son conceptos completamente diferentes?
Se espera que Dart haga un mejor trabajo al cerrar la brecha cliente / servidor que GWT, ya que fue diseñado desde el principio para compilarse en JavaScript, resolviendo así el problema principal con GWT-RPC (es decir, GWT-RPC solo puede serializar un pequeño subconjunto de Java , Dart no tiene este problema).
Nunca he visto o encontrado este problema. Puede serializar con facilidad todos los tipos y la mayoría de las estructuras de datos en java.util. *. ¿Qué más quieres o necesitas?
Creo que el objetivo principal de Dart no es reemplazar los compiladores fuente a JavaScript como GWT, sino reemplazar el propio JavaScript. Tiene que hacer eso para bases de códigos de mantenimiento enormes, y para un mejor rendimiento, y un montón de otras razones, supongo.
Está más fuertemente tipado, y ha tomado prestados muchos conceptos de Java y otros idiomas.
En lo que respecta a predecir el futuro, es posible que pueda ver cómo está Dart contra JavaScript en Google Trends.
Creo que lo encontré: (debería haber leído las preguntas frecuentes de Dart primero, en lugar de buscar en Google "GWT vs Dart")
De: http://www.dartlang.org/support/faq.html#future-for-GWT
P. ¿Cuál es el futuro de GWT?
Bruce Johnson publicó en el blog de GWT (con más comentarios sobre Plus): "Dart y GWT comparten el objetivo de permitir la programación web estructurada. De hecho, muchos de los mismos ingenieros que le trajeron GWT están trabajando en Dart. una evolución ambiciosa de la misión de GWT para mejorar las aplicaciones web para los usuarios finales, y somos optimistas sobre su potencial. A medida que Dart evoluciona y se prepara para el horario de máxima audiencia, anticipamos trabajar estrechamente con la comunidad de desarrolladores de GWT para explorar Dart ".
"Mientras tanto, puede estar seguro de que GWT continuará siendo una forma productiva y confiable de crear las aplicaciones web más ambiciosas, e incluso juegos como Angry Birds. Los proyectos clave dentro de Google dependen de GWT todos los días, y tenemos la intención de seguir mejorando (y abrir -sourcing) GWT basado en sus necesidades del mundo real ".
Dart principalmente existe para resolver dos problemas
- Proporcione un lenguaje del lado del cliente que permita a los desarrolladores construir grandes aplicaciones sin los dolores asociados normalmente con las aplicaciones de JavaScript grandes.
- Utilice el mismo idioma cliente y servidor (es decir, el SDK de Dart será, en el futuro, similar a NodeJS).
De esta forma, resuelve algunos de los problemas de GWT (que acortan la brecha entre el cliente y el servidor) y algunos de los problemas resueltos por CoffeeScript (un lenguaje moderno adecuado para el desarrollo a gran escala).
Se espera que Dart haga un mejor trabajo al cerrar la brecha cliente / servidor que GWT, ya que fue diseñado desde el principio para compilarse en JavaScript, resolviendo así el problema principal con GWT-RPC (es decir, GWT-RPC solo puede serializar un pequeño subconjunto de Java , Dart no tiene este problema).
Si será mejor que CoffeScript es una discusión diferente, pero ahora sus capacidades mejoradas de depuración (es decir, ejecutarlo directamente dentro de Chrome) está demostrando ser una gran ventaja para el desarrollo de aplicaciones web a gran escala (como GWT lo hace con su modo dev).