Nativo
Tecnología
Entiendo que hay millones de buenas ideas que terminan en nada. Da igual lo buenas que sean, si al cabo de un tiempo no consiguen suficientes beneficios como para compensar el coste de su desarrollo se eliminan del mapa sin piedad. Es un fenómeno más que común en las empresas que cambian del modo "vamos a aumentar nuestra cuota de mercado", "vamos a aumentar la facturación" o "vamos a pasar el rato" a "vamos a ganar dinero". Google se ha cepillado un montón de utilidades y librerías e IBM empieza a replantearse lo de la supercomputación a precio de coste ahora que empieza a vender a bancos y ISPs.
He descubierto una de estas herramientas que, siendo una idea cojonuda, puede ser que le llege su San Martín en un año y pico.
Hace unos años todas las aplicaciones que podía utilizar una empresa eran aplicaciones de escritorio. Esto consolidó Windows y Java (C++ menos) dentro del entorno empresarial. Todo el mundo podía presuponer que en cada PC de oficina del mundo habría Windows (más o menos actualizado) y una máquina virtual de Java.
El tiempo pasó y llegó la revolución de Internet, la chorrada del web 2.0 y Javascript. Las páginas web ya podían correr código asíncrono y ceder parte de la carga al navegador. Esto ha evolucionado hasta ver interfaces gráficas de sistema operativo enteras en el navegador (si no me equivoco esto era lo de EyeOS). Y hemos visto llegar este tipo de virguerías por dos motivos. Los intérpretes de Javascript han mejorado significativamente en los últimos años. De hecho hay una guerra abierta entre MSFT, Google y la fundación Mozilla para ver quién tiene el intérprete de Javascript más potente. También porque, a demás de Windows y una máquina virtual de Java, en cualquier PC de oficina hay también un navegador.
Pero aunque el intérprete de Javascript pueda conseguir que una aplicación web asíncrona parezca una aplicación de escritorio no podrá nunca hacer lo mismo. El principal motivo es que, por seguridad, los intérpretes de Javascript pueden hacer una cantidad muy limitada de cosas. Por ejemplo no pueden hacer llamadas directas a memoria ni acceder a dispositivos (que estrictamente hablando es lo mismo) o ejecutar código concurrente.
Este es el motivo por el que el Native Client de Google me parece una idea cojonuda. En el fondo es extender el navegador con código objeto escrito en C++, algo que los que hemos usado Python o Matlab para HPC llevamos haciendo varios años (en mi caso ya más de un lustro). Tampoco es un concepto muy nuevo. MSFT ya lo intentó con ActiveX, pero fue un fracaso absoluto. No me he molestado demasiado en descubrir los motivos.
Esta herramienta puede tener usos muy interesantes en el desarrollo de aplicaciones en entorno empresarial, donde se quiere hacer algo más que subir fotos, chatear o rellenar formularios. Además Chrome está ganando aceptación y ya no se considera un "capricho para hackers" en las oficinas.
Quizás tenga razón y sea algo que esté en el portfolio de posibilidades de cualqueir empresa, o quizás me equivoco y el Native Client SDK muera en año y medio.
Comentarios
Entiendo que hay millones de buenas ideas que terminan en nada. Da igual lo buenas que sean, si al cabo de un tiempo no consiguen suficientes beneficios como para compensar el coste de su desarrollo se eliminan del mapa sin piedad. Es un fenómeno más que común en las empresas que cambian del modo "vamos a aumentar nuestra cuota de mercado", "vamos a aumentar la facturación" o "vamos a pasar el rato" a "vamos a ganar dinero". Google se ha cepillado un montón de utilidades y librerías e IBM empieza a replantearse lo de la supercomputación a precio de coste ahora que empieza a vender a bancos y ISPs.
He descubierto una de estas herramientas que, siendo una idea cojonuda, puede ser que le llege su San Martín en un año y pico.
Hace unos años todas las aplicaciones que podía utilizar una empresa eran aplicaciones de escritorio. Esto consolidó Windows y Java (C++ menos) dentro del entorno empresarial. Todo el mundo podía presuponer que en cada PC de oficina del mundo habría Windows (más o menos actualizado) y una máquina virtual de Java.
El tiempo pasó y llegó la revolución de Internet, la chorrada del web 2.0 y Javascript. Las páginas web ya podían correr código asíncrono y ceder parte de la carga al navegador. Esto ha evolucionado hasta ver interfaces gráficas de sistema operativo enteras en el navegador (si no me equivoco esto era lo de EyeOS). Y hemos visto llegar este tipo de virguerías por dos motivos. Los intérpretes de Javascript han mejorado significativamente en los últimos años. De hecho hay una guerra abierta entre MSFT, Google y la fundación Mozilla para ver quién tiene el intérprete de Javascript más potente. También porque, a demás de Windows y una máquina virtual de Java, en cualquier PC de oficina hay también un navegador.
Pero aunque el intérprete de Javascript pueda conseguir que una aplicación web asíncrona parezca una aplicación de escritorio no podrá nunca hacer lo mismo. El principal motivo es que, por seguridad, los intérpretes de Javascript pueden hacer una cantidad muy limitada de cosas. Por ejemplo no pueden hacer llamadas directas a memoria ni acceder a dispositivos (que estrictamente hablando es lo mismo) o ejecutar código concurrente.
Este es el motivo por el que el Native Client de Google me parece una idea cojonuda. En el fondo es extender el navegador con código objeto escrito en C++, algo que los que hemos usado Python o Matlab para HPC llevamos haciendo varios años (en mi caso ya más de un lustro). Tampoco es un concepto muy nuevo. MSFT ya lo intentó con ActiveX, pero fue un fracaso absoluto. No me he molestado demasiado en descubrir los motivos.
Esta herramienta puede tener usos muy interesantes en el desarrollo de aplicaciones en entorno empresarial, donde se quiere hacer algo más que subir fotos, chatear o rellenar formularios. Además Chrome está ganando aceptación y ya no se considera un "capricho para hackers" en las oficinas.
Quizás tenga razón y sea algo que esté en el portfolio de posibilidades de cualqueir empresa, o quizás me equivoco y el Native Client SDK muera en año y medio.