Google Chrome – som set i 2008

I anledningen af at Google Chrome for et stykke tid siden kom i version 7 faldt jeg over en gammel artikel jeg fik skrevet om Chrome, den gang den var ganske ny. Jeg har prøvet at rette et par åbenlyse fejl men ellers er artiklen her gengivet uforandret. Der vil derfor naturligvis være et par observationer der nu virker ganske forældede :-)

Google Chrome er nu kommet og dermed endnu en browser på markedet. Den Anden Browserkrig har dermed fået et nyt aspekt med fire hovedroller og et par biroller: Microsoft (Internet Explorer), Mozilla (Firefox), Apple (Safari) og Google (Chrome), samt Opera og Nokia. Opera fortsætter deres egen retning med et stort sats på mobile enheder, mens Nokia har slået pjalterne sammen med Apple og Google i udviklingen af WebKit/WebCore motoren. Dette er næppe godt nyt for Opera – men hvad er reelt det disse dage? – da WebKit allerede nu bruges i alle Apple iPod Touch og Apple iPhone enheder, vil blive i Nokia’s serie 60 og gennem Google Chrome vil blive brugt i Google’s Android.

Man kan der spørge, hvorfor vil Google nu blande sig i browser markedet?

En lille tangent – der dog er relevant
Blandt udviklere har der i mange år været intense diskussioner om hvilken programmeringssprogmodel der var den bedste: Den statiske eller den dynamiske. Den statiske, der baserer sig på at man som udvikler eksplicit angiver hvad der skal ske hvordan, hvilket teoretisk gør et programs funktion umiddelbart forståeligt for en computer, har hidtil haft flest tilhængere. Det har været med sprog som C, C++, Java og C# (.NET) og de bruges da også til langt de fleste applikationer.

Alligevel har de dynamiske sprog, hvor programmøren får meget vide rammer og ikke behøver være eksplicit hele tiden, (f.eks. Perl, Python, PHP, JavaScript, Ruby) haft en stor udbredelse, så stor så f.eks. Perl var det mest anvendte til serverside kode i slutningen af 90’erne. Som jeg har omtalt flere gange viste en tysk forsker for nogle år siden den store – praktiske – forskel på sprogene: Nogle var hurtigere at udvikle i, nogle udviklede man hurtigere applikationer i.

De statiske sprog gav oftest applikationer der var dobbelt så hurtige som dem der kørte i dynamiske sprog. Til gengæld tog det oftest kun halvdelen af tiden at udvikle applikationerne i de dynamiske sprog.

Flere virksomheder, herunder JobIndex, har valgt at gå mod strømmen og udvikle i et dynamisk sprog. Det har også været en styrke for de virksomheder der har været baseret på en kundedrevet udvikling, da kravet der vil være at man skal udvikle løsningerne på meget kort tid. Og selvfølgelig har det været en fordel for de virksomheder der har haft brug for hurtigt at kunne lave ændringer til deres løsninger.

Men undersøgelsen havde et forkert udgangspunkt. Den var baseret på hvor hurtigt statiske sprog, der er blevet optimeret til performance siden 70’erne, klarede sig i forhold til dynamiske sprog, der på det tidspunkt slet ikke var fokuseret på performance.

I kølvandet på Web 2.0
Da Netscape i den første halvdel af 90’erne havde brug for et programmeringssprog der kunne kontrollere dynamiske elementer på en hjemmeside ventede de på at Sun blev færdig med Java. Det tog sin tid og i stedet valgte man at inkludere JavaScript i browseren. Det var en midlertidig løsning; “brug det her indtil det rigtige applikationssprog til hjemmesider kommer”. Vi har ventet siden…

Med den eksplosion af web applikationer der fulgte Web 2.0 blev det pludselig indlysende at sproget allerede var tilgængeligt. Over tid var JavaScript – og browserne – blevet så gode at alt det man ønskede at gøre kunne gøres. Nu var problemet blot at JavaScript var ekceptionelt langsomt. Til gengæld var der millioner af websites der ville blive bedre, millioner af tilføjelser der kunne laves, hvis bare lige JavaScript blev hurtigere.

Parallelt med denne udvikling havde det også vist sig, måske counter-intuitivt, at dynamiske sprog kunne optimeres til en hidtil uhørt performance. Faktisk til en performance der oversteg de statiske sprogs. Counter-intuitivt, idet de statiske sprog netop serverede alt for computeren så den ikke behøvede gøre noget, udover at udføre applikationen. Men som indenfor mange andre naturvidenskabelige grene har det vist sig også indenfor datalogi, at kvalificerede gæt ofte rammer godt nok og desuden er de meget hurtigere end møjsommeligt at beregne alle detaljer. Og når man så finder en måde at konstatere hvornår gættene er forkerte, så kan man nøjes med de detaljerede beregninger til de situationer.

Og også counter-intuitivt, fordi man altid til sidst skal ende med at fortolke koden i en statisk sammenhæng, alligevel.

Udviklingen har siden år 2000 givet markante performance forbedringer i dynamiske sprog (f.eks. Parrot og nu JavaScript V8 motoren).

Googles fremtid ligger – stadig – på internet
Google har for længst indset at deres succes fortsat skal baseres på udviklingen af internet til en ægte platform, og dermed overlade det stadig mindre interessante desktop marked til Microsoft, Apple og Unix folkene. Den platform har brug for en bedre performance og når nu JavaScript allerede var de facto udviklingssproget til alle applikationerne på den eksisterende platform var det oplagt at arbejde på en forbedring der.

Google kunne have valgt at lægge kræfterne hos Mozilla, og dermed Firefox, hvorimod det er utænkeligt at de ville have givet en hjælpende hånd til Microsoft (Internet Explorer). Ligeledes kunne Google næppe gå til Apple (Safari), da deres browser i høj grad er knyttet til Apple’s desktop og mobil platforme. Der er dog tre mulige grunde til at Google ikke gik til Mozilla.

For det første har Google haft det svært med Mozilla’s licens, som de mente blot var en mindre udbredt variant af allerede eksisterende licenser. Kortvarigt – indtil nok havde protesteret – blev Mozilla Public License derfor fjernet som mulighed hos Google Code. For det andet, et synspunkt Google’s Chris DiBona uofficielt har givet udtryk for, ønskede Google ikke at udsætte Firefox for at blive tynget ned, hvis Google nu begik en stor fejl. Uden Firefox ville hele browsermarkedet (igen) tilfalde Microsoft, hvilket Google under ingen omstændigheder vil tillade. For det tredie kan Google (korrekt) have fornemmet en modstand hos Mozilla mod at omskrive hele browseren, igen. Den proces havde Mozilla været igennem fra 1999 til 2004 og det er usandsynligt de ville risikere en tilsvarende forsinkelse igen.

Desuden havde Google allerede gjort sig erfaringer med WebKit i udviklingen af deres mobiltelefon, Android, og gennem Open Handset Alliance (med bla. Apple og Nokia). Dette kunne være den fjerde grund til at vælge WebKit i stedet for Mozilla’s kode. Det kan selvfølgelig også være at WebKit projektet var et eksperiment for at se om det kunne bruges.

Perspektiver
Internet som en platform kommer. “The future is already here, it’s just not evenly distributed yet” som William Gibson har sagt, og på mange områder kan man se det i en række Web 2.0 applikationer. Platformen vil flytte vores fokus fra desktoppen (og mobilen) til internettet, hvilket er en stor udfordring for de “gamle” IT selskaber. Tænk Microsoft… For at understøtte platformen har Google brug for at internettet er et “fair, smart, safe place”.

For virksomheder der udvikler webløsninger betyder det at man skal øge fokus på JavaScript udvikling og derigennem mere dynamisk og interaktivt indhold. Google Chrome er i virkeligheden udtryk for at JavaScript er blevet og fremover vil være det sprog der vil tilgængeligt overalt, på alle platforme.

Links:

http://www.google.com/googlebooks/chrome/small_36.html

Hvorfor Google Chrome (af Scott McCloud):

http://www.google.com/googlebooks/chrome/index.html

Nokia serie 60 vil bruge WebKit: http://press.nokia.com/PR/200506/998214_5.html

Jeg vil tilføje at vi allerede i dag reelt har Internet som en platform og at Microsoft Internet Explorer 9 indeholder en stærkt forbedret JavaScript performance.

Dette indlæg blev udgivet i Udvikling og tagget , , , , , , . Bogmærk permalinket.

Skriv et svar

Udfyld dine oplysninger nedenfor eller klik på et ikon for at logge ind:

WordPress.com Logo

Du kommenterer med din WordPress.com konto. Log Out / Skift )

Twitter picture

Du kommenterer med din Twitter konto. Log Out / Skift )

Facebook photo

Du kommenterer med din Facebook konto. Log Out / Skift )

Google+ photo

Du kommenterer med din Google+ konto. Log Out / Skift )

Connecting to %s