Kotlin vs Java vs Ionic vs Flutter vs ReactNative Desarrollo móvil ¿Qué prefieren?
Resultados 1 al 10 de 10
Like Tree3Likes
  • 1 Post By _Tuner_
  • 1 Post By Magallanes
  • 1 Post By Ena McEna

Tema: Kotlin vs Java vs Ionic vs Flutter vs ReactNative Desarrollo móvil ¿Qué prefieren?

  1. #1
    Pajarito Nuevo Avatar de _Tuner_
    Fecha de ingreso
    01 Sep, 16
    Mensajes
    14

    Kotlin vs Java vs Ionic vs Flutter vs ReactNative Desarrollo móvil ¿Qué prefieren?

    Buen día estimados!

    He estado adentrándome en el desarrollo móvil, hasta el momento he ocupado Ionic para CRUD, geolocalización y más pero no estoy conforme con el rendimiento y algunos problemas de incompatibilidad que me surgieron. Ahora estoy en la búsqueda de nuevos lenguajes/herramientas lo que me ha llevado a una encrucijada ¿Qué elegir? ¿Nativo o Híbrido? Herramientas más nuevas como flutter /Kotlin? o android studio?

    Estoy muy interesado en poder aprender a utilizar de todo pero como muchos sabrán, aprender un lenguaje o herramienta es una inversión que conlleva tiempo. De momento manejo Java, C# y alguna vez vi algo de C.
    Agradecería saber sus opiniones, particularmente sus proyecciones futuras respecto a cuales serán las herramientas que ustedes creen, la llevarán en el desarrollo móvil de aquí en adelante.

    Saludos y gracias!

  2. #2
    🐔 La papa
    Avatar de Kensho
    Fecha de ingreso
    16 Aug, 06
    Ubicación
    En este cuerpo que me contiene.
    Mensajes
    7,318

    Re: Kotlin vs Java vs Ionic vs Flutter vs ReactNative Desarrollo móvil ¿Qué prefieren?

    A los que contemplan la luna las nubes a veces ofrecen una pausa. ¯\_(ツ)_/¯
    Cita Iniciado por kermit Ver mensaje
    esta prohibido alabar a kensho, ban
    Cita Iniciado por _PeTiZa_ Ver mensaje
    ya me esta artando esta rana de mierda

  3. #3
    Usuario
    Fecha de ingreso
    26 Mar, 09
    Mensajes
    409

    Re: Kotlin vs Java vs Ionic vs Flutter vs ReactNative Desarrollo móvil ¿Qué prefieren?

    Como dirían los simpson, esto ya se ha visto:

    Desarrollo Mobile

    PD: Kotlin no es una herramienta, es un lenguaje. Tienes el mismo resultado usando java o kotlin. Sólo cambia el proceso.

  4. #4
    Cookie Monster Avatar de DarkSpy
    Fecha de ingreso
    20 Jan, 04
    Mensajes
    2,198

    Re: Kotlin vs Java vs Ionic vs Flutter vs ReactNative Desarrollo móvil ¿Qué prefieren?

    Otra alternativa: Xamarin

  5. #5
    Pajarito Nuevo Avatar de _Tuner_
    Fecha de ingreso
    01 Sep, 16
    Mensajes
    14

    Re: Kotlin vs Java vs Ionic vs Flutter vs ReactNative Desarrollo móvil ¿Qué prefieren?

    Agradecido por las respuestas. De todas formas no me había dado cuenta que había un tema similar. Sorry!
    Samsarulz likes this.

  6. #6
    Trabajando Avatar de Magallanes
    Fecha de ingreso
    07 Nov, 04
    Ubicación
    Nuñoa
    Mensajes
    3,007

    Re: Kotlin vs Java vs Ionic vs Flutter vs ReactNative Desarrollo móvil ¿Qué prefieren?

    Java Android es un cacho, ya que esta mal hecho.

    Digo, supongamos que cargas tu aplicacion y tienes una clase de objeto y cargas una actividad. Android puede liberar la memoria cuando le da la gana. Puede incluso descargar otras actividades (incluyendo actividades previas). Asi que hay que prevenir todo eso.

    Pero, aun asi es la mejor alternative. Kotlin es bueno pero es lento, y no hace que Android sea sencillo.

  7. #7
    Usuario
    Fecha de ingreso
    26 Mar, 09
    Mensajes
    409

    Re: Kotlin vs Java vs Ionic vs Flutter vs ReactNative Desarrollo móvil ¿Qué prefieren?

    Cita Iniciado por Magallanes Ver mensaje
    Java Android es un cacho, ya que esta mal hecho.

    Digo, supongamos que cargas tu aplicacion y tienes una clase de objeto y cargas una actividad. Android puede liberar la memoria cuando le da la gana. Puede incluso descargar otras actividades (incluyendo actividades previas). Asi que hay que prevenir todo eso.

    Pero, aun asi es la mejor alternative. Kotlin es bueno pero es lento, y no hace que Android sea sencillo.
    1.-Te estas quejando de la forma en que funciona la VM, ¿En qué afecta el lenguaje que uses? Puedes escribir tu app en scala y va pasar lo mismo. Puedes usar javascript y va a ser... bueno, peor, ya que estaras corriendo en una webview, que a su vez corre en la VM. Podrías usar Xamarin, y TAMBIÉN va estar sujeto a los mismos límites, por muy JIT que sea para las capas comunes (offtopic: me pregunto cuanto futuro tendrá contra Kotlin-MP), etc. El remedio, es simplemente, saber cómo funciona android, pero ya sabiendo como funciona java, es bien fácil. El problema viene mas bien de estar acostumbrado a la web. Android es mucho mas simple si piensas en multiproceso y ejecución en paralelo. Lidiar con el ciclo de vida es lo mismo que lidiar con un deadlock.

    2.-Kotlin no es "lento". Se traduce al mismo bytecode que java. Simplemente trae características que java android no tiene oficialmente (aunque D8 ya permite usar muchas de las características nuevas de java 8 al 12), así que muchas cosas se vuelven mas breves, o más sencillas (puedes hacer toda tu inyección de dependencias usando funciones de extensión, por ejemplo), pero se traduce al mismo bytecode. Tu tiempo de ejecución será igual, por que el resultado final es igual.

  8. #8
    n00b Avatar de deadpool_455
    Fecha de ingreso
    05 May, 13
    Ubicación
    localhost:3000
    Mensajes
    728

    Re: Kotlin vs Java vs Ionic vs Flutter vs ReactNative Desarrollo móvil ¿Qué prefieren?

    Llevo un par de meses trabajando con React Native, y debo decir que me ha sorprendido mucho, tanto en la velocidad de desarrollo y curva de aprendizaje, como en el rendimiento en general comparandolo por ejemplo, con Ionic.

    No voy a mentir diciendo que he trabajado en aplicaciones de alto rendimiento o cosas muy complejas, estoy consciente de que el resultado final jamás será igual al desarrollo 100% nativo. Aún así, lo recomiendo si lo que quieres es desarrollar algo simple tal y como mencionas al principio (CRUD, geolocalización, manejo de archivos, etc).
    Última edición por deadpool_455; 15/01/2019 a las 20:57

  9. #9
    Trabajando Avatar de Magallanes
    Fecha de ingreso
    07 Nov, 04
    Ubicación
    Nuñoa
    Mensajes
    3,007

    Re: Kotlin vs Java vs Ionic vs Flutter vs ReactNative Desarrollo móvil ¿Qué prefieren?

    Cita Iniciado por Ena McEna Ver mensaje
    1.-Te estas quejando de la forma en que funciona la VM, ¿En qué afecta el lenguaje que uses? Puedes escribir tu app en scala y va pasar lo mismo. Puedes usar javascript y va a ser... bueno, peor, ya que estaras corriendo en una webview, que a su vez corre en la VM. Podrías usar Xamarin, y TAMBIÉN va estar sujeto a los mismos límites, por muy JIT que sea para las capas comunes (offtopic: me pregunto cuanto futuro tendrá contra Kotlin-MP), etc. El remedio, es simplemente, saber cómo funciona android, pero ya sabiendo como funciona java, es bien fácil. El problema viene mas bien de estar acostumbrado a la web. Android es mucho mas simple si piensas en multiproceso y ejecución en paralelo. Lidiar con el ciclo de vida es lo mismo que lidiar con un deadlock.
    Yo soy bueno en Java y me gusta Java, pero Android es un cacho.

    a) tiene programacion funcional, y eso es un asco.

    b) tiene funciones asincronicas, lo cual no es sencillo, pero es estandard para las apps. Aun asi no es bueno.

    c) El uso de la memoria sigue siendo un asco...
    -android : te fuiste a dormir aplicacion?. Pues di adios a tu memoria. Usas mucha memoria?. pues tambien. Usas poca memoria, pues lo mismo.

    d) Programar para android es saber escribir mil veces context()

    e) La persistencia es guardarlo en el disco.

    f) Los layout son un asco.

    Yo nunca habia visto algo asi. No recuerdo que Xamarin-Forms tuviera ese problema, Kotlin sigue teniendo ese problema.


    Afortunadamente esta retrofit (2) y picasso


    Cita Iniciado por Ena McEna Ver mensaje
    2.-Kotlin no es "lento". Se traduce al mismo bytecode que java. Simplemente trae características que java android no tiene oficialmente (aunque D8 ya permite usar muchas de las características nuevas de java 8 al 12), así que muchas cosas se vuelven mas breves, o más sencillas (puedes hacer toda tu inyección de dependencias usando funciones de extensión, por ejemplo), pero se traduce al mismo bytecode. Tu tiempo de ejecución será igual, por que el resultado final es igual.
    Kotlin es lento de compilar, y el ciclo de compilacion ya es mas o menos lento en android studio. Ademas, mucha de la ayuda es para java-android.

  10. #10
    Usuario
    Fecha de ingreso
    26 Mar, 09
    Mensajes
    409

    Re: Kotlin vs Java vs Ionic vs Flutter vs ReactNative Desarrollo móvil ¿Qué prefieren?

    Cita Iniciado por Magallanes Ver mensaje
    a) tiene programacion funcional, y eso es un asco.
    Al margen que los gustos personales no definen una tecnología, puedes usar POO en android todo el día. Llevo haciéndolo desde el 2012. Por otro lado, igual me cuidaría de decir que la programación funcional es un asco. Hay una razón para que Scala funcione como lo hace, y me parece que tipos como Martin Odersky tienen aaaalgo más de conocimiento y práctica bajo el cinturón que tú.

    Cita Iniciado por Magallanes Ver mensaje
    b) tiene funciones asincronicas, lo cual no es sencillo, pero es estandard para las apps. Aun asi no es bueno.
    Sí, igual que Java Standard Edition, en cualquier ambiente con multiproceso, e incluso en monoproceso. ¿Acaso nunca has usado un listener? ¿Jamás tratas con runnables o threads? No es diferente. En cualquier ambiente donde necesites exprimir los recursos vas a tener que usar esas cosas. La asincronía sólo es problema si estas acostumbrado a programar de forma lineal.

    Cita Iniciado por Magallanes Ver mensaje
    c) El uso de la memoria sigue siendo un asco...
    -android : te fuiste a dormir aplicacion?. Pues di adios a tu memoria. Usas mucha memoria?. pues tambien. Usas poca memoria, pues lo mismo.
    De nuevo, así se supone que funcione un garbage collector en ambientes de pocos recursos. Que estés acostumbrado a trabajar en máquinas que siempre tienen electricidad y las que siempre se les puede poner más ram, no significa que esa sea la forma en que todas las máquinas funcionan. Si bien la brecha se ha acortado enormemente en términos de tamaño, los teléfonos siguen teniendo menos RAM que los equipos de fijos, y por otro lado, es un sistema operativo diseñado para máquinas RISC, con recursos escasos y electricidad finita, en los cuales la escasez de RAM causa muchos más problemas que en x86. Por último, la gestión de la memoria en android no es ningún problema para un developer decente. Sólo es un problema si no la mides, no la gestionas, o tratas con ella como lo harías en un equipo corriente (crea variables nomas, si total tiene RAM!).

    Cita Iniciado por Magallanes Ver mensaje
    d) Programar para android es saber escribir mil veces context()
    Aunque a nadie le parecen bien los objetos Divinos (god object), por algún lado hay que acceder a los recursos del dispositivo, especialmente aquellos que son necesarios para el correcto funcionamiento de APIs standard; Qué es mejor, ¿Cambiar la API de File, haciendo que montones de código no funcionen en android (o viceversa) o delegamos en una clase diferente el acceso al disco? Obviamente lo segundo es mejor.
    Programar para android es saber escribir SIN pasar context por todos lados, porque entiendes que :

    -Context representa al estado de la app/proceso en android en un momento dado y por ende, referenciarlo por todas partes es la mejor forma de botar la memoria por el drenaje, causar excepciones irrecuperables, y conseguir bugs que dependen del momento de ejecución así que cuesta reproducir.

    -Tu código deja de ser reusable, porque incluye referencias a una plataforma única. Es JAVA. Si mantienen la separación entre el Android SDK y su código, pueden escribir la mitad del servidor mientras hacen la app.

    -Tu código se vuelve difícil de testear, porque depende del acceso a un dispositivo real. Si escribes de forma tal que tu código recibe justo lo que necesita del SDK en lugar de llamarlo por todos lados, puedes testear prácticamente todo lo que no sea la UI final en junit.

    Cita Iniciado por Magallanes Ver mensaje
    e) La persistencia es guardarlo en el disco.
    No entiendo mucho esto, ya que todos los medios de almacenamiento físico son "discos". Ahora, si por persistencia te refieres a JPA o cualquier otro ORM, en realidad hay muchos. Algunos incluso funcionan en desktop. ORMlite es el que me ha permitido acercarme más a lo que escribía con EclipseLink. Obviamente no se puede usar el wizard, pero cualquier persona que sepa java es capaz de crear un DAO base que haga todas las operaciones comunes y reciba la clase representando a la tabla y campos claves con genéricos, y así no tener cuatrocientas clases para representar la BD, salvo que tengas una enorme maraña de relaciones. O puedes simplemente abstraer y tener una implementacion JPA y otra en Realm, Room, GreenDao, Ormlite, Ada, SQL pelado...

    Cita Iniciado por Magallanes Ver mensaje
    f) Los layout son un asco.
    Yo nunca habia visto algo asi. No recuerdo que Xamarin-Forms tuviera ese problema, Kotlin sigue teniendo ese problema.
    Nunca he intentado comerme un layout, pero respeto que lo hayas intentado. Bromas aparte, eso significa que jamás viste Swing, o nunca miraste mas allá del editor de interfaz. Android es extremadamente similar a Java Swing en términos de UI. En ambos casos, la UI es una subclase de un contenedor, que tiene como miembros a todos los controles que se hayan agregado al contenedor en el editor de interfaz. La diferencia es que en swing se creaba una clase Java que podías editar si querías, mientras que en android se crea una plantilla XML que es mas breve y simple de editar a mano, pero al ejecutar, es exactamente lo mismo. Se crea una instancia de View, lo mismo que se creaba una de Jframe/JPanel/Jeetcetcetc. Por ende, se puede tratar con la UI de la misma manera que en desktop... como una clase java, que produce objetos java. Igual al resto de cosas en java. Por último, si es escribir XML lo que te molesta (a mí tampoco me agrada mucho, pero imagino que google tenia bastantes recursos relativos a procesar tags y lo aprovecharon), puedes escribir tu UI vía código, con algo de XML, o nada de XML. O puedes usar Json (no es un soporte oficial, pero existe). Escribe con Xamarin si quieres, pero es un vil transpiler, así que al final del día igual estas usando a View y todas sus subclases. Lo único que escapa de esto, es flutter.

    Cita Iniciado por Magallanes Ver mensaje
    Afortunadamente esta retrofit (2) y picasso
    No capté el punto aquí, pero de todas maneras, he visto que glide es más popular que picasso por estabilidad (aunque imagino que picasso se debió poner al día en algún momento). Retrofit está bien, si te gustan las anotaciones fuera de POJOs. Personalmente, prefiero cosas que me permitan abstraer más, escribir el código para GET una vez y parametrizar todo, en lugar de 10 interfaces idénticas, donde igual voy a tener que enviar los argumentos. Retrofit es una de las soluciones que aparecieron cuando se hizo patente que había mucha gente metida en android sin tener idea cómo trabajar con java. Produce un ahorro medio sin que el usuario tenga que saber mucho, en contraste a escribir todo una vez como puedes hacer con volley, restemplate, okhttp, y ahorrar mucho pero teniendo que operar con java a bajo nivel.


    Cita Iniciado por Magallanes Ver mensaje
    Kotlin es lento de compilar, y el ciclo de compilacion ya es mas o menos lento en android studio. Ademas, mucha de la ayuda es para java-android.
    Performance y recursos no son lo tuyo, ¿verdad? "Tengo un auto con un remolque, y extrañamente, si le conecto otro remolque, anda más lento. Por ende, el remolque número dos es lento."
    Kotlin es un lenguaje. Recordando a Jake Wharton, si agrego a android studio un plugin que soporta un lenguaje entero, TIENE que ir mas lento. Antes usaba una juego de herramientas, ahora usa el mismo, mas una. El tiempo de ejecución TIENE que aumentar. Eso es algoritmos 101, crece la carga de trabajo, crece el tiempo de ejecución. Ahora, si tu proyecto va MUY lento en android studio, parte por desactivar los plugins que NO usas, como el NDK. Si sigue siendo lento, evita usar java y kotlin en el mismo módulo y sepáralos (kotlin siempre tendrá que compilarse primero por compatibilidad). Agrega compilacion bajo demanda, builds en paralelo, aumenta la RAM para el demonio de gradle. Subdivide tu proyecto en módulos y separa los que rara vez se tocan del código que muta constantemente. Si sigue siendo lento, compila vía terminal, el IDE seguirá funcionando y el logcat también. Si aún es lento, agrega un POM y compila con maven para desarrollar y usa gradle para los releases. Listo.
    Punto aparte, kotlin y java interoperan perfectamente, a no ser que estes creando jerarquías de clases mezcladas entre ambos. Así que la ayuda para java, es válida en kotlin. Incluso puedes convertir java en kotlin con un clic.

    Me da la impresion que cuando dices "sé java" quieres decir "sé un montón de librerías y frameworks como spring, que se usan corrientemente en java". Lo que no es malo, pero no es saber java. Alguien que sabe java, conoce el lenguaje a bajo nivel y como funciona, y por ende, puede trabajar en cualquier plataforma, con cualquier librería o framework, porque se fundamentan en las mismas bases que ya conoce.
    flukke likes this.

Permisos de publicación

  • No puedes crear nuevos temas
  • No puedes responder temas
  • No puedes subir archivos adjuntos
  • No puedes editar tus mensajes
  •  
*