#20250 Pero qué coño me estás contando, si no estás diciendo nada con tu post. Mi mensaje anterior te contesta sobradamente, pero venga, ya que insistes:
#20248eZpit:1º Ves React para cosas pequeñas pero "que puede fallar para temas mas grandes", que es una frase completamente absurda. La utilidad de React para un proyecto depende de las especificaciones y necesidades del proyecto, no de su tamaño.
No es como si te lo negara, pero para apps grandes veo Angular como un framework mucho más preparado. Esto, por supuesto, es una observación altamente subjetiva, pero por tal y cómo están organizadas ambas herramientas, no creo que esté diciendo ninguna burrada.
#20248eZpit:2º Crees que un lenguaje o framework (y sus bugs) no son problemas mientras hagas un "testing intensivo". Everything is gonna be alright.
Lógicamente los bugs son un problema, y muy serio si hablamos de apps mission critical. Hacer numerosos tests unitaros, E2E y hasta integration / regression tests, debería ser suficiente para encontrar cualquier tipo de bug en cualquier tipo de lenguaje. El scope de estos tests por supuesto cambiará dependiendo de las necesidades del proyecto, pero ya que estábamos pesaditos con las mission critical, ahí es necesario dedicar muchísimo tiempo a ello.
#20248eZpit:3º Estamos hablando de desarrollo móvil y mencionas "apps mission critical" que ya me darás un ejemplo, porque lo único que se me ocurre "critical" en mobile es la seguridad y es algo que no tiene una mierda que ver con un lenguaje de programación o programación funcional.
No te creas que pienso distinto xD, pero esto lo sacó el otro user antes a dilación.
#20248eZpit:4º Pones ejemplos de lenguajes funcionales random que no tienes pinta ni de conocer, que no tienen nada que ver con el desarrollo de apps y que ni cuentan con tooling para mobile y te quedas tan ancho.
Nombro los lenguajes funcionales más importantes, no cualquier mierda random xD. Y como dije antes, el scope de mi respuesta iba contextualizado según lo que decía el otro user, y yo me refería a que el backend de dichas supuestas "mission critical mobile apps" probablemente estaría muy bien hacerlo en lenguajes como esos, más que nada porque es más difícil cometer errores con ellos, y el tiempo dedicado a resolver los bugs tras la fase de testing, será menor que si usamos lenguajes imperativos.
#20248eZpit:5º Dices "workarounds javeros" que no significa nada.
Esto tiene más sentido del que parece, y me da que tu inteligencia no está en alza hoy si no has comprendido esto. ¿En qué programamos Android, si se puede saber? En Java, joder, en Java. ¿Y qué paradigma de programación usarás si quieres minimizar la aparición de bugs, y facilitar un entorno fácilmente testeable? El funcional, claramente. Y tanto en Java 7, 8 como 9, hemos visto mejoras al lenguaje que le otorgan cierta capacidad funcional, lo cual me parece que puede servir para estas supuestas "mission critical mobile apps" de las que tanto se quejaba el otro user donde frameworks híbridos no serían tan adecuados de usar.
#20248eZpit:6º Dices "app mission critical" y sigues con "TS full funcional". Como ves que no es creible, luego añades "con el testing suficiente" para que parezca que eres un profesional que sabe lo que hace. Justo después de defender JS & TS, como no te has convencido ni a ti mismo, aclaras que todo lo que has dicho es un non-sense y que te fiarías más de otros lenguages.
Porque no tengo por qué basar mis acciones en convencimientos personales. Los lenguajes completamente funcionales demuestran otorgar una comodidad mucho mayor a la hora de desarrollar este tipo de aplicaciones críticas, y por tanto, me fío de lo que los profesionales en dicho nicho dicen, ya que no es mi especialidad. Que ojo, eso no quita que tenga bastante confianza en un programa bien hecho en TS y aprovechando las características funcionales de JS, pero probablemente preferiría pasarle el marrón a otro que esté más curtido en el campo a la hora de hacer algo que podría ser arriesgado. No tiene mucha ciencia.
Esto es cíclico ya... las aplicaciones híbridas tienen un target específico y a poquito que empieces a hacer cosas complicadas la hostia que se pegan por rendimiento es pequeña xD
Llevo trabajando casi 4 años como dev móvil nativo y he cobrado muchas apps reescritas desde hibrído a nativo. Aparte, si supiérais programar bien en móvil el 75% del código es compartido entre dos apps con la misma funcionalidad (casos de uso, presenters, entidades y tests), obviamente salvando las diferencias del lenguaje.
Lo único híbrido que se medio salva es Xamarin (solo una de las dos versiones) pero igualmente te toca saber iOS y android para programar en ella, aparte de que la comunidad y las librerias tocapelotas no ayudan, como ya ha dicho antes @r2d2rigo
Por lo tanto nativo >>> all
#20253 Da datos reales y no saques conclusiones tan apresuradas con semejante ambigüedad. ¿En qué tecnologías (y versión de las mismas) estaban escritas las apps que dices que tuviste que reescribir a nativo?
Es que es lo que llevo diciendo varios posts: tiene poco que ver una app hecha en Ionic 1 o las primeras versiones de RN con lo actual, o Flutter mismo. Me atrevo a decir que la ganancia sustancial de rendimiento que tenía Xamarin con respecto a este tipo de apps, ya se ha quedado como algo del pasado.
#20255 En 2014 terminé mi ciclo superior, hice algunos trabajos web, Java SE para escritorio y Android para unos clientes de mi hermano y mi padre, y luego me metí de profesor especializado en Java en Agosto de 2015. Eso me hizo aprender mucho más del aspecto teórico del desarrollo, y también me metí en más tooling javero y a aprender mejor desarrollo web (que lo tenía un poco crudo de aquella). En 2016-2017 desarrollé un proyecto propio (que está on hold) así como seguí trabajando de autónomo dando cursos de bastantes más tecnologías que antes, esta vez por varios sitios de España (y ya comenzando a cobrar como dios manda). A finales de 2017 me marché para Holanda y empecé a trabajar para una empresa de Amsterdam dedicada al MBO para la que todavía trabajo en remoto, aplicando todo lo que sé del stack Javascript y mis humildes conocimientos de arquitectura de software (hice un plan de rediseño de su arquitectura y me lo aceptaron, y todavía estamos trabajando en ello).
A día de hoy me saco 3.5k brutos al mes por 6h de trabajo diarias desde casita, y me están cayendo ofertas que ofrecen más, casi todas y cada vez más, en Angular e Ionic. No creo que esté patinando tanto por más que os empeñéis en ello, pero bueno, cada uno a lo suyo.
EDIT: Tampoco quiero que números como el anterior funcionen a modo de argumento de validación de lo que digo (eso sería muy falaz), pero sólo quiero hacer ver que aquí parece que me tenéis como un puto paria, cuando realmente tengo una muy buena carrera profesional (de la que estoy orgulloso) y una posición privilegiada gracias a en gran medida a haber hecho un cambio de nicho tecnológico.
#20254 De verdad, que no es por llevarte la contraria gratuitamente, pero esq en mi día a día (que son muchos años ya) esta discusión aparece en todas las reuniones con el cliente, y hay algunos que por sus cojones toreros deciden hacerlas híbridas con la tecnología de turno y al año nos están llamando para cambiarla.
No te digo yo que entre una aplicación Android/iOS hecha por indios vs una app en RN hecha por gente que sabe programar, la híbrida sea mejor, pero en el mundo real y hablando de especialistas en las plataformas, nativo se come al desarrollo híbrido por todos lados... Hace un par de semanas repliqué la funcionalidad entera de una app en Swift que tenían hecha en RN en 4 días (6h diarias) y el resultado final daba mil vueltas a la app que tenían en híbrido y todo porque la pantalla principal tenía un mapa.
#20257 Me parece interesante lo que comentas, pero es lo que digo: habría que ver cómo estaba hecha esa híbrida, ya sabes que muchas veces más que problema de la tecnología, es de mal uso de la misma. Aún así yo estoy más puesto en Ionic eh, con RN prefiero no mojarme. Sólo digo que Ionic 4 usa Stencil y creo que con abrir la página https://stenciljs.com/ ya os doy un argumento de peso para pasarse a Ionic desde RN a los que hagáis híbridas.
#20258 <3
#20252 Estamos hablando de programación de apps móviles. Ni de páginas web, ni de backends, ni de Angular, ni de Java. Te sales por la tangente.
#20261 Not really, solo algunas vistas secundarias (e.g. ajustes) están hechas en hibrido. El resto, lo gordo, nativo 100% y del bueno.
#20260 Estás haciendo que me plantee que realmente te dediques a la programación macho, porque creo que mi mensaje ha quedado bien claro y se refiere a precisamente lo que buscabas. Pero bueno, es lo que tiene cuando alguien en este país se queda sin argumentos, que no sabéis admitir que no tenéis la razón y tenéis la autocrítica en el culo.
O al menos si intentases leer y entender lo que digo...
#20261 #20262 No sé si me equivoco, ¿pero no estaba hecho en un framework híbrido propio, que no era RN? Quizá esté patinando, ¿o es que acaso la han reescrito en RN?
#20265 Nadie en su sano juicio usaría Ionic excepto
a) clientes roñosos con 0 idea de lo que están haciendo a los que alguien les ha dicho que es BARATO
b) web developers ofreciendo mobile developement
c) apps con requerimientos muy sencillitos que seria suficiente con tener una web responsive pero que por X o por Y es necesario tener una app movil.
No puedes desarrollar apps para plataformas móviles sin conocer y estar preparado para bajar a nativo. Tanto React-native como Xamarin requieren un conocimiento de la plataforma nativa para poder trabajar correctamente. Recomendaría a cualquier persona empezar por NATIVO para entender correctamente el desarrollo móvil y solo cuando tengan una base ver que oportunidades les ofrece el híbrido. A día de hoy veo el híbirdo como una herramienta más del toolkit de un desarrollador nativo.
#20267 ¿Cuándo fue la última vez que tocaste Ionic, por curiosidad? Es que en serio, me parece lo que diría alguien hace años con su primera versión, la que usaba AngularJS y era lenta como el demonio.
Yo había hecho un proyectito propio con Ionic 2 (más lento que las versiones actuales, por cierto) cuando estuve aprendiendo JS, que tenía una vista que tenía que hacer una consulta a 3 APIs de Google distintas (secuencialmente), instanciaba un mapa de mala manera (cargando la librería desde un CDN lololol) y sin siquiera usar los packages nativos, ponía un montón de mierda en él, estaba todo bastante mal hecho, y aún así, y sin siquiera activar el AOT de Angular, esta vista me tardaba dos segundos en cargar en el viejo Samsung de mi madre.
Usando Ionic 4, flags de producción, programando las cosas bien y usando el package nativo de Ionic para Google Maps, algo como esto tiene que optimizarse todavía muchísimo más. Por eso me parece surrealista lo que me cuentas.
#20268 pues vaya balubas, porque AngularJS está deprecateadísimo.
#20270 Dicen que quieren cambiar pero cada cliente nuevo que les entra vuelven a ahcer las cosas en Angular porque no quieren perder tiempo ahora aprendiendo otras cosas y tu de lel
#20271 Pues en cuanto Ionic lance la versión LTS (que poco le queda) de la actual versión 4, creo que deberíais replanteároslo, ya que será un buen momento para meterse en ello. La ganancia en rendimiento, calidad del código, esalabilidad, mantenimiento y reusabilidad de componentes, vale mucho la pena. El salto de calidad de angularJS a Angular 5 es mastodóntico.
Y es que usar algo tan viejo como Ionic 1 y AngularJS valida totalmente lo que dice
#20267, básicamente no vale para más que para cosas muy muy muy sencillas.
#20270 Tu descripción encaja con el punto c) que explicaba:
c) apps con requerimientos muy sencillitos que seria suficiente con tener una web responsive pero que por X o por Y es necesario tener una app movil.
#20272 Yo me piraré pero vamos, si fuese webdev angular no lo tocaría ni con un palo. Es la cosa más absurdamente compleja que he visto para hacer cualquier puta mierda.
#20273 Esa era una vista, pero la app en sí tiene como 20 vistas, no es tan enana como te piensas, y hay muchas con bastante lógica detrás. Y en serio, yo estaba todavía aprendiendo a usar guay JS de aquella y pfff, hay cosas MUY mal hechas que a día de hoy podría optimizar una locura. Y eso, con esa versión ya tan atrasada, sin activar flags de producción. Por eso te digo que creo, sin acritud, que lo que dices se podría aplicar hace años, pero a día de hoy me parece un poco surrealista.
Personalmente, yo sólo programaría Android si tuviese que hacer juegos que traguen muchos recursos.
#20274 No te niego que es complejo. Tiene algunas cosas muy mal hechas, como dije atrás. Pero bien usado termina siendo la clave. Aunque honestamente, creo que todavía tienen que mejorar algunas cosas (como el module lazy-load, que me parece la parte más descuidada) para que sea algo así como "el framework definitivo". Pero vamos que sí, requiere de bastante tiempo para aprenderse a usar bien del todo.
Personalmente, yo sólo programaría Android si tuviese que hacer juegos que traguen muchos recursos.
ME LOL
