Estoy desarrollando una web. Aunque la idea es hacer versiones mobile nativas para Android y para iOS en un futuro, quiero que la web sea usable desde cualquier dispositivo (con sus diseños responsive y tal).
Una cosa que me obsesiona es el tamaño de los ficheros Javascript e imágenes (no me gusta que la gente tenga que descargarse en su móvil con una tarifa limitada 1MB de Javascript, CSS e imágenes).
La cosa es que quiero usar el mismo API Rest para hacer luego los clientes móviles... así que me surgieron dos opciones (probablemente hay más, pero son las que se me ocurrieron):
- Hacer un API Rest + JSON único y usar Ember o Angular.
- Hacer un API Rest + JSON y usar Play! Framework con plantillas en Scala.
La primera opción implica meter el .js de Ember o Angular (Ember pesa bastante más, creo). Son 200kb a descargarse "por la patilla". Pero así me ahorro tener que dividir el API en dos respuestas (html y json).
La segunda implica tener que cambiar código para devolver html o json en función de la petición, pero me "ahorro" introducir esos frameworks.
La cosa es que usando alguno de esos frameworks SPA... las peticiones ajax tendrán menos transferencia de datos, ¿no?.
¿Pensáis que merece la pena usar esos frameworks para dispositivos móviles con tarifa de datos limitadas?, ¿compensa el ahorro de transferencia de datos la descarga de los ficheros js de dichos frameworks?.
Hola Francisco. Es un tema muy interesante y que creo que a más de uno nos habrá traído de cabeza. Has nombrado Ember y Angular, a mi me encanta Backbone, minificado y gzippeado pesa menos de 7kb, suelen haber quejas de que se crea bastante código boilerplate (repetitivo) pero desde mi punto de vista se soluciona con facilidad utilizando mixins y creando tus propias vistas (extendiendo los objetos "originales").
Por otro lado requirejs es una buena opción para "escalar" la carga de librerías externas. Las dependencias básicas (jquery, ember/angular/backbone, lodash... etc) no te las quita nadie, pero la carga de archivos css y templates se puede hacer de forma progresiva según se necesite, así como las librerías propias de tu aplicación o las librerías de terceros que se usan en momentos puntuales.
Aquí te paso un artículo y librería js sobre el tema de descargar esos "200kb por la patilla": https://muut.com/riotjs/ (segundo post que escribo en este foro segunda vez que la nombro, pero me ha venido a huevo las dos veces :))
Es cierto, no había mencionado Backbone (no lo había descartado por algo concreto). Pero Backbone tiene dependencias con jQuery, ¿no?.
Supongo que al final dependerá del tamaño del código que vas a generar. Si al final va a generar 300kb de código Javascript... seguro que con esas herramientas es mucho menos, con lo cual te compensa. Además de hacer peticiones más "ligeras" y agilizar la carga...
Voy a echarle un vistazo a RiotJS ¡gracias!.
Pero bueno, sino siempre queda el DIY y hacer algo a medida... (aunque lleva más tiempo, dolores de cabeza, etc...).
Aunque depende mucho del producto que estés desarrollando, un MVC siempre viene genial para proyectos grandes, separar las capas de tu producto te ayudará a reducir los problemas y ser más versátil a la hora de conectar nuevas tecnologías o capas que consuman datos.
Quiero decir con esto que si a futuro desarrollas una app nativa, y tienes separado el modelo de datos, la capa front puede ser nativa (iOS, Android, ...) pero el resto puede consumir la capa ya desarrollada, como el controlador o el mismo modelo.
Con el tema de consumo de datos, te recomiendo una SPA, lleva algo más de trabajo, aunque no tiene por que si usas un buen framework, pero logras una buena experiencia de usuario y un reducido consumo de datos.
Veo que habéis comentado la parte javascript. Voy a intentar aportar algo al CSS aunque no sea el foro apropiado.
Mediante nodejs y gulp, puedes automatizar ciertas tareas que te vendrán bien. En el caso del CSS suelo usar bastante gulp-uncss. Esto te permitirá eliminar de tus hojas de estilos (o las de cualquier framework que uses) cualquier clase que no utilices.
Estoy desarrollando una web. Aunque la idea es hacer versiones mobile nativas para Android y para iOS en un futuro, quiero que la web sea usable desde cualquier dispositivo (con sus diseños responsive y tal).
Una cosa que me obsesiona es el tamaño de los ficheros Javascript e imágenes (no me gusta que la gente tenga que descargarse en su móvil con una tarifa limitada 1MB de Javascript, CSS e imágenes).
La cosa es que quiero usar el mismo API Rest para hacer luego los clientes móviles... así que me surgieron dos opciones (probablemente hay más, pero son las que se me ocurrieron):
- Hacer un API Rest + JSON único y usar Ember o Angular.
- Hacer un API Rest + JSON y usar Play! Framework con plantillas en Scala.
La primera opción implica meter el .js de Ember o Angular (Ember pesa bastante más, creo). Son 200kb a descargarse "por la patilla". Pero así me ahorro tener que dividir el API en dos respuestas (html y json).
La segunda implica tener que cambiar código para devolver html o json en función de la petición, pero me "ahorro" introducir esos frameworks.
La cosa es que usando alguno de esos frameworks SPA... las peticiones ajax tendrán menos transferencia de datos, ¿no?.
¿Pensáis que merece la pena usar esos frameworks para dispositivos móviles con tarifa de datos limitadas?, ¿compensa el ahorro de transferencia de datos la descarga de los ficheros js de dichos frameworks?.
En vuestra opinión, ¿qué opción veis más viable?.
Muchas gracias por vuestras opiniones.
Un saludo.
30/12/2014 17:50
Por otro lado requirejs es una buena opción para "escalar" la carga de librerías externas. Las dependencias básicas (jquery, ember/angular/backbone, lodash... etc) no te las quita nadie, pero la carga de archivos css y templates se puede hacer de forma progresiva según se necesite, así como las librerías propias de tu aplicación o las librerías de terceros que se usan en momentos puntuales.
Aquí te paso un artículo y librería js sobre el tema de descargar esos "200kb por la patilla": https://muut.com/riotjs/ (segundo post que escribo en este foro segunda vez que la nombro, pero me ha venido a huevo las dos veces :))
31/12/2014 10:20
Supongo que al final dependerá del tamaño del código que vas a generar. Si al final va a generar 300kb de código Javascript... seguro que con esas herramientas es mucho menos, con lo cual te compensa. Además de hacer peticiones más "ligeras" y agilizar la carga...
Voy a echarle un vistazo a RiotJS ¡gracias!.
Pero bueno, sino siempre queda el DIY y hacer algo a medida... (aunque lleva más tiempo, dolores de cabeza, etc...).
Muchas gracias por tu respuesta.
Un saludo.
11/03/2015 12:45
Aunque depende mucho del producto que estés desarrollando, un MVC siempre viene genial para proyectos grandes, separar las capas de tu producto te ayudará a reducir los problemas y ser más versátil a la hora de conectar nuevas tecnologías o capas que consuman datos.
Quiero decir con esto que si a futuro desarrollas una app nativa, y tienes separado el modelo de datos, la capa front puede ser nativa (iOS, Android, ...) pero el resto puede consumir la capa ya desarrollada, como el controlador o el mismo modelo.
Con el tema de consumo de datos, te recomiendo una SPA, lleva algo más de trabajo, aunque no tiene por que si usas un buen framework, pero logras una buena experiencia de usuario y un reducido consumo de datos.
Un saludo, espero haberte ayudado.
18/03/2015 18:23
Mediante nodejs y gulp, puedes automatizar ciertas tareas que te vendrán bien. En el caso del CSS suelo usar bastante gulp-uncss. Esto te permitirá eliminar de tus hojas de estilos (o las de cualquier framework que uses) cualquier clase que no utilices.
https://www.npmjs.com/package/gulp-uncss