html5 - framework - javascript ui
Frameworks de UI HTML5 (2)
Encontré muchos frameworks UI HTML5, como:
Estoy un poco abrumado con tantos recursos por ahí. Parecía que algunos de ellos, pero casi todos parecían demasiado lentos y pesados.
Me estoy confundiendo acerca de cuál aprenderé. Cada uno de sus sitios web habla de su producto como si fuera el mejor en el mercado. (estrategias de marketing obvias).
Como principiante en desarrollo de aplicaciones web y marcos de interfaz de usuario JS en el lado del cliente; Ustedes, en base a su experiencia, ¿cuál recomiendan para el desarrollo rápido de aplicaciones web de escritorio teniendo en cuenta la velocidad, las colecciones de widgets, la complejidad, la apariencia, el soporte, etc.?
¿Cuál me recomiendan para comenzar a aprender?
Sé que podría haber muchas respuestas y cada una podría preferir otras diferentes, pero esto podría ayudarme a guiarme un poco y criticar algunos de los marcos más populares.
Hay tanto en su pregunta, que la respuesta no será fácil y no será definitiva en absoluto. También será muy obstinado. Mirando la lista de marcos que trajiste, veo cosas muy diferentes que difícilmente se pueden comparar entre sí. Trataré de agruparlos de alguna manera y agregar más marcos a la lista.
La pregunta principal aquí no son los pros y los contras de un marco particular. La pregunta principal es: ¿cuánto quieres ? ¿Realmente quisiste decir una aplicación como Gmail o Grooveshark? ¿O quiso decir algo como , un sitio dinámico y para nada simple, pero aún así un sitio web? Consideremos todas estas opciones.
Tal vez, solo desea mejorar su sitio web con algunos widgets, como pestañas, cuadros de diálogo, algunos elementos arrastrables / desplegables, edición de texto, etc. y no está dispuesto a cambiar su modelo de desarrollo. Quiero decir, usas tu Java / PHP / Ruby favorito y no deseas escribir muchas de las lógicas y el comportamiento de tu aplicación en JavaScript. En este caso, las soluciones tipo plugin basadas en jQuery lo harán por usted, particularmente, jQuery UI y jQuery Mobile .
Los widgets jQuery siguen su sistema de complementos. Esto generalmente significa que son extremadamente fáciles de usar. Para crear un botón, escribes:
$(''#myButton'').button();
Ahora, si desea deshabilitarlo, llame a un método usando el siguiente patrón:
$(''#myButton'').button(''disable'');
Y obtener o establecer valores, por ejemplo, en el control deslizante o datepicker, se ve así:
$(''#mySlider'').slider(''value'');
$(''#mySlider'').slider(''value'', 42);
Como ve, las soluciones basadas en jQuery no tienen modelo. Todos sus datos se guardan en DOM y se obtienen a través de llamadas a métodos extravagantes. Si necesita procesar dinámicamente sus datos, por ejemplo, realizar validaciones complejas, cargar algo en segundo plano, filtrar u ordenar, entonces verá que esto pronto se volverá complicado. Por cierto, este es el problema por el que el equipo de jQuery UI aún no ha proporcionado un control de red: no pueden hacerlo sin un modelo. En jQuery Mobile obtienes una buena interfaz de usuario móvil por medio de un marcado simple, pero no hay forma oficial de pasar datos entre páginas.
Resumiendo esto: si tiene un sitio web de varias páginas, si PUBLICA sus formularios, entonces use jQuery UI o una solución más liviana como Twitter Bootstrap .
Quizás, desea construir algo más complejo, más parecido a una aplicación (¿una aplicación de una sola página?). Sabes que deberás trabajar con datos del lado del cliente. ¿Cuáles son tus opciones entonces?
Puede utilizar uno de los muchos marcos de JavaScript que le proporcionan modelos, enlaces de datos y, probablemente, otros medios para crear aplicaciones web e integrarlas con la interfaz de usuario jQuery. O puede usar un marco más completo como Kendo o Wijmo o jqWidgets . Estos marcos se basan en jQuery (Wijmo se basa en jQuery UI) y proporcionan medios adicionales para la manipulación de datos. Ellos tienen un modelo de datos. Kendo implementa su propia solución (creo), mientras que Wijmo y jqWidgets se integran con el popular Knockout JS.
Así que Kendo y Wijmo pertenecen al grupo de marcos que proporcionan widgets / controles y algún modelo de respaldo. Hay otros marcos como estos, que no están basados en jQuery, por ejemplo, Dojo Toolkit . Agregue un poco de carga de datos dinámica y obtendrá una aplicación web algo compleja. ¿Qué más puedes desear?
En realidad, lo más importante es olvidado: ¿cómo estructura (organiza) su aplicación? Si intentas construir una aplicación de una sola página que se comunique con el servidor de manera RESTful, pronto te encontrarás en un lío si tu aplicación no tiene arquitectura. Las características que generalmente se requieren para esto son algunas cuestiones relacionadas con la separación (MVC, MVVM), la creación de plantillas, el enrutamiento y la administración de módulos. Aquí es donde aparecen SproutCore y Sencha . Proporcionan una solución integral para crear aplicaciones web, donde los widgets son solo una pequeña parte.
Puede parecer que SproutCore y Sencha son los ganadores aquí, porque son las soluciones más completas que incluyen tanto la interfaz de usuario como las lógicas comerciales y también estructuran su aplicación. A pesar de todos los pros, hay algunos contras. Algunos dicen que son demasiado pesados o necesitarán adherirse a su modelo de desarrollo, que puede que no te guste. Por ejemplo, en Sencha describe su GUI en JavaScript y usa el sistema de tipos de Sencha. Esto agrega una especie de sentimiento pesado de que hay abstracciones y envoltorios, mientras que realmente te gusta la facilidad de HTML, CSS y JavaScript vanidoso.
Pero esta no es la única forma. El poder de la web es que hay muchos marcos, bibliotecas, herramientas, smaller y más grandes, que te ayudarán a crear tu aplicación de la manera que te guste. Por ejemplo, considere AngularJS . No proporciona un conjunto de controles en sí, pero combinado con Twitter Bootstrap se convierte en una solución completa para RIA. O, por ejemplo, mira EmberJS , un framework más ligero del tipo que creó el peso pesado SproutCore. Tampoco le proporciona un conjunto de widgets, pero, en mi opinión, es una muy buena base para una aplicación.
Así que aquí está mi pensamiento final en lugar de la conclusión. Todos esos marcos generalmente muestran su conjunto de widgets, temas que se ven bien y otras cosas visuales. Pero lo que realmente importa es cómo desarrollarás tu aplicación, cómo la estructurarás, dónde implementarás tu lógica. Conozca lo que ofrece el marco y piense si puede sustituir lo que falta.
La respuesta de Infeligo es de primera clase. Mi experiencia puede ser de interés para algunos. Uso Ruby on Rails como mi plataforma de servidor donde reside la mayor parte de mi lógica comercial.
En el front end uso dHTMLX, que es una biblioteca JS de ''objetos'', el más poderoso de los cuales es su objeto de grilla. La mayoría de mis aplicaciones tienen requisitos de procesamiento / visualización de información empresarial / contable y el objeto de la cuadrícula es mi pilar principal allí. Sin embargo, su conjunto de objetos es completo, incluida la capacidad de crear "ventanas" adicionales dentro de la única aplicación para proporcionar una interfaz de tipo MDI para el usuario final. Por lo general, tengo un formulario de inicio de sesión que cuando se aplica con éxito abre una sola página HTML con un menú en la parte superior. Según la selección del menú, se abren y cierran ventanas nuevas para mostrar / manipular información. Estas ventanas están dentro del alcance de la página HTML única.
Todos los objetos tienen muy buenos eventos asociados y hago bastante validación en la parte delantera usando estos eventos. Sin embargo, generalmente también duplico toda validación de datos dentro del Modelo Rails. Es un trabajo adicional, pero soy más cauteloso. También hay una serie de objetos abstractos que ayudan a conectar datos entre los objetos visuales frontales, por ejemplo, la red y el servidor back-end. La mayoría de las conexiones de datos se pueden hacer usando XML o JSON. Uso XML sobre JSON simplemente por mi experiencia con esa estructura y por el hecho de que Rails proporciona un constructor XML decente. Por lo tanto, en mi caso, raramente utilizo vistas basadas en Rails ya que todos mis objetos visuales provienen de dHTMLX.
La otra cosa que me gusta de dHTMLX es la velocidad de sus objetos. Por ejemplo, el objeto de cuadrícula manejará fácilmente más de 10.000 filas a velocidades muy aceptables.
El GRAN DESCENSO de la suite es su documentación. La compañía es un desarrollador de Europa del Este y por lo tanto, a menudo es difícil entender exactamente lo que significa su documentación. Además, su documentación tiende a no documentar todo por completo, por lo que se desperdicia mucho tiempo en el aprendizaje de tipo de prueba y error.
Espero que esto ayude