Hace 9 años | Por dersu_uzala a manzanamecanica.org
Publicado hace 9 años por dersu_uzala a manzanamecanica.org

El año es 1991, y mientras los geeks del mundo disfrutamos de este mundo de "apps", Tim Berners-Lee ya ha escrito el primer servidor web y el primer navegador. En los próximos 4 años nuestro mundo de "apps" implotará y desaparecerá. El mundo de las "apps", que en realidad se llamaban BBS (Bulletin Board Systems), dará paso a la web.

Comentarios

D

#6 En uso de cpu, no tiene porqué, depende lo que haga y como, pero para leer información deberá ser irrelevante. Incluso muchas aplicaciones móviles "nativas" no son más que simples js&html, con algún framework como Sencha Touch, cordova, etc..
En cuanto al ancho de banda, tampoco tiene porque ir mejor una nativa, si la página esta bien hecha con ajax y sólo transfiere json con datos, pues lo mismo que la app nativa, ya que la parte estática se cachea.

kados.

#7 Si dices que no usa mas cpu, y despues dices de usar javascript y ajax para consumir json ... mas cpu si usa, y mas ahora que android tambien compila las apps.

#13 Hablando de lenguajes de google, con Go se pueden hacer aplicaciones nativas para android. Y puede que pronto sea un lenguaje oficial para android como Java y C. https://blog.golang.org/go1.4

D

#50 Te repito, muchas aplicaciones que consideras "nativas" ya son html&js. Los nuevos motores como V8 de Google hacen que ejecutar js sea muy rápido, desecha tus viejos conceptos sobre js
#51 Estas equivocado. Al acceder a una web (bien hecha) en la que ya has estado, tu navegador manda un comando para saber si el contenido que tiene en caché ha cambiado, en caso negativo te muestra los datos que ya tenía en cache, sin más trafico que el json que se use para cargar datos. css, js, html e imagenes se cachean y no se tienen porque volver a descargar.

kados.

#52 Lo se, he trabajado con cordova y phonegap pero te repito, que son mas eficientes las nativas. Lo bueno de las webapps es que desarrollas 1 vez y te sirve hasta para la TV. Pero en performance, no tienen nada que hacer, la unica discursion posible es la diferencia de rendimiento.

D

#53 Y tu crees que ese menor rendimiento es apreciable en aplicaciones "chorras", como la de Marca? roll
El tener algo más de privacidad me compensa con creces esa supuesta perdida de rendimiento

kados.

#55 Para una cosa tan basica si, un webapp te sobra.

p

#1 Porque de siempre es sabido que hacer caso a los gurús del marketing ha sido positivo para el publíco.

Además, para qué vas a hacer un servicio público, si puedes comprar una app y pagar por l que normlamente no haría falta. El mundo del mongophone y los mongousuarios.

avalancha971

#1 Yo estoy completamente de acuerdo en el absurdo que es tener cientos de apps que realizan las funciones de webs, pero no obstante me gustaría defenderlas en un par de cosas:

Lo de fisgonear en los datos personales depende de la aplicación. Sí, hay muchas fisgonas, pero no todas lo son.

Las apps que realizan las funciones de web pueden aportar el valor añadido de no tener que descargar todo el envoltorio para mostrar los datos, sino unicamente, una vez ya descargada la app, lo que es la información. Esto en dispositivos con poco ancho de banda permite una mayor rapidez. Por ello, creo que deberían de existir unas "web-apps" en HTML, no fragmentadas, que permitieran esto.

D

#46 "no tener que descargar todo el envoltorio para mostrar los datos, sino unicamente, una vez ya descargada la app, lo que es la información"

Esa es la idea de Tizen. En otros sistemas, algo parecido ocurre al usar la cache del navegador, aunque tal vez no de una forma tan controlada.

d

#1 No coincido contigo. Cada vez que accedes a la web, tienes que descargar la interfaz de usuario por completo y los datos (cachés aparte), y el navegador tiene que "componer" todo eso. Si accedes a través de la aplicación, lo único que descargas son los datos, por lo que es más rápido y consumes menos megas.
Sí que estoy de acuerdo en que regalar tus datos personales es tontería, pero para eso, cada vez que instalas una app, se muestran los permisos que necesita, no todas requieren acceso a tu información o a la de tus contactos. Así que no creo que se pueda sentenciar que web=buena y app=mala, cada caso será diferente. Otra cosa muy distinta es que ni el Tato se lea estos permisos y pulse en "Aceptar" por defecto...

mmm_

#19 Tú lo has dicho, por el momento. Me constan varios trabajos (WebRTC, sin ir más lejos). Ahora estoy en el móvil -usando la web de Meneame, btw, y no una app- por lo que no tengo a mano las URL. Si me acuerdo, las pondré por aquí.

D

#19 "El rendimiento de motores 3D en web está muy por detrás"

¿Seguro?

Experimentos varios, incluidos simuladores de fluidos
http://www.chromeexperiments.com/webgl/

Benchmarks
http://blogs.unity3d.com/2014/10/07/benchmarking-unity-performance-in-webgl/

D

#29 "Experimentos varios, incluidos simuladores de fluidos"

Unreal Engine 4.:



Mejor calidad:

D

#31 Cierto, el Unreal Engine 4 también funciona en navegador:



https://www.unrealengine.com/blog/strategy-game-webgl-demo-available-now

D

#32 No llega ni a 30 FPS en el segundo, hay parones y la calidad es muy, muy inferior, parecida a la que da un dispositivo GLES movil. Solo hay que ver la geometría.

D

#33 Los únicos "parones" que da WebGL se deben a tener tropecientas pestañas de navegador abiertas. Por cierto, con el soft nativo también pasa, que si tienes al lado un navegador con tropecientas pestañas, acaba dando "parones" y "no llega ni a 30 fps".

En cuanto a diferencia de calidad... las diferencias entre OpenGL y GLES son mínimas. Tal vez te refieras al rendimiento de los dispositivos móviles que soportan GLES, que ese sí suele ser más bajo que el de las gráficas de escritorio.

D

#36 "Las diferencias entre OpenGL y GLES son mínimas."

Tu no usas OpenGL en Linux, ¿Verdad?

Lanza un emulador GLES 2.0 VS Mesa 10.3 (GL 3.3 y parte de la 4) y me comentas.

https://www.khronos.org/registry/gles/specs/2.0/es_cm_spec_2.0.25.pdf

D

#61 Gracias por las especificaciones de GLES. Aquí tienes las diferencias con OpenGL a secas, cortesía de la misma Khronos:

https://www.khronos.org/webgl/wiki/WebGL_and_OpenGL_Differences

Como decía, son mínimas.

"emulador GLES 2.0 VS Mesa 10.3 (GL 3.3 y parte de la 4)"

Como curiosidad, la compatibilidad con OpenGL ES 2.0 es una de las novedades de... OpenGL 4.1.
A ver si es que tu problema viene de solo usar linux, en vez de entender lo que usas.

D

#84 emulador que haga uso de. Como ppsspp. Así que si, como poseedor de una intel d 3000 y pcsx2 con gsdx no me queda mas cojones que enterarme y saber hasta donde llega cada API. Ídem con reicast , donde ando compilando el port android gles a Linux y según como tire gles en mesa, o juego o me jodo con reicast.

D

#86 Tan obvio que te puedes pegar un tiro en un pie:

https://www.opengl.org/registry/specs/ARB/ES2_compatibility.txt

"This extension adds support for features of OpenGL ES 2.0 that are missing from OpenGL 3.x."

#85 Pues no sé yo cuánto habrás mirado la compatibilidad de cada versión de OpenGL, porque aquí hay un resumen bastante bonito que lo deja bien claro:
https://en.wikipedia.org/wiki/OpenGL

* OpenGL 4.1 - OpenGL ES 2.0
* OpenGL 4.3 - OpenGL ES 3.0
* OpenGL 4.5 - OpenGL ES 3.1
* OpenGL NG / AMD Mantle - unificado con OpenGL ES

D

#87 WebGL + GLES seguirá sin ofrecer exactamente lo mismo que OpenGL en una estación normal.

Tanto a nivel de características como rendimiento.

Te pongas como te pongas, donde no hay no se puede sacar.

Es inutil compararar Webgl contra videojuegos creados en C++ & LUA.

Si no pregunta a la gente de Irrlicht

D

#88 ¿LUA?... y por qué no PHP, ya puestos

Lo siento, no sé si estás trolleando o es que no tienes ni puta idea, pero eso ya es pasarse.

D

#90 C++ para el motor y LUA para scripting y ciertas cosas que con su JIT hacen milagros .

¿Troleando? No.

D

#91 LUA es entre 2 y 30 veces más lento que JavaScript, muy parecido a la velocidad que saca PHP. La única razón para usarlo en juegos es que está pensado para que sea fácil extenderlo con funciones nativas en C/C++, a diferencia de PHP y parecidos. Es muy fácil escribir un juego en "C/C++ + LUA" que funcione más lento que su equivalente en "JavaScript + asm.js".

De hecho, hace tiempo que los navegadores usan compiladore JIT de JavaScript bastante optimizados, y asm.js es una forma de optimizarlos mucho más.

D

#92 He dicho "scripting". Eventos en el juego. Y c++ por ello arrasa con JS, puesto que el motor ya es un lenguage de bajo nivel y se encarga de lo "crudo". Y con asm.js , pues no sé, pero espero que esté lejos del JSMESS y demás.

Solo recuerdo la web de TV a la carta EITB en JS. Inusable en mi i3 y ni te digo en mi CoreDuo . Y ni Chrome, oiga .

D

#93 Como he respondido antes en #47, con asm.js se pueden conseguir velocidades de entre el 50% hasta casi el 100% del código nativo.

No, la web de EITB no usa asm.js. Lo que sí hace en cambio es cargar 66 (!!) scripts en solo la página principal. "Menos mal" que algunos solo son de unas pocas líneas lol

D

#94 Lo ideal sería un compilador de JS. Con las SSD , tal tarea en el futuro será como visitar una web actualmente

Vamos, que podrás compilar la web como quien compila el kernel con una SSD y 24 procesos a la vez.

Para eso sí sería un buen uso de los multicore, y JS-

D

#94 Por cierto, asm.js con Clang es una buena dirección.

Un poco offtopic: A ver si los de Etoilé GNUStep y Clang espabilan y cobren Cocoa de OSX 10.5.6 de forma libre.

Molaría portar segun que SL a Linux

D

#87 En lo que webgl será bueno será en multimedia para matar a Flash .

Para juegos extremadamente complejos, aun queda mucho, pero muchísimo para que JS se acerque siquiera a cosas como CXX + SDL + GL.

D

#84 compatibilidad? Claro como que gles es un subconjunto limitado de gl. Obvio, mi capitán.

c

Estamos hablando en el móvil #29

cc #31

D

#40 La cosa es que da igual que estemos hablando de móvil, linux, la TV, un Mac, o lo que sea:

- WebGL = OpenGL ES = el OpenGL "de los móviles"
- Da exactamente igual de dónde salgan las instrucciones OpenGL/WebGL, se van a ejecutar siempre de forma nativa por los drivers/gráfica de turno.
- El soporte de asm.js permite que un navegador ejecute código a velocidad muy cercana a la de código nativo.
- Tanto Firefox como Chrome, tienen soporte para WebGL, asm.js, y versión para móviles.

En este mismo momento, existe el soporte suficiente para coger CUALQUIER escena OpenGL ES de cualquier app de móvil, y ejecutarla exactamente idéntica en un navegador de móvil a un 50%-90% de fps.

Que no se quiera hacer, y el por qué, es otro tema (y no digo que se deba hacer siempre, pero poder se puede).

A

#43 La última vez que lo miré los creadores de asm.js decían que como mucho la cosa iría al 50% de la velocidad del código nativo. Muy cerca no parece aunque sí sorprendente

D

#44 El código ejecutado en asm.js, según el algoritmo que se use, puede llegar hasta casi el 100% de velocidad del código nativo... pero sí, se suele decir que un 50% es "suficientemente aceptable".

Lo que ocurre es que la parte pesada de procesar una escena en 3D normalmente no recae sobre el código en asm.js, sino sobre la gráfica que ejecuta las instrucciones de OpenGL. Si está bien hecha, incluso una reducción del 50% (o más) en la velocidad de proceso no debería afectar a los fps. De hecho hay más diferencia que eso entre el hardware de los distintos dispositivos en los que se puede ejecutar.

A

#44 Sólo en velocidad de ejecución, luego ya de consumo de memoria y tal...

c

#29 "El rendimiento de motores 3D en web está muy por detrás" ¿Seguro?

#43 ejecutarla exactamente idéntica en un navegador de móvil a un 50%-90% de fps.

Tu mismo te contestas

D

#54 Hombre, si eres de los que piensan que overclockear una gráfica para ganar un 10% de fps, pasando de 60 a 66, es una gran idea, seguramente te parezca eso.

c

#83 Me alegra que estemos de acuerdo.

D

#4 Lo segundo sí, lo primero, depende.

Dicho esto, las webapps son cacota contra esto:

https://f-droid.org/repository/browse/?fdfilter=osmand&fdid=net.osmand.plus

https://f-droid.org/repository/browse/?fdid=com.addi

Sin datos, ni servicio remoto ni gaitas.

m

#34: A ver, la idea es una página web con Java Script para calcular.

El único problema es el alojamiento, que tiene que ser gratuito y que te permita subir tus propios ficheros HTML y que no te fuerce a usar plantillas.

polvos.magicos

#4 Bendito seas.

s

#2 En este caso fue arquitectura cliente-servidor (tocho a cada lado) vs sistemas "centralizados" robustos con clientes ligeros ("thin") en las capas superiores, y allí fue que triunfaron los navegadores, si mal no recuerdo... s.e.ú.o.. auqnue claro, lo que molaba era ver tias en pelotas desde playboy o penthouse bajándose la imagen linea a linea... qué tiempos!!!

B

#23 Línea a línea para llegar a lo interesante y tener que gritar ¡Joder! ¡¡Que tiene rabo!! Momento de tensión patrocinado por calle 13... lol

superjavisoft

Que se venga a mi curro donde no llega ni señal gsm, y solo hay una parte donde llega algo de wifi, odiaria que TODO fuera online.

kernelspace

La razón es simple.
Las apps permiten vender un producto y simplicidad para que el usuario las adquiera, confianza en el distribuidor. Por otro lado puede utilizarse offline o una mezcla de estos.
Las WebApps para adquirirlas debes registrarte, crear una cuenta, asociar una tarjeta de credito (con toda la desconfienza que esto conlleva), pagar, y luego cada vez que quieres entrar poner tus datos. No puedes usarla offline, o por lo menos hacerlo para el proveedor requiere mucha complejidad

No hay por donde perderse

D

#10 Tu has comprado algo en Google Play? Porque es una app, y me he registrado y asociado mi tarjeta, con la misma desconfianza que lo hago en una web.. Y bueno, se acuerda de mis datos, pero no puedo usarl a offline, como la mayoría de apps. Piensa en una sola app que uses, que requiera registro o pago y funcione sin cobertura y sin wifi..
Y no veas la que pasé el otro día para dar de alta una nueva tarjeta y borrar la caduca, anda que no es fácil perderse!

cyberdemon

Pues yo lo veo clarísimo: las app triunfan por el medio en que se usan. Navegar por la web en smartphone es una puta mierda, casi nadie adapta sus webs en condiciones para estos dispositivos y su tamaño.

e

#18 No es fácil hacerlo, y menos hacerlo bien.

l

¿Acaso la web y las apps son cosas distintas? La mayor parte de las apps utilizan http como protocolo para conectarse a sus servidores.

Si bien la UX se mejora mucho con una aplicación nativa, el pequeño coste añadido de poner un interfaz web y las posibilidades que eso aporta a una app hace que a la larga todas las aplicaciones acaben desarrollando su sistema web para poder acceder a los datos desde las plataformas no soportadas.

D

#25 "¿Acaso la web y las apps son cosas distintas?"

Sí. Una app es un programa que manipula contenido, la web es una forma de transmitir contenido.

"La mayor parte de las apps utilizan http como protocolo para conectarse a sus servidores."

No sé qué mierda de apps utilizarás, pero te puedo asegurar que la gran mayoría de las que yo uso ni tienen "sus servidores", ni necesitan conectarse a ellos para nada, por ningún tipo de protocolo.

l

#28 #30 Sigue siendo el sistema de conexión de las APIs más extendido en el mundo de las apps. Y #30 dudo que sea tu hijo, capullo.

D

#38 Las apps me causan gracia frente al rendimiento nativo.

Seguid fundiendo la batería mientras el código de mucho más nivel hace ahorrar ciclos en mi dispositivo.

l

#64 Suerte para que encuentren tu app entre el resto de la morralla de las stores.

D

#66 No está en las stores. Pero las apps NATIVAS están en Fdroid y Google Play con más calidad que tu "truño mapa JS + HTML5".

Ver OsmanD, VLC o cualquier JUEGO nativo para Android con GLES. NA-TI-VO. No juguetes con webgl.

l

#67 No todo el mercado son juegos, a ver si maduramos un poco.

D

#68 Los juegos dan pasta, madura tú de una vez.

Y donde digo juegos, digo programas críticos donde se exija la velocidad y rendimiento, y que no te consuma la batería de movil en dos horas.

Aprended lenguajes de verdad, aunque sean Objetive C y Android/Java.

l

#70 Más pasta da desarrollar sistemas de integración de datos en ingeniería, pringao.

D

#71 Seguid con HTML5 desperdiciando recursos mientras los chinos y americanos con programas en C, C++ y similares con QT se coman el mercado por dar 200.000 vueltas a las bazofias patrias en HTML5+JS.

l

#72 Es cierto voy a dejar de usar gmail y usar un cliente de correo basado en QT. .

A cascarla mamón.

D

#75 Cada cosa tiene su uso, ver #76

Flash = Suicida, obsoleto, sin soporte y atado al plugin de Macromedia.
Webs HTML5 + JS = OK, es una web.
Aplicaciones en JS = apaño rápido. ¿Eficiente? NO.

l

#77 A ver gañan, en una aplicación web tienes un front-end javascript y un back-end que está programado en lo que te de la gana.

D

#78 Una web, tu lo has dicho, no una app que se hace pasar por algo decente.

Si quieres decentralizar todo teniendo que usar tu conexión de datos siempre, allá tu.

Y usar algo que no necesita internet con HTML5+JS es un chiste como programador, tiendo obj-c y el pseudojava de Android. Así de claro.

Si quieres eficiencia ya sabes.

Sí, con un bicho de ocho núcleos va de puta madre un "reproductor" de audio y video con JS y etiquetas de HTML5. Digo "reproductor" porque de algo verdaderamente nativo, nada. Chorrimierdas ineficientes.


Mientras tanto VLC hace lo mismo en un Galaxy Mini y en el 8 núcleos le sobra tiempo para engancharse a la tele y abrir cosas a 4k. Tu decides.

Cojona, te digo que el JSMESS es un truño LENTO que hasta un Pentium3 con el MESS en C SE LO COME en velocidad. Hasta en C++, que traga un poco más en esas CPU's le da sopas con ondas.

D

#78 Perdón, MESS usa c++. Y aun así es mucho mejor el MESS, repito, que JSMESS en mi i3. Bajo Chrome, el navegador con el motor JS más rapido, el V8. Pero como 40 veces más, sin exagerar. Abres un juego y como si lanzas 30 emuladores, ni lo huelo.

Con el JSMESS, frameskip constante. Y no llega ni siquiera a 2/30 frameskip, necesario par que sea jugable.

En un i3, repito. Que yo jugaba a esos juegos en el AMD Athlon y me sobraba para poner música y algun programa de chat de fondo.

Si ese es el futuro estaremos jodidos pero bien. CPUs potentisimas desperdiciadas en lenguajes con velocidades y capacidades ridículas.

D

#66 Sácame un emulador de consolas con webgl, JS. Te reto. Y que llegue al 50% de velocidad de PPSSPP, MAME, Dolphin o VBA.

Han sacado JSMAME/JSMESS para Archive.prg y se ralentiza HORROROSAMENTE comparado con MESS en C donde a mi me funcionaba emulado el SF2 con una CPU CIENCUENTA veces menos potente y con 1/16 de RAM.

D

#25 "a mayor parte de las apps utilizan http como protocolo para conectarse a sus servidores."

¿Qué mierdas me instalas hijo mio?

¿Como es que no me he arruinado en Francia con la tarifa de datos, Android y OSManD? ¿Será que no la he usado para nada mientras usaba el GPS del movil?

D

#62 Hace más de una década desarrollé en flash fantásticas apps de escritorio

Yo he dicho "flash" empleado en la web no mola. En cualquier caso, y aunque esas características (que se dan en la práctica totalidad de las webs desarrolladas con flash) sean responsabilidad del programador, Flash (a) lo permite y (b) no es estándar.

Para mí esas dos premisas ya convierten a Flash en algo a evitar en, repito, la Web. Y, por supuesto, hay que diferenciar una app embebida dentro de un sitio web correctamente diseñado a un sitio web diseñado por completo en Flash.

D

No acabo de entender porqué una app mola, pero una aplicación web en flash, no.

D

#9 Una "app" no mola por defecto y "flash" empleado en la web no mola porque no es accesible, no es estándar, no es opaco para los buscadores, se inventa su interfaz supermolona pasándose por el forro los comandos del navegador (el botón "atrás" sin ir más lejos)

En realidad no. Flash no es una tecnología de vectores y de stream, con una potencia infinitamente superior a lo que una decada despues todavía permite html5+ajax+.....

Lo que hagas luego con flas es cosa del desarrollador, no de la tecnología. Se pueden hacer desarrollos terriblemente accesibles (a las personas) y de hecho la ONCE tiene uan guia sobre ello. Y se pueden hacer truños infumables si el desarrollador es un tierno infante haciendo dibujitos.

Además, para una app embebida es irrelevante que sea o no rastreable por google, porque no es ese su fin.

Item mas en cuanto a los comandos de navegador, que dependen de lo profesional o no de su desarrollo, no de la propia tecnología.

Hace más de una década desarrollé en flash fantásticas apps de escritorio que funcionaban (y funcionan) perfectamente en tabletos sin ningun problema ni adaptación, independientemente del SO, del navegador y de cualquier otra consideración.

D

#62 Flash es basura y no funciona en entornos ARM sin el plugin para empezar y no van independientente del SO ni de coña.

No me seas dinosaurio.

"Se pueden hacer desarrollos terriblemente accesibles (a las personas) y"

Y nada. Flash no es accesible y crea conflictos con los programas de dictado web para ciegos.

¿Decía UD algo?

"Hace más de una década desarrollé "

Pues muy bien. También VC6 era hace una década y Java/.Net se comió el mercado por la portabilidad . Sí, incluso Mono era y es mejor (UNITY) que VB6.

Welcome to 2014. Ni Flash, ni ActiveX ni mierda propietaria e INSEGURA. Estándares abiertos. ¿O hace falta decirte donde acabó Silverlight? Si hasta MS que era el demonio liberó .Net .

D

#65 Flash, repito, no es una "paginica güé". Flash es una tecnología vectorial y de stream. Con ella puedes hacer desarrollos accesibles o no accesibles. Todo depende de lo que sepas o no hacer.

El problema es que las tecnologías de hoy no son capaces de hacer lo que se hacía con flash hace más de 10 años. Eso hemos perdido.

¿Flash inseguro? Me temo que en informática/internet lo único seguro es un pc encerrado en una caja a un metro de profundidad y apagado. Y no lo tengo tan claro.

D

#73 Que flash está obsoleto, pesado.

Es propietario y solo funciona en Intel.

Es como seguir con Active X, suicida si no quieres que te fundan a tí y al cliente sus datos y pierdas dinero por no poder entrar desde ningún dispositivo que no sea Windows XP.

Hasta Youtube usará (y usa)HTML5 por defecto.

Otros ejemplos:

Dailymotion, Soundcloud, GrooveShark, Gmail, DropBox. Sin flash ni mierdas propietarias.

Sigue con tu flash mientras los que apuestan por la web multiplataforma te comen el negocio por verse desde el PC, movil, tablet y neveras, sigue.

D

#74 hace años que no desarrollo en flash porque el mercado no me lo pide. Pero llevo en el el tiempo suficiente como para haberme ganado bien la vida cuando lo usé, y por eso puedo hablar de el de primer mano y no de oidas

D

#81 Ya pero los tiempos cambian, y en plataformas cerradas, es mucho peor.

Es como apostar por WMV y ActiveX frente a MP4, webm y Vídeo HTML5.
O VB6 vs .net.
Eran la única alternativa, pero la mejor ni por asomo.

D

#73

Web = HTML5, JS + Nginx/PHP/SQL detrás entre otros.
Aplicaciones = Java, C/C++ && QT, .Net.
Hasta Freepascal es más deseable que Flash
Sigue con Flash, y Active X.

Que será lo próximo, ¿funcionar para Windows 98 y XP)

raistlinM

En parte, la culpa de esto la tiene el "marketing", ahora todo hijo de vecino quiere tener una app, simplemente para poner en su web "descárgate nuestra app".
Se repite el "si no estás en internet no existes", esto no hacía daño pero sus segundas partes (facebook, twitter ahora las app) son lamentables.

Una web diseñada para móbiles es lo suyo, y cualquiera con dos dedos de frente tomaría ejemplo de muchísimas webs que hacen esto y muy bien.

A

Una app nativa de verdad está a años luz en cuanto a rendimiento y consumo comparado con otra app nativa ejecutando otro código arbitrario: http://sealedabstract.com/rants/why-mobile-web-apps-are-slow/

D

En la variedad está el gusto

D

Chorradas.

El aspecto principal de las "apps" de hoy en día, es su encapsulado, su independencia. Sí, hay toneladas de apps que no funcionan sin conexión a internet, sin una suscripción o sin una webapp de fondo. Pero eso hay que añadirlo a posta, no es un aspecto que defina a las "apps" de por sí.

Las apps son programas, puros y duros. Que luego haya quien las use para replicar las funciones del navegador... pos bueno, pos vale, pos le auguro un futuro de descojonarnos de él de forma buena.

Sofrito

El futuro es hacer aplicaciones usando la misma tecnología que usamos para la web. Las ventajas son ilimitadas:
http://miguelangellv.wordpress.com/2014/06/16/dart-y-android/

D

#13 " Las ventajas son ilimitadas:"

Para los juegos no. Para el rendimiento, tampoco. Y para tener TUS datos en tu dispositivo, menos.

Sofrito

#17 todo dependerá de la potencia de tu dispositivo. Y cada vez los dispositivos son más potentes. Y en cuanto al tema de seguridad, todo depende del programador. Si te quieren robar información, pueden hacerlo desde una aplicación web o una app "de escritorio".

D

Explicarselo a los q estan hypeados haciendo basura en android, sin pensar un segundo en como destrozan sus propias ideas usando basura. yo ya desisti hace mucho tiempo de discutir con personas q han aceptado ser exclavas de frameworks y android.

c

Nadie obliga a nada, aqui hay webs, apps, y cada uno elije lo que quiera. Eso es lo bueno.

m

Las aplicaciones tienen los días contados, aprovechad desarrolladores y no queráis saltaros un paso en el mercado, después vendrán las webs y a volver a empezar. sshhhh

piki.g.saraza

Yo creo que las apps son el futuro, paso de la wikipedia y voy instalarme la Encarta.
Y de paso el Outlook para email

Pijus_Magnificus

Las apps no existen, son los padres. Ahora bien, si os referis a aplicaciones entonces estamos hablando el mismo idioma.

Por lo demás creo que el mundo de las aplicaciones y la web pueden converger (al menos la API de la que se nutren ya es un servicio web), ya hay muchas aplicaciones que hacen uso de WebViews, aunque sin aprovechar al máximo la API del dispositivo en el que funcionan.

Zade

Hablar de BBS para demostrar que la web es mejor que las apps, es como si yo ahora hablase de Geocities para demostrar que las apps son mejores que la web. Basura de artículo para un debate interesante.

Mi opinión: Depende del uso, para buscar y tratar información "ligera" prefiero la web, pero para herramientas las apps. Por lo general prefiero las apps, me gusta más que algo sea haya pensado y construido para un fin "específico" que usar algo genérico como la web para el uso específico del momento. Lo que si que no aguanto son las aplicaciones híbridas, meter una web en una app nativa (por ejemplo la app de ING), eso es una gilipollez. O me haces una aplicación bien adaptada al terminal y aprovechando la buena usabilidad que te da una app nativa, o para eso accedo directamente por web.