Sí tío, la gente navega con conexiones de 100mb y con PC's que mueven juegos triple AAA, las páginas que tardan segundos en cargar con cada acción que realizas en ellas, que dejan el navegador tostado en cuanto tienes varias pestañas abiertas, y que en móvil directamente te petan el navegador, son de un universo paralelo, en este no existen.
Seguid pensando que el rendimiento en el emulador de Chrome representa la mayoría del mercado móvil xD
Probad vuestros freimguorks en conexión 2G/3G con 400ms de lag, un par de adservers en la web y varias pestañas del navegador abiertas. Si en esas condiciones va bien, enhorabuena.
observo que esto va de defender lo que usamos cada uno y de no habalar que ventajas desventajas no? Yo para maquetar newsletter necesito usar tablas a cascoporro y oye como funcionan las cabrones de bien y como me toca los huevos los lotusnotes y los clientes yahoo peor que se le va a hacer 
En mi oficina usaban uno que te dejaba subir PSD. En cuanto llegué yo se les acabó la tontería de los WYSIWYG editors para newsletters; son todos cáncer de sida.
#1
Para mi, opinion personal, el lenguaje mas cómodo hoy en día para full-stack es Javascript, y mas que nada por el isomorfismo. Que quieres hacer algo pequeño i rápido Express + SQL + Node o incluso típica pagina de contendió rápida puedes usar KeystoneJs.
Pero para el sector empresarial usaría Hapi + SQL + Redis + NodeJs i si estas pensando en SPA y futura posible app móvil, añadiría React + Redux ( La verdad no le veo sentido alguno a Angular ahora mismo si no es para usar Ionic. Tiene peor rendimiento, necesitas de prerender si quieres seo, y al final es una lib demasiado grande i creo que es mejor buscar pequeñas libs que hagan bien las cosas )( No he probado Angular 2 ).
Descarto Mongo en la mayoría de stacks por que es difícil sacarle partido sin tener mucha experiencia, casi todo lo que he visto con el es usando un ORM que al final simula relaciones i te obliga a usar un Scheme, cosa que hace perder toda la gracia a un NoSQL.
Y el por que prefiero no usar Express en aplicaciones grandes, es mas que nada por el manejo que hace de los middlewares que te obliga a estar muy atento al orden de ejecución de los mismos y a la hora de escalar no me parece nada fácil de mantener.
Y como gran contra a NodeJS en general, pondría el requisito de usar transpiladores para ES6, que teóricamente ahora con la v6 ya tiene soporte y no ara falta. ( Para mi es un requerido, yo lo siento pero sin el sugar de Class, map, filter, Promises y destructuring.. se hace mucho mas duro JS en backend ). El problema de los paquetes no actualizados, o con poco soporte a nuevas features, por que quien no esta cansado de bajar paquetes que siguen usando callbacks y tienes que acabar con bluebird siempre promisificando todo.. Y como ultimo punto añadiría que en proyectos que pueden crecer solo un poco es obligatorio usar inyección de dependencias, por que sino es imposible hacer Unit Testing y muy difícil de mantener por culpa de pequeñas libs que no están del todo actualizadas.
#102 MongoDB y ORM claro, claro... Los ODM te permiten trabajar con mongo como si creases relaciones, pero al final lo que creas son colecciones, el ODM es solo una abstraccion conceptual, para hacer mucho mas facil la gestion de la informacion, representando el documento comp un objeto, sin más. Y sabiendo todos problemas y limitaciones que tienen tanto los ORM como los ODM especialmente de rendimiento, sinceramente en el 90% de las veces es mucho mejor que utilizar queries a pelo.
Yo últimamente sólo pico JS y estoy montándome RIAs con MongoDB+Express+NodeJS+ExtJS.
En cuanto al backend que más me gusta, por encima de node, spring y phps... Ruby con Rails 3/4. Matz fanboy.
#2 Preferiría Symfony2.
¿Porque tu prefieres CodeIgniter?
Yo creo que este tema debe abarcarse teniendo como premisa que tipo de proyecto se va a desarrollar: costes, tiempo, escalabilidad, como se tiene prevista la carga de trabajo. ¿El proyecto tiene una concurrencia de usuarios bestial?, pues quizás MEAN, que no, pues quizas podemos usar MYSQL+PHPFW+FRONT NORMAL.
En definitiva, la cosa es tener en cuenta varios aspectos de lo que necesitamos.
No entiendo porque os quejáis del peso de las librerias js en aplicaciones móviles, es irrelevante. Las aplicaciones móviles hechas con phonegap/ionic compactan todo el código y librería en un .apk para descargar. Por lo que el tamaño de las librerías (js, css, etc...) solo es relevante en el momento de la descarga de la aplicación ( a no ser que incluyas las librerías a traves del cdjn). La velocidad de tu conexión móvil solo es relevante para la transferencia de información entre server y movil, normalmente código JSON (imágenes, videos, sonidos támbien...)
El problema de los frameworks actuales para móviles es que no son lo rápido y eficaces que debieran ser, debido principalmente a la cantidad de recursos de sistema que consumen, esto en teléfonos móviles, sobretodo de gama baja, es un problema si la aplicación es grande. Pero hacen su trabajo. Ahora con la llegada de Ract native e ionic2 + angular2, la cosa mejorará.
#108 también hay algo más, js no deja de ser ejecutado por un motor, y ninguno es precisamente la panacea en optimización, a eso le sumas que android corre sobre una jvm y ya tenemos la fiesta preparada xD
Una pregunta, ya que no desarrollo para android y no sé cómo va. Desarrollando una app de manera no nativa, con esos frameworks que habéis citado, el sistema de notificaciones e interacción con el SO (que salgan en la parte de arriba) se puede programar igual?
#110 Cuando se habla de JS en movil se suele hablar de cordova/phonegap, que mas que nada abre un app con un navegador embebido que te carga el JS, obviamente, en esa app tienes ciertos plugins para jugar con la api nativa del movil como la cámara, notificaciones, geolocalizacion...
A mí lo que me gustaría ver, es algún tipo de comparativa de rendimiento entre Phonegap, Cordova, Android nativo, y Android parseado de Xamarin. Sería interesante ver qué diferencias existen entre estas plataformas.
#110 en Android y iOS puedes establecer un puente en JS que comunique web con código nativo para hacer lo que quieras. Yo tengo compras in-app en una webview y va perfecto.
Alguien ha probado Yii Framework ? http://www.yiiframework.com/
Me he leído la documentación y tiene buena pinta
#113 toma y goza:
https://medium.com/@harrycheung/cross-platform-mobile-performance-testing-d0454f5cd4e9#.bcxfajyiv
https://medium.com/@harrycheung/mobile-app-performance-redux-e512be94f976#.fja7dpi1l
Rendimiento cercano a nativo en la mayoria de los casos (y en casos concretos... mejor, vease ObjC vs Swift). Es la hostia:
En otro orden de cosas, a ver si me hacen ya mod del subforo y puedo banear ya a los defensores de JS como #102 #104 #108.
#118 Yo estoy haciendo applicaciones web ricas ricas (RIA), así que esos gráficos de app móviles lo puedo mover directamente a /dev/null.
No me parece que los gráficos que has puesto aporten nada nuevo o sean un argumento a favor de nada. Básicamente, porque lo que la conclusión que se puede inferir de ellos es lo que todos sabemos: que una aplicación nativa es más rápida que una web app. Está claro, de la misma manera que una aplicación en C++ será más rápida que su equivalente en Java, por ser interpretado, al igual que la misma aplicación en ensamblador bien optimizada será más rápida que su equivalente en C++ (y, por eso, verás que hay un gran gap en tus gráficos entre todo aquello que se traduce a código nativo o se ejecuta como una app nativa en móvil, y lo que es realmente web, y se interpreta, de una forma u otra, en un "navegador").
Si quieres meter en el mismo saco (etiquetado "stack web") una aplicación nativa en ObjC/Swift/C++ y una aplicación web, en ese caso la bolita para ti: sí, desde luego que es mucho más rápida la app en C++ que en HTML/CSS/JS, pero creo que precisamente el objetivo de hacer una aplicación web es que sea "platform-independent", y puedas ejecutarla en cualquier sistema con un navegador web adecuado, sin tener que optimizar para OSX/Linux/Windows/iOS/whatever.
PD: Acabo de ver el mensaje al que contestas. Está bien como contestación pero, insisto, no aporta nada nuevo.
