¿En qué me equivoco acerca de mi proyecto y estos marcos de JavaScript?


107

En primer lugar, lo más básico del proyecto que deseo crear es un motor wiki implementado como una aplicación web de una sola página. Planeo tener un conjunto de funciones disponibles desde el principio con muchas adiciones de funciones en el futuro.

Caracteristicas basicas

  • creación de página (crea un artículo wiki y un foro de discusión para ese artículo)
  • marcado y WYSIWYG ala markitup
  • conversión sobre la marcha entre marcado / html / WYSIWYG
  • una barra lateral para navegar rápidamente
  • una barra de herramientas superior para elegir editar / ver

Características avanzadas

  • barra lateral configurable para navegar a través de diferentes métodos
  • barra de herramientas configurable (posiblemente agregue el lenguaje de marcado de su elección)
  • etiquetas
  • tareas editables
  • arrastrar y soltar archivos subidos y adjuntos de imágenes

El motor originalmente consistiría en la creación de páginas, el marcado y la edición WYSIWYG y el guardado más básicos. Eventualmente me gustaría extender este motor básico con soporte de imágenes de arrastrar y soltar, carga de archivos, gráficos de datos en vivo y una barra lateral para personalizar las vistas.

He hecho una búsqueda bastante extensa de un proyecto decente en el que basar mi proyecto, pero aparte de TiddlyWiki, no parece haber ningún buen motor wiki basado en javascript. También consideré aplicar Jquery en la parte superior de los motores wiki existentes, pero creo que eventualmente terminaría reescribiéndolo de todos modos (además, es más emocionante agregar las funciones que quiero a medida que avanzo). De cualquier manera, he llegado a implementar esta bestia con una biblioteca + marco de javascript.

Sé que realmente no se pueden comparar algunos de estos marcos entre sí, ya que no son manzanas con manzanas. He intentado enmarcar cualquier comentario / pregunta de comparación con piezas comparables de los respectivos marcos, pero estoy abierto a ser corregido.

Así que, aquí vamos:

Basado en mi propia investigación y opiniones, he reducido la lista a los elementos siguientes. Dejé de lado intencionalmente cosas como SproutCore, corMVC, YUI y otras, ya que yo, en mi capacidad limitada, pensé que los elementos a continuación encajarían mejor.

Mis opciones


jquery / UI + backbonejs

En general

Por lo que he leído, esta combinación es utilizada y amada por muchos y es muy flexible y extensible. Mi mayor preocupación es que esta combinación simplemente no es el mejor punto de partida para desarrollar una interfaz de usuario más orientada al escritorio.

UI

Si bien jQueryUI o jqueryTools pueden ser competitivos, ciertamente no parecen estar a la par con las capacidades de interfaz de usuario de otros marcos. Específicamente, parecen tener muchos efectos, pero carecen de un soporte decente de corte de diseño.

javascriptMVC

En general

Para mí, JavascriptMVC parece que es esencialmente extensiones jquery + MVC (jqueryMX), junto con algunas otras aplicaciones para documentar (documentJS), pruebas funcionales (funcUnit) y gestión de código y dependencia (stealJS). Más allá de los beneficios del módulo adicional, creo que el debate funcional realmente se reduce a backbonejs frente a jqueryMX. ¿Estoy en lo cierto en esto y alguien ha trabajado o comparado con ambos?

UI

JavascriptMVC agrega los elementos MXUI encima de lo que esté disponible para Jquery, así que creo que al menos es una pequeña victoria en esa categoría.

knockoutjs

En general

Mis pensamientos y preocupaciones sobre esto son muy similares a los comentarios de jquery + backbone. Ambos parecen ofrecer características similares pero solo desde una perspectiva diferente. Un inconveniente que se cita a menudo es que knockoutjs combina la lógica empresarial y la presentación con demasiada fuerza con el enlace de datos y que este método de enlace puede romperse para una interacción compleja de la interfaz de usuario, pero me encantaría saber por qué eso no es un problema.

UI

En blanco por el momento

Dojo y ExtJS

En general

Voy a combinar la discusión Dojo y ExtJS porque sé lo que menos sobre ellos y parecen jugar casi en el mismo espacio. La mayor parte de la información sobre stackoverflow sobre estos dos parece estar desactualizada. Por lo que he visto, ambos son marcos grandes que son buenos para la implementación de aplicaciones de escritorio de calibre. Dojo había sido reprendido por una documentación deficiente, pero parece que ya no es así. ExtJS, por supuesto, tiene la licencia comercial, pero es realmente razonable para lo que obtienes y no lo reprocharía demasiado. Los widgets en ExtJS parecen estar hechos de manera algo más profesional que Dojo, pero ciertamente podría ser corregido allí. Me interesaría saber de alguien que tenga experiencia en ambos.

UI

Dojo tiene la biblioteca de IU de dijit ExtJS tiene características de IU pero no están en Ext core. Aquí está la documentación y aquí están sus demostraciones.

Capuchino

En general

Y luego está Cappuccino. Sin CSS, sin html, pero también podría ser difícil utilizar las bibliotecas de JavaScript existentes. Objective-J no parece dar miedo, especialmente si se tiene en cuenta que también pregonan poder escribir JavaScript sin formato. Las demostraciones son impresionantes y parecen acercarse de cerca a las necesidades de la interfaz de usuario del motor wiki. La API basada en cacao es mucho para alguien que no esté familiarizado con ella, pero tal vez valga la pena. He escuchado que no siempre es fácil trabajar con el motor de diseño, pero una tecnología joven y posiblemente disruptiva como esta ciertamente tendrá algunas deficiencias.

UI

En blanco por el momento

Me disculpo por escribir tanto, pero bueno, al menos no es una pregunta ax vs y vs z esperando toneladas de respuestas baratas. ¿Entonces, qué piensas? ¿Cuál debería ser la base de mi motor de escritorio como wiki, que con suerte se volverá más rico en funciones (lectura compleja) con el tiempo?


9
+1 para una pregunta increíblemente detallada y bien pensada.
Sean Vieira

8
No estoy seguro de su cronograma y recursos, pero cuando trato de decidir entre múltiples marcos / entornos, simplemente sigo adelante e intento construir rápidamente un prototipo. Incluso si se trata solo de una o dos funciones principales, encuentro que toda la investigación y documentación del mundo nunca coincidirá con el intento de construir algo con las herramientas. Yo digo que tómese un día con cada uno y vea hasta dónde llega. Eso le dará una buena indicación de qué herramientas están a la altura de la tarea y se sienten más cómodas para usted.
Brian Flanagan

1
@Brian Flanagan Pasar a una respuesta, incluso si es "meta".

1
¿Has mirado tiddlywiki.com ? Creo que es una wiki pura y autónoma hecha en JavaScript
Bernhard

Sí, he mirado tiddlywiki. En muchos sentidos, es la inspiración para este proyecto, pero tengo mi propia base y la dirección prevista para este proyecto.
funkyeah

Respuestas:


4

Sugeriría que primero se propongan requisitos específicos de IU para su proyecto. ¿Cuáles de los frameworks que has probado, has probado?

Personalmente, entré en el desarrollo de ExtJS porque los proyectos en los que trabajo requieren mucha personalización de controles / widgets. ExtJS tiene un montón de ellos desde el primer momento y siempre se pueden ampliar, combinar o incorporar a cualquier monstruosidad que requiera su negocio.

ExtJS 4 también le permite "cambiar la piel" de su interfaz de usuario para personalizar aún más la apariencia.

Si es nuevo en JavaScript y se siente cómodo con Java, incluso podría buscar una solución del lado del servidor como GWT , JSF o incluso Vaadin.


19

No estoy seguro acerca de su línea de tiempo y recursos, pero cuando intento decidir entre múltiples marcos / entornos, simplemente sigo adelante e intento construir rápidamente un prototipo. Incluso si se trata solo de una o dos funciones principales, encuentro que toda la investigación y documentación del mundo nunca coincidirá con el intento de construir algo con las herramientas. Yo digo que tómese un día con cada uno y vea hasta dónde llega. Eso le dará una buena indicación de qué herramientas están a la altura de la tarea y se sienten más cómodas para usted.


6

está de moda hoy en día (el marco de JavaScript de pila completa con más estrellas en GitHub y Meteorpedia es un motor wiki escrito en Meteor.

El video de lanzamiento lo enganchará a la 1:28.

Es agnóstico con respecto a la interfaz de usuario, y ha sido probado extensamente con Bootstrap y Famo.us . También genera aplicaciones móviles a partir de la misma base de código.


1
Y hay integraciones con React, pero eso es solo para personas que están al 100% en él. Tampoco hay problemas para usar los complementos de jquery y las bibliotecas de dibujo svg / canvas sin mucho conocimiento sobre Meteor.
imslavko

1

Es posible que su elección de marco no restrinja sus opciones de interfaz de usuario tanto como puede imaginar. Este artículo reciente de Henri Bergius sobre desacoplar la gestión de contenido ilustra el punto mucho mejor de lo que yo podría y, dicho sea de paso, enlaza a un editor de contenido in situ de JavaScript puro (independiente del marco) de aspecto bastante atractivo .


Ciertamente estoy cavando el editor aloha para WYSIWYG. Definitivamente lo acoplaría en la parte superior de la pantalla y agregaría pestañas para ver el área de texto en el marcado de algún formato también. Mi otra opción principal sería un poco de markItUp .
funkyeah

1

¡No estas solo!

VanillaJS y Ampersand ... son excelentes ejemplos del impulso serio de JavaScript más simple y modular.

Incluso hay un libro al respecto.

La simplicidad está impulsada por una característica de es6 infravalorada: los módulos y el estándar de implementación SystemJS . Incluso se puede utilizar en sistemas que no sean es6.

¡Cuan genial es eso!


1

Yo diría que está equivocado en su elección general de candidatos, ya que está omitiendo Angular y Ember, que son más adecuados que cualquiera de los otros marcos enumerados.

En general, diría que Angular.js es el marco para este.

Énfasis en el enrutamiento

Gran parte de lo que está hablando (varias barras laterales para la navegación, una aplicación de una sola página) son funciones de enrutamiento o cómo la interfaz interpreta el texto en la barra de navegación de su URL.

Tanto Angular.js como Ember tienen excelentes enrutadores que le permiten lograr todo lo que necesita sin código adicional.

Para su beneficio, aquí hay un desglose rápido de las características en Angular que se pueden usar para crear su wiki de una sola página.

La estructura del sitio en sí

Angular tiene una biblioteca increíble llamada enrutador de interfaz de usuario que le permite crear una navegación personalizada y configurar una estructura compatible con SEO para revelar su contenido. Varias vistas también permitirían una barra de herramientas superior.

Tutorial del enrutador de interfaz de usuario: http://cacodaemon.de/index.php?id=57

Editor WYSIWYG

Angular se basa en un enlace bidireccional en vivo (cuando cambia algo en algún lugar, cambia automáticamente en cualquier otro lugar). Por lo tanto, viene con muchas características que funcionan bien con este tipo de editor. Ya se han hecho algunos buenos y solo necesita implementarlos.

http://textangular.com/

Gráficos y otras cosas interesantes

Las directivas angulares están diseñadas para hacer cosas como crear componentes de gráfico que sean reutilizables. No son totalmente diferentes a los widgets de Wordpress. Muchos de estos ya se han desarrollado y se pueden colocar en su proyecto Angular.

http://www.sitepoint.com/creating-charting-directives-using-angularjs-d3-js/

Respecto a Ember, no sé mucho al respecto, por lo que no puedo hablar de sus características particulares.


0

Una sugerencia sobre Backbone, si decides usarlo, deberías optar por Marionnete ya que es Backbone pero con una mejor estructura arquitectónica y más obstinado (personalmente creo que Backbone no establece ninguna pauta y eso se siente como un inconveniente en las aplicaciones grandes) .

Trabajé con él durante unos meses combinando diferentes js libs y no se interpone en su camino como otros marcos y la canalización de mensajes es una muy buena manera de conectar componentes a través de la aplicación pero mantenerlos desacoplados.

Aquí tienes una gran charla que me hizo decidirme: https://www.youtube.com/watch?v=qWr7x9wk6_c

Y aquí tienes un prototipo de demostración que también tiene el elemento de arrastrar y soltar más otras bibliotecas js conectadas. Me encantaría saber lo que piensas sobre mi código, ya que llevo 1,5 años trabajando en desarrollo web ... todavía soy un novato: https://github.com/Drasky-Vanderhoff/marionette-demo/

Acerca de Knockout, es realmente bueno si desea interactuar con el contenido que ya tiene y no se conectará constantemente con el backend. Trabajé con él durante 6 meses y termino necesitando usar muchas otras librerías js para enrutamiento; además termino repitiendo muchas de las estructuras que terminan teniendo Backbone y otros JS Frameworks. Lo que diré es que no se interpondrá en su camino y será una herramienta en lugar de una restricción. Además, esto fue hace casi un año, por lo que algunas cosas han cambiado.

Una cosa, si encuentra Knockback (Knockout + Backbone) ... evítelo, la documentación no es tan buena como debería ser y le llevará mucho más tiempo aprenderla. Si quieres hacerlo, primero haz un prototipo rápido para ver si es lo que quieres.


Ha pasado un año desde que publicaste esto. Como estoy buscando comenzar un nuevo desarrollo ahora, ¿Marionette sigue siendo su mejor opción para el desarrollo de Javascript?
AlVaz

En absoluto, ahora mismo es mejor hacerlo con Angular.js o React.js (puedes combinar ambos si quieres). Si desea una versión móvil y web para una aplicación, le sugiero encarecidamente que use React.js, ya que React Native se está utilizando para crear aplicaciones nativas de iOS y Android. Tanto React.js como native comparten los mismos conceptos, estructuras y paradigma (es Aprender una vez, usar en todas partes, Conocer React.js == React Native, sí, no estoy usando triples iguales: P)
DraskyVanderhoff

También hay componentes web que utilizan Polymer que le sugiero encarecidamente que lo revise si quiere trabajar con probablemente el marco más popular el próximo año. Por último, Meteor es una excelente opción si necesita sincronización de datos 100% en tiempo real / enlace de datos de tres vías, especialmente porque si escribe validadores para parámetros, ejecutará el mismo validador tanto en el backend como en el frontend, evite la necesidad de tener 2 códigos bases que son iguales.
DraskyVanderhoff

Una aclaración, nunca dije que Marionette era mi primera opción (en realidad era Angular en ese momento) lo que dije fue que SI vas a usar Backbone.js, ELLOS usa Marionette.js en su lugar.
DraskyVanderhoff
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.