Arstechnica torna sulla questione Webkit, l’engine che Google ha deciso di abbandonare in Chrome per passare a un suo fork denominato “Blink”. Quanti sono impegnati nei due engine in questione stanno rimuovendo da una parte e dall’altra elementi di cui non hanno più bisogno, scelte che alla fine potrebbero essere fonte di grattacapi per gli sviluppatori. Apple sarà in grado di continuare a guidare il progetto WebKit ora che Google non lo supporta più? Apple e Google sono state infatti le due società che più di altre hanno contribuito alla creazione e allo sviluppo di questo ormai onnipresente motore di rendering per browser, nato a sua volta come fork open source del motore KHTML. Da quando Google rilasciò la prima versione di Chrome nel 2008, il WebCore, la parte del WebKit che si occupa effettivamente dell’elaborazione di HTML e CSS ha servito due padroni; benché in modo diverso, Apple e Google, hanno sfruttato vari componenti in modo diverso, differenti Java engine (JavaScriptCore, detto “JSC” per Apple, V8 per Google), adottato approcci diversi per la gestione del multiprocessing e del sandboxing.
Il WebCore ha finora dovuto tenere conto di tutti questi aspetti; JavaScript, ad esempio, non è stato strettamente integrato con codice in grado di gestire il DOM (la base per una vasta gamma delle interfacce di programmazione delle applicazioni), poiché questo doveva essere gestito da un layer intermedio in grado di assicurare l’interoperabilità con JSC e VP8. A detta di Google, il nuovo fork permetterà sviluppi più veloci su entrambi i versanti; i rispettivi team, come già detto sono al lavoro, eliminando codice superfluo. Al momento il compito sembra più facile per Google e loro sviluppatori potranno attivare in modo permanente funzionalità che in precedenza (con il WebCore) erano ritenute opzionali.
La posizione di Apple è più complicata: sono molti i progetti che sfruttano e si appoggiano al WebKit e nessuno può sapere quali sono le funzionalità effettivamente richieste in progetti di terze parti. Apple potrebbe voler rimuovere il layer JavaScript e ricorrere solo a JSC ma alcuni progetti derivati dal WebKit potrebbero dipendere dalla presenza di questo layer. Samsung, ad esempio, sfrutta il WebKit con l’engine V8 ma con la decisione di Google di creare un fork, nessuno ora si occuperà di curare la sezione che tiene insieme questi due elementi. Apple potrebbe decidere di affidare a terzi la cura di elementi di questo tipo e mantenere per sé la propria variante, un compito arduo man mano che Cupertino aumenta l’integrazione tra JSC e WebCore.
Oracle lavora su un progetto simile: una variante del WebKit con integrato un proprio engine JavaScript denominato “Nashorn”, basato sulla Java virtual machine e che presenta alcuni vantaggi rispetto all’astrazione JavaScript e che diventerà complesso da gestire se Apple rimuoverà le astrazioni.
Un possibile punto di vista positivo è che varianti del Webkit potrebbero invece consolidarsi. Coloro che vogliono appoggiarsi all’engine V8 potrebbero passare a Blink e quelli che usano JSC restare con il WebKit. Google finora si è occupata della manutenzione di molte parti di codice, elementi che probabilmente toccherà ora ad Apple mantenere decidendo cosa eliminare e cosa mantenere. Cupertino dovrà fare ad ogni modo molta attenzione: un conto è eliminare l’engine JavaScript, un altro eliminare funzionalità considerate per molti standard. Se Apple non saprà valutare attentamente le mosse da fare, il rischio è che gli sviluppatori cominceranno con il passare del tempo a supportare Blink e considerare WebKit uno strumento di seconda classe.
[A cura di Mauro Notarianni]
