En realidad, está haciendo más de una pregunta. Actualmente estoy analizando la pregunta "¿qué marco debo usar?" Para nuestra empresa. Esto implica mucho más de lo que piensas. Debajo está lo que tengo hasta ahora y, a medida que obtengo más información, intentaré actualizar este ítem.
Mientras tanto ...
La cuestión de los patrones arquitectónicos es diferente de la de las bibliotecas o los marcos.
ARCHITECTURAL DESIGN PATTERNS son útiles por muchas razones. Una razón sería lograr un acoplamiento flexible en sus módulos. Un gran ejemplo de cómo lograr un acoplamiento flojo se encuentra en el Mediator Pattern.
La cuestión de cuál es el marco a utilizar tiene muchos puntos de decisión:
Pruebas de velocidad:
Estos son Lo que considero MARCOS:
he decidido limitar mis opciones de marco para:
- Dojo: Kit de herramientas, de escritorio, móviles, gráficos & Vectoring
- YUI: Herramientas de Desarrollo, Infraestructura, Servicios Públicos, Reproductores, galería , Proyectos
- jQuery: Core, UI, Mobil, Complementos, Graficación, Visualización
... Pero también se necesita un desglose de las bibliotecas de Javascript:
MVC es el patrón de front-end más comúnmente utilizado. Sin embargo, mis notas aquí aún no están completas. Incluso estoy teniendo problemas para encontrar estadísticas de uso en los artículos enumerados anteriormente.
Backbone.js (MVC)
Diseñado más hacia el consumo de datos REST. Backbone tiene su propio sistema de eventos, y por lo tanto, compite con la funcionalidad de jQuery.
Spine.js (MVC)
JavaScriptMVC (MVC)
MVC integra herramientas de desarrollo; se usa con jQuery; Altamente modular Todavía no estoy seguro de si se puede considerar simplemente una biblioteca o no ... ¡pero papi amiguito!
AngularJS (MVC)
Separación de preocupaciones, acoplamiento flojo e inversión de control. Dos vías de enlace de datos
SproutCore (MVC)
YUILibrary (MVC)
Esto es realmente parte del marco general YUI ... pero fue incluido en el original source article.
Broke.js (MVC)
documentación en la actualidad pobres.
Fidel.js (MVC)
Sammy.js (MVC)
Diseñado más hacia el consumo de datos REST.
KnockoutJS (MVVM)
PREGUNTAS:
- Por qué hay tan pocas implementaciones directas MVVM?
- ¿Es el enlace bidireccional lo mismo que MVVM?
- En caso afirmativo, ¿por qué algunas de estas bibliotecas (que hacen enlace bidireccional) se consideran MVC?
MODULAR javascript:AMD, CommonJS y promesas Basada Implementaciones:
Todavía estoy presentando esta área. Sin embargo, a continuación hay algunas áreas que estoy usando como inspiración.
PREGUNTAS:
- ¿Hay diferentes 'modelos' de AMD (varios artículos parecen decir que sí)?
- ¿Qué significa 'basado en promesas'?
que crean los widgets & plugins:
vez que decida sobre qué variante del AMD sus módulos deben utilizar en realidad se puede empezar escribiendo algo.
PREGUNTAS:
- ¿Cuál es la diferencia entre un plugin y un widget?
Indicaciones generales:
Yo sugeriría mirar cómo cada uno de sus marcos implementaron módulos. Mire el código que se necesita para lograr algo. ¿Se siente bien? ¿Se siente torpe?
Mi sensación inicial:
En cuanto a la tendencia, el uso, la velocidad y la inmensidad de opciones de apoyo de la comunidad ... jQuery es muy por delante.
EL OBJETIVO:
El objetivo final es elegir un marco, cualesquiera/todas las bibliotecas y definir un enfoque general para la carga y la creación de módulos de acoplamiento flexible JavaScript.
La cuantificación de costos por Riesgo:
Quantiying costó pura y simple es difícil, pero se puede explicar lejos riesgo. En su última decisión, también debe tener en cuenta las tendencias enumeradas anteriormente. Pero, en general, me suelta ruptura coste en 3 áreas que definen RIESGO:
- familiaridad: ¿Cuál es su equipo más familiarizado con ahora?
- Enlentecimiento: ¿Cuánto esfuerzo extra se requeriría para "aumentar" en cada marco y biblioteca?
- Licencias: ¿Hay inconvenientes aquí?
Riesgo: Una vez evaluados, se puede explicar con razón por las que podría clasificar como una opción de bajo, medio o alto.
@ErezCohen
Somos una tienda de ASP.NET, por lo que utilizar la API de Web para nuestro backend reparador. Y dado que el desarrollo de JavaScript al estilo de los componentes es el futuro, optamos por utilizar jQuery & RequireJS como línea base estándar en todas nuestras páginas. Además, hacemos un uso intensivo de Deferreds en nuestros controladores.
En cuanto al MVC del lado del cliente, muchos de los "frameworks" mencionados son más modas que cualquier otra cosa (y muchos han disminuido en uso). Además, tenía más sentido tratar las capacidades de MVC/MVVM como un complemento único cuando los requisitos eran dictados en lugar de un estándar. Y, francamente, dado que consideramos que hacer llamadas Ajax es fácil, acceder a vastos marcos para hacer un enlace de datos simple parecía tonto (el único beneficio real es la vinculación bidireccional para ciertos casos complejos). Además, piense qué dolor sería desacoplar algunos de estos marcos una vez que ya no sean populares.
Por supuesto, tenemos el talento para hacerlo por nuestra cuenta ... es posible que no. Si tu equipo no es muy bueno con JavaScript, prueba Angular porque fue desarrollado para "diseñadores" y no para programadores. Alternativamente, si su equipo es capaz de hacer sus propios progresos y quiere un marco para los controladores, entonces jQuery Widget Factory es útil. Sin embargo, el uso simple del patrón de módulos para sus controladores también está bien (eso es lo que hacemos). Y ... funciona muy bien ... y está MUY limpio.
Tengo curiosidad por saber qué has seleccionado. + ¿Has considerado Kendo también? –
Sí, utilizamos controles de Kendo hoy. El problema con Kendo MVC es el fuerte acoplamiento a su conjunto de control ... usted depende de Kendo. Te conviertes en una tienda de Kendo. Además, hoy en día, ningún conjunto de controles le proporcionará todas las capacidades que necesita. Kendo es bueno en algunas cosas y horrible en otras. Mientras tanto, faltan otras bibliotecas de control como Synchfusion o RGraph donde Kendo es genial. Al final, tiene que usar muchos conjuntos de herramientas para proporcionar los requisitos de experiencia dictados. Y, dado que Kendo MVC está tan fuertemente acoplado a los controles de Kendo ... no usamos esa parte de Kendo. –