#60 No es que lo confundan, es que hay gente que no sabe ni que es directamente.
#62 Luego te encuentras unos desarrollos chapuceros, que funcionan para unos proyectos sí y para otros no, y para otros pues sólo los días impares.
- "Oiga, no desarrollaban software escalable con el crecimiento propio de la empresa?
- "Y para ke kieres saber eso jaja saludos"
Tan real como la vida misma.
Escalable es que si tu estas abajo y la tia en pelotas está arriba, te la puedes follar sin necesidad de que ella baje. Eso es escalable.
Ahora mismo estoy usando MEAN que es lo que me está dando de comer, aunque no lo considero el mejor Stack, no soy muy fan de nodejs. Aun así es rápido, eficiente y fácil de trabajar con el.
Sinceramente yo no le veo muchos problemas de rendimiento a Angular en móvil, llevo desarrollando aplicaciones híbridas con ionic y angular desde sus primeras alphas y, aunque si que es cierto que la experiencia nunca llega a ser totalmente igual a una app nativa, no es para nada mala. Mucho menos si le dedicas tiempo y mimo a optimizarla para evitar tirones en la interfaz y demás.
Por supuesto sigue estando el problema de que angular pesa una barbaridad, es cierto, en comparación a librerías como React y compañía, angular es un framework grande, no obstante, no estamos en 1998 y por suerte las conexiones ya no son de menos de 1mb/s.
Con respecto a Node, es cierto que no tiene el mejor rendimiento, pero no es especialmente lento, tampoco creo que aspire a ser el más rápido, lo que si que tiene es una grandísima flexibilidad y una barrera de entrada mínima.
Creo que se pone demasiado énfasis en cual es más rápido sobre el papel, pero ya puedes tener el servidor más veloz del planeta y desarrollar todo tu front en vanillaJS que si la implementación es chapucera, no funcionará bien, independientemente de cuantas peticiones por segundo puedas procesar.
Volviendo al tema del front, como ya mencionó Zerokkk antes, no vas a desarrollar para un Galaxy Mini y su procesador de juguete. La cantidad de personas con smartphones gama baja de hace un par de años es ya marginal, los gama baja del año pasado en adelante, te tiran una web single-page hecha con angular y angular-material sin sudar demasiado, dentro de un año, el panorama será aún mejor. Querer seguir manteniendo los Android 4.0 con su navegador a vapor y sus procesadores de 500MHz es como querer seguir soportando Internet Explorer 7.
Bonus track: Con MEAN tienes un solo lenguaje para dominarlos a todos: Javascript en el server, javascript en el front e incluso javascript en tu app de Google Play.
PD: Soy nuevo en el foro, espero no haberos aburrido con tanto texto 
#69 la gente que piensa como tu es el cancer del desarrollo movil, JS para el navegador y gracias, e Ionic/Cordova estarian mejor enterrados.
#70 Yo francamente pienso que tiene bastante razón. Este tipo de paradigma de desarrollo puede que fuera cancerígeno hace 2/3 años, pero a día de hoy hay apps híbridas que funcionan súper bien y la diferencia con una nativa es mínima.
Claro está, como decía otro user en otro hilo, depende de para qué. Si manejas una cantidad de datos importante y tienes que representarlos en la GUI... ahí la diferencia de rendimiento crece de manera exponencial respecto a la cantidad de datos multiplicada por el procesamiento que se hace con éstos. Ahí una app nativa es prácticamente obligatoria.
Pero en una app que simplemente te pide unos JSONs no muy tochos a una API... la diferencia es mínima, y oye, tardas menos programando la app una vez para las tres grandes plataformas, que haciendo tres distintas.
A mi lo de desarrollar apps móviles con JS siempre me ha parecido una matada, el encargado de departamento de QA en dispositivos android se va a estar cagando en tu familia de por vida.
#72 Hombre eso está claro que el testing en JS es cancercito.
Que conste que si usais algún framework que lleve Angular (como Ionic), tirad de Karma o Jasmine para hacer unit tests y demás parafernalias de QAs. Yo por lo menos testeo las cosas a lo oldschool, pero vamos, que haber hay herramientas para facilitar el testeo.
Por supuesto sigue estando el problema de que angular pesa una barbaridad, es cierto, en comparación a librerías como React y compañía, angular es un framework grande, no obstante, no estamos en 1998 y por suerte las conexiones ya no son de menos de 1mb/s.
Y cuando la gente piensa así, acaba pasando esto:
#79 No hace mucho en la oficina tuve que cambiar toda una maquetación de un form porque había un 20% del share que usaba IE 8 x)
#78 #79 Interesante artículo, me ha molado. Pero es que es lo que dice aerotoad: con estas conexiones, no sucede nada por hacer una web un poco más pesada, siempre y cuando el tiempo de carga para una conexión promedio no sea alto.
Todos aquí sabemos perfectamente (espero, vamos) que una web más ligera cargará más rápido, y que un código de más bajo nivel ("más nativo") correrá antes. Al igual que cachear lo que se debe, tener las imágenes redimensionadas, y programar bien los algoritmos.
Pero seamos realistas: hoy en día la media de los terminales y las conexiones están lo suficientemente altas como para sacrificar esas ínfimas diferencias de rendimiento, en ahorrar en tiempo de desarrollo y tener un código más mantenible. A menos que hablemos de algo muy específico cuyo requerimiento principal es alto rendimiento en servidores lo más baratos posibles.
React Native pone el liston a un nivel que hasta un developer nativo le sorprenderia. Yo hasta descartaría hacer desarrollos nativos en una app que sea para Android y iOS, no vale la pena en la gran mayoria de casos. En serio, probadlo. Ya no estamos en los tiempos de Phonegap y Sencha/jQuery Mobile.
NodeJS y NPM, junto a los BaaS, han abierto el ecosistema de una manera tal que practicamente te puedes olvidar del desarrollo backend en muchisimos casos. Hoy en dia no me veo trabajando con algo que no sea con Webpack/JSPM y Babel. El framework es lo de menos, Angular, React, Aurelia, Ember o incluso Meteor. Todos son validos, solo hay que mirar bien el caso de uso.
#70r2d2rigo:#69 la gente que piensa como tu es el cancer del desarrollo movil, JS para el navegador y gracias, e Ionic/Cordova estarian mejor enterrados.
Hombre, pues muchas gracias. No obstante ahora mismo el desarrollo híbrido es lo que paga mi alquiler y me da de comer.
Por supuesto, esto quiere decir que no soy imparcial, ni lo prentendo y, aunque si soy consciente de los fallos que tiene cordova, también lo soy de las ventajas que ofrece. Tirarse a la yugular de alguien solo por defender el desarrollo de apps híbridas no creo que nos lleve a ninguna parte.
#78cabron:Y cuando la gente piensa así, acaba pasando esto:
¿Y donde está tanto problema?
El mismo DOOM me sirve como ejemplo, eso pesaban los juegos hace 20 años y hoy en día a nadie le sorprende que un juego pese 20GB, 30GB o más.
Los tiempos cambian, es hora de asumirlo.
Si los desarrolladores, que supuestamente estamos "obligados" a mantenernos en la vanguardia nos negamos a aceptar nuevas herramientas, paradigmas y demás...seguiríamos maquetando webs con tablas.
#87 un respeto a las tablas... DEP Dreamweaver
ontopic: considero que tienes bastante razón en todo lo que dices, siendo objetivo y hablando a nivel técnico, cordova es una mierda, pero siendo realistas y pragmáticos no lo es tanto
#70 Entiendo a los detractores, pero si un desarrollador cobra la mitad y lo hace el triple de rápido.. y encima se entera y lo hace fluido.. al cliente le costará diferenciar y ni le importará si es nativo o hibrido.
Otra cosa como han dicho son los proyectos más complicados y ambiciosos.