FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
|
Herramientas | Buscar en Tema | Desplegado |
|
#1
|
||||
|
||||
La informacion de dec esta bien, el porqué react es en general mejor es debido a que:
- Cordova y similares: Usas el control WebView y cargas todo como si fuera una página web, con un poco de comunicación entre el webview & el host para lo demás. En donde quizás esto tiene mucho sentido es cuando queremos empaquetar un sitio existente y darle un toque de acceso al móvil, pero la app es definitivamente un sitio web "local". - React & NativeScript: Solo usas el runtime de JS y los controles y clases son los NATIVOS de la plataforma. React también es una librería de hacer UI de forma declarativa, y se puede compartir una buena parte entre servidor/cliente. Aquí estamos usando Javascript como un lenguaje de scripting sobre el runtime nativo del host, no usamos HTML, ni CSS, ni el DOM. Si tenemos un "Button" es el del host. Esto es mejor si queremos que la app desempeñe prácticamente si fuera hecho de forma nativa, acceso casi completo a toda la API del host, etc. Es decir, es como si usaramos Xamarin o Delphi, solo que aqui es con JS. React ADEMÁS es una excelente librería que resuelve el tema de cómo operar la UI y notificar los cambios (ie: data binding). Piensen que es como los controles RAD de Delphi, pero sobre una MUCHO MEJOR base lógica. P.D: React es también usado en el servidor y para hacer páginas web, tanto directamente en el cliente, como compilado en el servidor. Se puede usar agregado al HTML/CSS o de forma totalmente independiente.
__________________
El malabarista. |
#2
|
||||
|
||||
¡Hola a todos!
He leído vuestros mensajes esta mañana, pero, no he podido responderlos hasta ahora mismo. Pido disculpas. ¡Y vamos allá! Cita:
Cita:
Cita:
Cita:
En efecto, no sólo existe Apache Cordova, ni tan siquiera "React-Native", también hay otras herramientas similares, por ejemplo, las que tratan (como Apache Cordova) de utilizar el "WebBrowser" las diferentes plataformas añadiéndole algunos "componentes nativos" accesibles vía Javascript. Digamos, no obstante, que Apache Cordova está en desarrollo constante desde hace más de cuatro años... hasta donde yo llego. No estoy muy seguro de si "React-Native" trabaja de este modo, pero, según entiendo de tu mensaje no se basa en los "WebBrowser", sino en otras cosas. Está bien, Mario, no hay ningún problema, seguramente "React-Native" puede ser también una buena herramienta para según qué aplicaciones. Sin embargo, creo que hay algún que otro punto que puede al menos debatirse. Ciertamente, "React-Native" te liga a un "framework" Javascript determinado, como es "React". Apache Cordova, en este aspecto, no sólo no te liga a ningún "framework", pero, tu aplicación podría ser la siguiente después de escribirlo en el bloc de notas que mejor te parezca: Código PHP:
A lo mejor me equivoco y una de las plataformas de "React-Native", como también ocurre en Apache Cordova, es, precisamente, la plataforma "Browser", es decir, de manera que algunos de los plugins de Apache Cordova estén disponibles también en los navegadores. Como digo, no sé si esto es posible utilizando "React-Native". Sin embargo, aunque la plataforma "Browser" no estuviese disponible en Apache Cordova (que lo está), lo cierto es que, poniendo por ejemplo la aplicación en que estoy ahora trabajando, de las más o menos 20 vistas conque cuenta, en sólo tres de ellas es necesario el uso de cierto plugin para Apache Cordova: el plugin Camera. En realidad, si quisiéramos, podríamos preparar lo necesario para que, en dicha aplicación, se utilizase un posible sustituto al plugin Camera de Apache Cordova: de hecho estaba ya implementado así, utilizando controles HTML "input file". Esto, insisto, al menos ha de considerarse: nuestras aplicaciones correrán también en cualquier navegador en cualquier dispositivo. A la hora del desarrollo también nos viene muy bien que nuestra aplicación pueda correr en cualquier navegador. En el caso de la aplicación en que trabajo y del programa con el que lo hago, probar una aplicación en Android puede llevarme menos de 20 segundos con mi teléfono conectado al PC, pero, probarla en el navegador me lleva aún menos tiempo: esto mismo, el tiempo de "compilación y prueba" se agradece mucho en Delphi también. "Compilamos" muchas veces al cabo del día... ¿Posibles desventajas del desarrollo "web"? Pues que acaso los controles no luzcan como los nativos. Afortunadamente, con "frameworks" como "Bootstrap CSS" (nótese que es el único que he recomendado aquí), esto no parece un mayor problema: nuestras aplicaciones pueden lucir realmente bonitas y aún espectaculares: dependerá de nosotros mismos, del estilo de nuestra app, de las imágenes utilizadas, etc. A más a más, de entre los cientos de temas que hay para "Bootstrap CSS", seguramente existirá alguno que "imite" los controles nativos de esta o aquella plataforma. Cambiar de tema, si es que se precisa, es cuestión de enlazar con este o con aquél archivo CSS y tal vez algún otro Javascript. Pero, sinceramente, lo digo de verdad de forma sincera, yo no me preocuparía por la comparación con los controles nativos en este aspecto. Otra cosa que quiero añadir, para ir terminando, es que, en mi opinión, Mario, has mencionado de una forma un tanto "despectiva" (pero sin malos rollos) a las aplicaciones HTML "que corren en local". No sé si conocerás el cliente de correo web de Google, GMail, que, podría perfectamente correr en local. Personalmente, llevo usando GMail desde hace años... con estupendos resultados, hasta el punto de que no uso ningún otro cliente de correo desde que lo conocí. ¿Cómo te quedas? Uno de los puntos que mencioné arriba trata del hecho de que las aplicaciones HTML, CSS, Javascript (cada vez más, y, hoy día con cosas como Apache Cordova o similares herramientas, siempre que no rompan la "compatibilidad web", como tal vez sea el caso de "React-Native"), digo, que estas aplicaciones, están lejos de ser "simples" o "meros juguetes". Antes al contrario, se ven aplicaciones, juegos, "sitios web", en definitiva, la mar de útiles y para nada "simples". No voy a comparar la aplicación en la que trabajo con GMail (aunque cumple su cometido perfectamente), empero, como dije en mi primer mensaje, esta aplicación permite el acceso a documentos privados para cada usuario, publicar artículos en un mercadillo, y, al modo de Wallapop, el contacto entre compradores y vendedores. La aplicación implementa varios tipos de "avisos" en forma de notificaciones "push" (que te llegan a tu dispositivo casi en tiempo real), noticias de la empresa a sus trabajodes, el acceso a programas, cursos, y, en definitiva, un montón de cosas útiles que esperamos satisfagan a sus usuarios. Para terminar sólo diré que yo no soy ningún máster del universo, quiere decirse, que, con el debido conocimiento y el trabajo que sea menester, las aplicaciones HTML, CSS y Javascript pueden resultar muy, muy potentes. No olvidemos una cosa que tal vez los desarrolladores Delphi pasamos por alto al enfocarnos en el "local" que significa Microsoft Windows y la posibilidad de acceso al sistema de archivos, etc.: en las aplicaciones HTML, Javascript y CSS podemos tener a nuestra disposición uno o más servidores detrás para ofrecernos todo tipo de datos e información con la que trabajar. ¡Y eso es todo de momento! ¡Siento haberme enrrollado tanto! P.D. Estoy seguro de que "React-Native" tiene también no pocas ventajas, pero, como no lo conozco, no las he mencionado. P.D.2. Se me ha olvidado comentar acerca de Javascript vs Dart vs TypeScript vs [Ponga aquí lo que quiera]. En realidad nadie te impide usar estos lenguajes, que, al cabo pueden y aún deben "compilarse" a Javascript. Personalmente, no sé porqué, llámame estúpido, porque, seguramente no es otra cosa, prefiero el Javascript "puro"... pero, como digo, Apache Cordova no te impide usar estos lenguajes si luego los compilas al Javascript que al final se termine usando. Última edición por dec fecha: 22-06-2017 a las 21:15:01. |
#3
|
||||
|
||||
Cita:
Precisamente, el chiste de Cordova es tener la pagina web corriendo en local, con un toque de acceso a la API nativa (y tener icono de la "app" separada sin ir al navegador). Pero si estamos hablando de hacer apps *moviles" es claro que no es la opcion ideal. Es lo mismo que decir: Usemos Cordova para hacer una app windows. Quedaria claro que no es lo mismo que usar los controles/api de windows, cierto? P.D: Aunque no usaria Google Mail como un ejemplo, ya que aunque es funcional, es claramente inferior a otros clientes de correo (osea, en cuanto a UI/funcionalidad de cliente, no almacenamiento/anti-spam), al grado que Google compro Sparrow (el cual fue el mejor cliente para OSX que habia) porque era muy bueno, y asi no tienen una competencia mas
__________________
El malabarista. |
#4
|
||||
|
||||
Desde luego. De hecho, mi comentario a Mario fue una invitación a ello .
Cita:
LineComment Saludos |
#5
|
||||
|
||||
Cita:
Porque los controles nativos son: 1- Mucho mas rapidos 2- Consumen menos memoria, CPU y aun mas importante, menos bateria 3- No son controles web. Web es prácticamente otro OS con sus propias características y hay que hacer gimnasia para intentar hacer que una app web parezca una nativa. Es muy notable cuando se compara una app nativa a una web que pretende serlo. Incluso en Desktop, las apps "web" mas notables (como Slack y otras hechas con Electron que es como cordova) son in-famosas por su excesivo consumo de recursos, lentitud y fallos en general. Y a la larga, puede resultar mas costoso desarrollar no-nativo que nativo. Algo que por ejemplo experimento facebook, que termino cambiando de web -> nativo luego de creer que era buena idea; y de hecho, es la razon por la que termino haciendo React Native, como un punto intermedio entre ambos. Porque la REALIDAD del mercado, es que las tecnologias web permiten contratar MAS BARATO y a programadores MENOS EXPERIMENTADOS que nativo. Ahora, de todas maneras estoy hablando de hacer apps, no de tener una pagina encapsulada, que es un caso de uso diferente. Hay apps donde tener la misma UI tiene sentido, y no hay intencion de ser ni parecer una app nativa, que es donde la falla se hace mas notable. P.D: Quiero acotar que mi punto de vista es mas en termnos generales, que refutar que a roman o cualquier otro vean que les sirve su elección; que al final es mas significativa que la opinion de un tercero que no conoce tus circunstacias especificas. Básicamente solo quera agregar que React Native es otra opción muy buena al arsenal, pero como cosa rara termine yendome por las ramas!
__________________
El malabarista. Última edición por mamcx fecha: 22-06-2017 a las 23:22:40. |
#6
|
||||
|
||||
¡Hola a todos!
Cita:
¿Consumen las aplicaciones "no nativas" menos recursos? Es posible, pero, volvemos a lo mismo, vamos a poner esto en perspectiva. Cada vez los dispositivos son más potentes, más optimizados, en fin, esto es (más o menos) como cuando pretendíamos que nuestros programas en Delphi ocuparan lo menos posible, ¿os acordáis? ¿Quién comprime hoy sus programas con UPX para ahorra espacio? ¿A quién le preocupa si su programa ocupa 1 ó 20 MB hoy en día? No es lo normal, puesto que hoy día 20 MB son... menos que 1 MB antaño. ¡Y esto no se va a quedar parado aquí! Por otro lado, creo que hay cierta insistencia en que las aplicaciones luzcan "nativas". Volviendo al ejemplo de GMail, ¿se parece GMail a una aplicación de Windows? ¿De Mac OS? ¿Tiene GMail alguna necesidad, para ser atractivo y útil, de parecerse a ninguna otra cosa? Lo que tiene que tener GMail, y por supuesto tiene, son "tablas" para mostrar información, "casillas" para introducir datos, "botones" para pulsarlos (claro está) y así sucesivamente. De hecho, GMail tiene una ventaja, desde mi punto de vista: será el mismo en todas y cada una de las plataformas, no se parecerá a nada, y siempre usarás el mismo GMail estés donde estés. A mí esto no me parece mal... |
#7
|
||||
|
||||
¡Hola a todos!
¡Vamos a seguir con tu última respuesta Mario! Cita:
Cita:
Yo creo que el perfil de la persona que refiero arriba está mucho más cercano a la realidad de una posible persona que dominase el desarrollo nativo en Android, iOS, Windows, otras posibles plataformas y además en cualquier navegador en cualquier dispositivo. ¿No te parece a ti que de lo que se trata de buscar una "plataforma universal", mejor que diferentes personas para diferentes plataformas? ¿Qué desarrollo será más económico? ¿Aquél que necesite una persona o el que necesite dos, tres o cuatro? ¿Por qué tiene que ser necesariamente más barato un desarrollador HTML, Javascript y CSS? ¡Eso serán los malos, digo yo! Que un programador sea malo o bueno no creo yo que tenga que ver en absoluto con el lenguaje o entornos que esté utilizando. Cita:
Cita:
¡Claro que "React-Native" puede estar bien! A veces será preferible a Apache Cordova... o viceversa... todo dependerá de lo que vayamos a hacer. |
#8
|
||||
|
||||
Buenas. Muy buen hilo. Me interesa mucho este debate, aunque no tengo argumentos para comentar, al menos de momento, pero estaré pendiente de lo que vayais contando.
__________________
http://www.gestionportable.com |
#9
|
||||
|
||||
¡Hola a todos!
Cita:
Una aplicación "web" con un icono en el escritorio del dispositivo vendría a ser lo que Google inventó con las "Progressive Web Applications", empero, una aplicación que se apoya en Apache Cordova puede ir bastante más allá que eso, recordemos, por ejemplo, que podríamos crear plugins (escritos en Java) para cuanto fuese menester. Por otro lado, quiero hacer notar que la idea de estos hilos míos va más bien por pensar en HTML, Javascript y CSS, lo que ya hoy día es posible hacer con Javascript, y, más particularmente, lo que pueda llegar a hacerse en el futuro con Javascript. Apache Cordova, como dices, es un añadido, pero, yo tengo mucha confianza en las aplicaciones HTML. Ahora bien, ¡no vayamos a intentar atornillar con un martillo! Si mañana me dices, necesito hacer un programa para Windows, problamente pensaría en Delphi. Seguramente no pensaría en otra cosa que en Delphi. Pero si me hablas de Android, ya no lo tengo tan claro, precisamente, porque, con HTML, Javascript y CSS, ojo a esto, POR EL MISMO PRECIO y con la misma base de código, podemos atacar varias plataformas más. ¿Quiero esto decir que ya sólo pensaré en términos de HTML, Javascript y CSS? No, por supuesto que no. Pero sí que quiero transmitir la idea de que estos lenguajes son cada vez más potentes, y, que, ya no hablamos de una, dos o tres plataformas, no... hablamos de poder llegar a esas dos o tres plataformas en que todos pensamos (sí, también Windows y su Windows Store) y además CUALQUIER navegador disponible en cualquier dispositivo. Para mí eso tiene ventajas indudables. ¿Superan las ventajas a los incovenientes? ¿Sería mejor usar algo nativo? Dependerá de cada caso, ¡digo yo! Cita:
Posiblemente un cliente de correo escrito en Delphi o cualquier otro entorno nativo para Windows sea más rápido que GMail... si es que guarda los mensajes en una base de datos local, pues, de lo contrario, habrá de contactar igualmente con un servidor. Pero lo que tengo claro es que no tiene porqué ser ni más bonito, ni más usable, ni mejor. Yo no uso GMail no porque reniege de lo nativo, vaya, sino porque con GMail tengo más que suficiente... e incluso mucho más de lo que utilizo. Última edición por dec fecha: 23-06-2017 a las 08:02:58. |
|
|
Temas Similares | ||||
Tema | Autor | Foro | Respuestas | Último mensaje |
Solicito orientación sobre un desarrollo para GPS. | TiammatMX | OOP | 6 | 28-03-2014 15:37:29 |
Sobre .NET en multiplataforma | SMTZ | Noticias | 2 | 16-09-2006 17:58:14 |
Compiladores y Entornos de desarrollo multiplataforma | Crandel | Debates | 9 | 16-08-2005 18:29:18 |
Desarrollo de webservice para apache | padillarj | Internet | 0 | 14-08-2005 08:24:05 |
Crear un componente multiplataforma para conectar un BD | RONPABLO | OOP | 0 | 10-02-2005 20:25:49 |
|