El problema con el mvc del lado del cliente es que terminas manteniendo dos patrones de mvc diferentes, lo que genera mucha confusión.
Descargo de responsabilidad, soy autor de Atoms.js
Después de jugar con varios marcos, identificamos que dejar el enrutamiento en el lado del servidor es aún mejor que crear un solo HTML para toda la aplicación. Y la página HTML puede contener una interfaz de usuario simple que se comunica con el modelo y el controlador del lado del servidor a través de REST. Solo debe mantener el mvc del lado del servidor, ya que la vista es poco interactiva al eliminar la programación del lado del cliente.
- ¿Por qué Knockout.js no se ha vuelto tan popular como Angular.js?
- ¿Cuáles son las características de resistencia más importantes de un marco de microservicios?
- ¿Qué es un marco de aplicación web en términos simples?
- Cómo crear un sitio web y alojarlo
- ¿Existe alguna demanda en el desarrollo web, ya que creo que solo las nuevas empresas necesitan desarrolladores web?
Problemas con el lado del cliente JavaScript MVC
- Dificultad para visualizar la IU
- Problemas de navegador cruzado
- Llamada asíncrona infernal (con Atoms.js, puede evitar por completo las devoluciones de llamada)
- ID infierno, crear y mantener ID de elemento es otra molestia (Atoms.js proporciona un alcance de UI múltiple para proporcionar aislamiento y reduce el conflicto de ID)
- Administre múltiples archivos de script, múltiples versiones del mismo script, las pruebas unitarias ayudan pero aún es demasiado trabajo para cosas simples.
Echa un vistazo a https://github.com/neurospeech/a…
Twitter: Atoms.js (@atomsjs) | Gorjeo
Fuente de GitHub: neurospeech / átomos.js
Documentación: Componentes web JavaScript de grado empresarial inspirados en Flex y Silverlight
