Opera abandona el desarrollo propio y se suma a WebKit
efrigerio
El día 12 del corriente, la empresa Opera, ha anunciado que abandonará el desarrollo de los distintos elementos que hacen a sus navegadores (Opera Desktop, Opera Mobile y Opera Mini).
A partir de ahora, empleará WebKit como kernel, Chromium como interfaz de usuario y Google V8 como motor de JavaScript.
Si, los mismos elementos empleados por el navegador Chrome.
Una versión preliminar para Android será presentada en el Mobile World Congress 2013 de Barcelona.
Según la hoja de ruta trazada, Opera reemplazará las tecnologías propias por sus equivalentes de manera progresiva, empezando por los dispositivos móviles y terminando en el desktop.
Esta noticia, ha sido recibida con escepticismo por parte de los analistas de mercado, y con un pésimo humor por parte de las comunidades (tanto de desarrolladores de Opera como de usuarios).
La pregunta de unos y afirmación de otros ...
Si este navegador, se ve, se siente, se comporta y (en especial) se presenta ante los servidores como una variante de Chrome. Entonces.
¿¡Qué sentido tiene utilizar Opera en vez de Chrome!?
¿Qué significa esto para Java?
En principio, decirle adiós al único navegador web decente y de adopción masiva escrito en Java que ha existido.
Adiós Opera Mini, y gracias por los servicios prestados.
Y en segundo término, WebKit visto como una "Foundation Classes" tiene (y esto es algo que se puede observar en las apiDoc de JavaFX y "en especial" en Qt Jambi) una gran superposición de funcionalidad con JavaSE. Es decir, sus propios objetos URL, Connection, Document, script, etc. por fuera de los que existen en la JFC. Por lo que se termina con un bajo nivel de acoplamiento contra la JVM o con una enorme cantidad de clases duplicadas como en Qt Jambi.
Por otra parte, es de estas funciones de la que sacan partido diferentes proyectos como PhoneGap para construir aplicaciones "oblicuas" o multiplataformas.
¿Cual es vuestra opinión?
Como veis la decisión de Opera de "arrojar la toalla y sumarse a la manada" dejando en el proceso a java de lado en favor de C++.
Reader Comments (7)
Efrigerio Opera Mini es un navegador tipo proxy, es Presto el que está en el lado servidor, y si quisieran podrían hacer algo parecido pero con WebKit en el servidor, no serían los primeros, aunque alguno de esos navegadores haya desaparecido tal y como Bolt.
La decisión imagino que viene dada porque apenas hacen dinero con el navegador Opera para encima tener que mantener Presto. Es una cuestión de dinero y foco de negocio.
En realidad, Opera Mini habla WAP/ECMAScript. Y si el servidor (como sucede con los de Google o los de Yahoo) reconoce esto, envía el contenido en este formato y el browser lo parsea / renderiza en local sin utilizar el servidor de Opera.
De lo contrario el servidor de Opera convierte de Web/javascript a una versión optimizada de WAP/ECMAScript para Opera Mini.
Mi pregunta es, ¿de dónde se ha sacado la gente que se vaya a cambiar la interfaz? Lo único que dice el anuncio oficial es que se cambia el motor de Presto a WebKit. Dicho esto, a mi entender, el navegador debería mantener el mismo interfaz gráfico y experiencia de usuario, únicamente con un motor diferente (que podrá ir mejor o peor, eso ya lo veremos en su día).
Yo habia leido que cambiaban el motor, que bueno, vale, se admite, pero no quiero que me cambien el interface de usuario...
Yo uso opera.
Un par de aclaraciones, si no esto no se entiende del todo.
Para empezar, WebKit es un "kernel de navegadores"no un motor de randerizado o un " widget toolkit". De hecho, este es el motivo por el cual SUN lo agrego a JavaFX, ya que le permitía unificar la capa de randerizado con la del resto de los componentes dentro del toolkit.
En segundo término, hace unos años Opera rompió lanzas con QT y decidió crear su propio toolkit.
Para este toolkit, en lugar de decantarse por una forma de programación procedural (como es en C) o OOP con componentes (como los que tenemos en Java), decidieron emplear lenguaje declarativo con partes imperativas como puede ser el caso de DHTML o PLSQL.
Para esto, se basaron en el Parser DOM que ya tenían para HTML, WAP, SVG.
Y para la parte imperativa, su runtime de JavaScript, camvas y SVG animation.
Por lo que hablar de Presto, es hablar de casi todo en los navegadores de Opera (menos la capa de comunicaciones), de los plugin's, y de los widget.
Eduardo WebKit renderiza HTML, es básicamente un navegador web sin "barra de direcciones" si además le añades "enchufado" un motor JavaScript ¿me equivoco?.
Vale, Presto puede representar casi todo en el mundo Opera pero de lo que estamos hablando es de adios al renderizador HTML/SVG (de la parte JavaScript no tengo ni idea) ¿no es así?
¿es básicamente un navegador web?
Si, como el kernel de linux es básicamente un OS, aunque le falte todo lo que le agregan Debian, Ubuntu, Fedora, SUSE, y el resto de las distribusiones y que lo complementan.
En el caso de WebKit (y entre otras cosas) es el building con las primitivas graficas y los flujos de vuelta (teclado y mouse), que cada navegador / OS (Symbian, Chrome, Safari, Android, KDE, JavaFX, etc) resuelven por su cuenta.
De allí es que no lo considero un motor de randerizado o un "widget toolkit". Pero si un "layout engine".
En el caso de Chrome y el futuro de Opera esto se hace desde Chromium.
Un saludo.