Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Je kunt ook een cookievrije versie van de website bezoeken met minder functionaliteit. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 102 reacties, 22.119 views •
Submitter: Nakebod

Google werkt aan zijn eigen browserrenderengine onder de naam Blink. Aanvankelijk is de engine nog gebaseerd op de code van opensourcesoftware WebKit, maar hij zal gaandeweg zijn eigen gang gaan. Ook Opera stapt over op Blink, dat nu de basis voor Googles Chromium-project is.

De reden om WebKit te forken is volgens Google dat de innovatie gehinderd werd door de toegenomen complexiteit van zowel WebKit als Chromium. Chromium is het opensourceproject dat aan de basis staat van de Chrome-browser en Chrome OS. Er zijn echter al een aantal fundamentele verschillen tussen Chromium en andere op WebKit gebaseerde browsers: zo gebruikt het Chromium-project een andere multiprocess-architectuur.

Voor webontwikkelaars zal er de komende tijd weinig veranderen, belooft Google. De eerste stap zal volgens het bedrijf zijn om de code op te schonen. Google verwacht direct zeven buildsystems en meer dan zevenduizend bestanden, goed voor in totaal 4,5 miljoen regels code, te kunnen schrappen. Op de lange termijn zorgt een gezonde codebase voor een stabielere browser met minder bugs, stelt de Chrome-ontwikkelaar.

Desondanks zal de fork op termijn wel van invloed worden op webontwikkeling. WebKit is de basis van niet alleen Chrome, maar ook Apples Safari en Opera en deze bedrijven droegen gezamelijk bij aan de ontwikkeling. Het afsplitsen van Blink zal de opensourcecommunity van WebKit-ontwikkelaars voor een keuze stellen. Ook zal Google eigen functionaliteit aan Blink toevoegen en kan het bedrijf nu zijn eigen keuzes maken wat ondersteuning van nieuwe web-standaarden betreft.  Volgens Google zorgt het hebben van meerdere renderengines echter voor meer innovatie en ook zou het in de woorden van het bedrijf bijdragen aan 'de gezondheid van het totale open web-ecosysteem'.

Opera zal Google volgen en ook van Blink gebruik gaan maken, zowel bij de desktop- als de mobiele versies van de Opera-browser. "Toen we aankondigden Presto achter ons te laten, maakten we bekend met Chromium verder te gaan en het forken en de verandering van naam is van weinig invloed op de Opera-browsers", zegt een Opera-woordvoerder tegen The Next Web.

De naam Blink refereert naar het veel bekritiseerde en niet gestandaardiseerde blink-element van html die tekst kon laten knipperen. De ontwikkeling van WebKit zelf werd in 2001 in gang gezet door Apple als fork van khtml en KDE's JavaScript-engine. De W3C waarschuwde een jaar geleden nog voor de dominantie van WebKit, die een browsermarktaandeel van ongeveer 40 procent heeft. Firefox gebruikt de Gecko-engine en Internet Explorer gebruikt Trident.

Update, 12.50: Volgens Google Chrome-ontwikkelaar Alex Russell zal Blink vooral de ontwikkeling van de Google-browser versnellen en werd dit gehinderd door de gezamelijke ontwikkeling van WebKit. Ook stelt hij dat ontwikkelaars met Blink minder bang hoeven te zijn dat aanpassingen onbedoelde gevolgen krijgen. Een medewerker van Chrome-beveiligingsteam, Justin Schuh, zegt dat Blink de mogelijkheid biedt 'heel wat beveiligingsproblemen die zich hebben opgestapeld aan te pakken'. Hij wijst onder andere op de ontwikkeling van Site Isolation.

Reacties (102)

Reactiefilter:-11020100+161+211+31
lgens Google zorgt het hebben van meerdere renderengines echter voor meer innovatie en ook zou het in de woorden van het bedrijf bijdragen aan 'de gezondheid van het totale open web-ecosysteem'.
Ik geloof wel dat dit voor meer innovatie gaat zorgen, maar we krijgen nu wel weer verschillen. Internet Explorer gaat zich eindelijk weer aan de 'regeltjes' houden en nu moeten zij het weer anders doen...
Een andere engine of meerdere engines zegt niks over het wel of niet aan de standaard houden natuurlijk.
Dat is waar, maar ik ben bang dat het toch altijd net iets anders wordt gerenderd waardoor je, al zijn het minimale, verschillen krijgt.
Dat probleem bestaat helaas nu al tussen verschillende browsers, zelfs als ze allemaal WebKit gebruiken. Dit komt omdat verschillende browsers nog steeds verschillende rendering backends kunnen gebruiken met bijvoorbeeld verschillende font rendering of verschillende GPU acceleratie.

Ondanks dat je je aan de standaard houdt gaat er simpelweg niets boven ouderwets testen in verschillende browsers ;)
Precies, en vergeet ook niet de verschillende besturingssystemen.... Chrome b.v. ziet er (fonts meestal) vaak anders uit op Windows, OSX en Linux.
En denk ook aan de verschillende chrome elementen (input types) van een browser, drop-downs, radio buttons, multiselect/checkbox etc.
Maar ik stel mij toch de vraag hoe het WebM debacle zou zijn afgelopen als Google beschikte over hun eigen browser engine in tegenstelling tot een engine waar ze meer rekening moet houden met anderen.

Het gevaar schuilt dat ze een IE'tje kunnen doen en in tegenstelling tot holle reclameslogans zoals "don't do evil", ben ik toch wat op mijn hoede voor zo'n zaken. Ik wil het echt niet terug meemaken dat tijdperk. Ook heel die CalDAV historie laat toch een vieze smaak na in mijn mond.

Naar wat ik gelezen heb heeft het ook te maken dat men bij webkit nogal strenge eisen stelt inzake het breken van stuff. Veel van die regels code die ze willen verwijderen zijn bvb tests en dergelijke voor andere platformen.

Elke patch & commit moet door een batterij tests (voor elk platform) lopen en vanaf dat ze ergens falen dan worden patches niet toegelaten. Het schijnt dat dit een doorn is in het oog is van Google. Dus compatibiliteit of incompatibiliteit heeft er ergens wel mee te zien.

[Reactie gewijzigd door simplicidad op 4 april 2013 09:13]

Wat heeft WebM te maken met de browser engine? Chrome ondersteund WebM, ook als het dezelfde browserengine gebruikt als Safari. De ondersteuning voor een codec heeft bar weinig met de browserengine te maken.
(voor elk platform)
Multiplatform is soms een voordeel, maar soms ook gewoon een groter nadeel. Het is prachtig dat je programma nog draait op een Sparc of andere zwaar specialistische instructieset, maar als er dan een fout ontstaat moet Google iemand in dienst nemen die fouten kan oplossen in een versie die een paar mensen kunnen gebruiken...

Daarnaast moet je ook goed bedenken wie 'verantwoordelijk' is voor dergelijke builds. Je kunt ook besluiten dat je maar 1 of 2 architecturen ondersteunt en de rest is een port vanaf die codebase. Op die manier heb je een paar mensen die af en toe een versie exporteren en builden en de 'quirks' in de gaten houden in plaats van je hele developmentteam continu op te houden. Daarbij zijn er vaak speciale bibliotheken beschikbaar die dat eenvoudiger maken, daar hebben uiteindelijk meer mensen iets aan dan één heel specifiek programma.
Het lijkt me ook niet dat ze een ongebruikelijk OS zullen gebruiken voor het testen, maar de verschillende windows versies (bv tot xp) een paar linux distributies en osx voor de desktop en ios6, android 2.3/4.0 en mogelijk nog een ander os lijkt me toch wel het minimale.

Je moet als browserfabrikant gewoon rekening houden met je doelgroep en die bevindt zich gewoon op verschillende platformen. Minder testen lijkt me in dit tijdperk niet de bedoeling. Soms zie ik het bij de Beta en Dev van Chrome ook helemaal fout gaan. Dan ben ik ergens mee bezig en werkt het niet zoals het hoort terwijl dit in andere browsers geen probleem is. Ja, dat lees je goed, Webkit werkt soms niet goed meer. Al 4x gehad dat ik een dag of 2 aan het zoeken ben geweest waarom chrome de pagina niet goed weergeeft.
Momenteel lijkt ie schijt te hebben aan het toepassen van antialiasing aan fonts (of cleartype) en bij css animaties zie je vaak bij sommige animaties dingen verspringen omdat de hele pagina naar de videokaart gaat ipv een klein deel (firefox en IE10 doen dat wel goed)

[Reactie gewijzigd door Martinspire op 4 april 2013 11:21]

Indirect wel. Zolang er meerdere veelgebruikte engines zijn, hebben zowel browsermakers als webdevelopers geen andere keus dan zich aan een algemene standaard te houden. Zodra er een monopolie ontstaat (zoals vroeger het geval was met Internet Explorer) is het nog maar een kleine stap naar het gebruik proprietary protocollen, waardoor concurrentie een stuk lastiger wordt.
En mozilla gaat een nieuwe engine ontwerpen from scatch. Dat komt met dit bericht ook in een ander daglicht te staan.

Interessante tijden, zal dit een bijdrage worden? Of blijkt de versnippering juist funest te zijn? De tijd zal het leren. Mijn glazen bol doet het op dit moment even niet.

edit -typo

[Reactie gewijzigd door Danib op 4 april 2013 08:52]

Het lijkt wel het kiezen tussen twee kwaden:

1) één zeer dominante browser/engine (bijv. IE6)

Voordelen:
  • 1 codebase voor web-devs
  • minder testen
Nadelen:
  • 1 bedrijf heeft monopolie en kan doen wat 'ie wil (platforms uitsluiten bijv.)
  • nauwelijks progressie
2) meerdere engines naast elkaar

Voordelen:
  • progressie door concurrentie
Nadelen:
  • testen, testen, testen
  • uitzonderingen in HTML/CSS/JavaScript

[Reactie gewijzigd door Rekcor op 4 april 2013 08:53]

Als webdevs nu zo lui aan het worden zijn dat ze nog maar een codebase wensen dan moeten ze nog maar eens goed over hun beroep nadenken. Firefox heeft in koude jaren vele mensen uit de brand geholpen en ervoor gezorgd dat MS niet te veel kan blijven leunen op hun oude browsers & oude features. Dat had niet gekund zonder diversificatie. Het bewaren en koesteren van open standaarden is niet alleen belangrijk in barre tijden. Het is minstens net zo belangrijk in goede tijden. Er zal geen vooruitgang geboekt worden zonder concurrentie en dus ook niet zonder verschillende codebases.

[Reactie gewijzigd door MaestroMaus op 4 april 2013 09:02]

1 codebase is misschien geen uitkomst, maar het lijkt er nu op dat we al richting de 8 verschillende browsers toegaan. Dat hindert het ontwikkelproces ook enorm.
Eerst had je al IE (6,7,8,9,10), Firefox, Chrome, Opera en Safari waar je voor moest ontwikkelen. Daar kwamen vervolgens nog de tablet en smartphone versies bij en nu hebben we ineens dat ze allemaal nieuwe engines of forks gaan gebruiken.
Alleen Opera is hierbij echt weggevallen, maar die kun je ook nog niet helemaal stoppen want de webkit versie moet nog komen.
Gelukkig verschilt IE10 niet veel van IE11, maar omdat IE10 nog niet overal op zal komen (hij is niet verplicht op Win7), zul je dus ook nog oude browsers moeten ondersteunen.

Al met al dus veel extra werk. Als er nou minder verschil zat tussen de mobile en tablet, was het te overzien, maar inmiddels is dat ook al niet meer en gaat het ook daar zijn eigen weg.
Ik wil best mn site testen, maar ga voor een project van 2 weken niet nog een volle week besteden aan alle mogelijke combinaties, want daar gaan we straks wel naartoe.

[Reactie gewijzigd door Martinspire op 4 april 2013 11:26]

Ik wil best mn site testen, maar ga voor een project van 2 weken niet nog een volle week besteden aan alle mogelijke combinaties, want daar gaan we straks wel naartoe
Waarom niet? Een project duurt dan gewoon 3 weken. Het mag dan saai en vervelend werk zijn, het is wel werk wat je gewoon kunt factureren. Hoe meer browsers en verschillen hoe meer werk voor webdevers hoe beter zou je toch denken.
De logica die je nu gebruikt staat ook wel bekend als de "broken window fallacy": http://en.m.wikipedia.org/wiki/Parable_of_the_broken_window

Zoals het repareren van een kapot raam geen winst levert aan de economie door het geld dat besteed moet worden aan de reparatie, zo ook levert nodeloos testen geen winst. In plaats van dat testen had de klant namelijk ook minder geld kwijt kunnen zijn en de developer alweer aan een volgend project bezig kunnen zijn.

Let wel, ik argumenteer niet tegen goed testen door developers, maar het kan ook de spuigaten uitlopen natuurlijk.
We zijn al 4 versies verder met IE en het grappige is dat IE10 het minst erge is gezien dat hele Webkit compatibiliteit gebeuren. Ik snap dus niet waar je heen wil met je verhaal. En MS heeft totaal geen monopolie meer.

Wel goed nieuws dat Webkit nu minder gepushed wordt. Kunnen devs zich eindelijk eens focussen op correcte code.

[Reactie gewijzigd door Relief2009 op 4 april 2013 09:04]

Wat belet de rest van ook niet over te stappen. Ik gok dat er toch een groot deel google werk achter webkit zit en als ze die terugtrekken is het maar de vraag of de rest dat kan opvangen (onderhoud == onderhoud). Daarom is het voor de rest wat betreft overlevingskansen nu (denk ik) het verstandigst om bij Google op de boot te blijven -onder moeder vleugels-.

Hetzelfde gevaar is er bij MySQL en zijn 'recente´ dochters (engines, mariadb enzo) welke feitelijk niet zonder Oracle kunnen overleven omdat de community te klein is om MySQL (zelf) bijgewerkt te houden.

Ja tuurlijk kan een MS, Apple of andere groot software bedrijf het oppakken, maar financieel is dat minder gunstig voor ze..

[Reactie gewijzigd door analog_ op 4 april 2013 09:15]

Je weet toch wel dat Apple een van de grootste contributors van Webkit is? Zoals in het artikel staat hebben zij Webkit geforkt van KDE... Ik zou me dan ook geen zorgen maken over de toekomst van webkit...
Dat is dus NIET zo, over de hele periode van begin webkit tot vandaag heeft Apple 37% bijgedragen net als Google, echter is Google maar minder dan de helft van de tijd actief, ga je dus over nu kijken per dag is Google ruim 2x zo actief in hun bijdrage!

http://photos.appleinsider.com/webkit-2013.png

Er zijn 10-allen bedrijven die mee werken en Googles aandeel is ongeveer 50% van alle bijdrage dus zet er echt veel meer mensen op in (42% van alle auteurs is van Google tegenover 11% bij Apple en de rest is allemaal veel lager)) :)

[Reactie gewijzigd door watercoolertje op 4 april 2013 10:43]

Dat is dus NIET zo, over de hele periode van begin webkit tot vandaag heeft Apple 37%
Apple 37,96% Google 37,73%
Apple is niet alleen één van grootste maar de grootste "contributor" (let op de quotes)!
echter is Google maar minder dan de helft van de tijd actief, ga je dus over nu kijken per dag is Google ruim 2x zo actief in hun bijdrage!
Het aantal commits per tijdseenheid zegt helemaal niets over geleverde bijdrage!
De geleverde bijdrage kun je alleen maar bepalen door te kijken naar wat er gecommit is.

[Reactie gewijzigd door Carbon op 4 april 2013 10:19]

Het is het enige meetbare dus daar moeten we het mee doen. Maar het kan dus nog veel positiever voor Google uitvallen, gezien die 4x zo veel personeel er op hebben gezet zijn hun commits waarschijnlijk groter...

Het is dus wel degelijk aannemelijker dat Google (veel) meer bijdraagt sinds 2008 (toen is Google webkit gaan gebruiken)...

Als je de grootste bent ben je OOK 1 van de grootste :)

[Reactie gewijzigd door watercoolertje op 4 april 2013 10:43]

Waar staan de manuren?
dat is dan weer een aanname die nergens op slaat, het kunnen bijvoorbeeld net zo goed bugfixes zijn van een regel (hoewel daar ook ooit veel tijd in kan gaan zitten).

En wie weet zijn de helft van de commits van apple enkel het verhogen van het type nummer (moet ook gebeuren)

Dus ook met het aantal gereviewde commits kun je nog steeds niets zeggen over de bijdrage.

Maar gezien het werk dat Google in chrome verzet verwacht ik inderdaad wel dat zij veel bijdragen aan functionaliteit en bug fixes.

Je zult dus echt moeten kijken nara de commits zelf voordat je er iets echt nuttigs over kan zeggen.
Inderdaad burgt. De diagrammetjes zeggen op detail niveau niet genoeg om overdreven sterke uitspraken over te doen. Het aantal commits zegt niks over de impact en de grootte en aantal auteurs zegt niks over de inhoud van de commits.

Iedereen die neutraal kijkt naar webkit weet dat zowel Apple als Google veel bijdragen. Dat is het enige wat ik zeg in het stukje waar Watercoolertje zo onnodig fel op reageert: Dat Google wegvalt is erg vervelend, maar Apple is nog steeds (en vanaf het begin) een van de grootste contributors van Webkit.
Dat het wordt ontkent met hoofdletters doet niks af aan het letterlijk waar zijn van dat statement.

[Reactie gewijzigd door curumir op 4 april 2013 13:21]

Als je de grootste bent ben je OOK 1 van de grootste
Grapjas!

Het stukje "Apple is niet alleen één van grootste" refereert aan jouw ontkenning!
Niet alleen naar wat er gecommit is, maar ook wat er behouden is gebleven. Ik kan me voorstellen dat van sommige functionaliteiten deze wel 5x van opzet kan zijn veranderd (juist omdat het niet door de test komt). Dan ziet de commit er wel prima uit, maar kan het gewoon iets ouds overschrijven. Dan zou bv Chrome maar 10% hebben toegevoegd (rustig, het is een voorbeeld).
Nou, waar ik heen wil met mijn verhaal is dit; we zijn heel lang met MS in IE6 land gebleven. Waarom? Omdat MS over het algmeen zo lang mogelijk doet met zijn software (kosten/baten).

Firefox (en later Chrome) nam puur door kwaliteit een groot deel van de markt af van IE en forceerde MS om nieuwe browsers uit te brengen die beter waren (sneller met javascript, zich beter houden aan standaarden, etc.). Was dit niet gebeurd dan hadden we nu allemaal nog steeds iets in de richting van IE6 gehad. Iets was MS natuurlijk prima gevonden had (jij betalen zij doen er haast niets voor).

Het feit dat MS zich nu beter aan de regels houdt en probeert met een kwalitatief goede browser te komen komt niet omdat MS dat zo leuk vindt. Die hadden veel liever met hun eigen "html standaard" doorgegaan en veel liever niet geinvesteerd in een betere browser.

En IE is de "minst erge"? Alleen als je voor IE10 sites bouwt ja. Maar serieuze website bouwers houden zich toch minimaal nog met IE8 t/m IE10 bezig nu.

Maar nu terug naar mijn opmerking: de enigste manier waarop je de verschillende browsermakers forceerd om hun browsers beter te maken is door concurrentie. Anders treed er stilstand op net als bij MS destijds. Dat is wat ik wilde zeggen met mijn vorige reactie.

[Reactie gewijzigd door MaestroMaus op 4 april 2013 09:30]

Hoe weet jij nu of ze liever hun eigen standaard hadden? Dat kunnen we ook zeggen over iedere andere browsermaker, en als we dan toch bezig zijn: het W3C heeft al enkele leren gezegd dat IE de beste implementatie van de standaarden heeft...

Als je problemen hebt met het ontwikkelen voor IE9 en 10, dan doe je iets fout, en ook IE8 geeft lang niet zoveel problemen als laat voordoen...
Ik heb regelmatig problemen met IE9 (missing WebSockets, anyone?), om over IE8 nog maar te zwijgen. Dat ze vooruit gaan valt niet te ontkennen, en IE10 is in mijn dagelijkse ervaring idd eindelijk op het niveau gekomen dat het praktisch geen extra effort meer kost om te ondersteunen. Maar zo rooskleurig als jij het laat voorkomen is het ook weer niet.
Ik voorzie meer verschillen tussen de browsers op iOS en Android. Dan zijn het in de toekomst niet zozeer de verschillen tussen de desktop browsers die irritant doen, maar juist de smartphones en tablets.
Het nadeel "1 bedrijf heeft monopolie" gaat m.i. niet op in het geval van WebKit; er zijn meerdere partijen die eraan kunnen ontwikkelen - en dit daadwerkelijk doen. Ook is het open source en kan bij stagnatie de ontwikkeling altijd weer door een ander opgepakt worden om zo de progressie te waarborgen.

Neemt niet weg dat meerdere engines het voordeel blijft houden dat er gestandaardiseerd wordt op basis van documentatie/een definitie van de functionaliteiten, in plaats van op implementatiedetails van 1 engine.

Het grote probleem wat zich nu voordoet met Webkit is dat in het geval van CSS de items met -webkit- prefix niet uitgefaseerd worden én dat WebKit dominant is op de mobiele markt. Hierdoor gaan webontwikkelaars de fout in door de standaardversie niet te implementeren. Dat is een heel ander probleem dan wat er in het IE6-tijdperk was (verschil van interpretatie qua standaarden).

In principe is het dus goed dat er meerdere engines zijn, mits dit niet resulteert in (wezenlijke) interpretatieverschillen van de W3C-standaarden - pas dan wordt 't echt vervelend voor web-ontwikkelaars.
Eugh, dat het open source is een non-argument. Er is nog altijd een selecte groep die bepaald wat er in komt en wat niet. En Webkit is daar een geweldig voorbeeld van, want aan de standaarden houd het zich niet echt. En dat heeft de mobiele markt geen goed gedaan (ontzettend veel Webkit-only websites)...
Eugh, dat het open source is een non-argument. Er is nog altijd een selecte groep die bepaald wat er in komt en wat niet.
Dat klopt wat betreft de ontwikkeling op zich; maar wat betreft continuïteit is het wél een argument. Immers, als de ontwikkeling daadwerkelijk stagneert kan er een fork gemaakt worden - zoals ook regelmatig gebeurt (OpenOffice->LibreOffice, X11->Xorg en nu Webkit->Blink). Dat is in het geval van een closed source oplossing (Trident) niet het geval.

Het verschil tussen nu en het IE6-tijdperk is dat er destijds een dominante browser was; nu is het een dominante rendering engine maar een grotere hoeveelheid browsers, waarvan enkele overstappen op een fork. Daarom is de situatie in het verleden (IE6) dus ook niet zomaar te vergelijken met de situatie nu (WebKit).
Dit bevestigt nog meer dat op html , javascript en CSS gebaseerde applicaties een nachtmerrie is om goed te laten werken op alle courante browsers en op verschillende OS'sen. Heel veel tijd ben je kwijt aan testen als je jouw applicatie op alle courante browsers wilt laten werken en kun je alleen gebruikmaken van de de grootste gemene deler van de functionaliteit van een bepaalde browser engine. Daarom zijn plugin zoals flash en silverlight zo slecht nog niet ondanks de hype op html5. HTML5 is niet anders dan een veredelde shell scripting voor het web...
Webkit was noch optie 1 noch optie 2, omdat het door een consortium van bedrijven werd gemaakt die nadeel 1.1 in de weg zat. Nadeel 1.2 heeft denk ik niet zo veel te maken met dominantie danwel met positionering in het businessmodel.
Bij Microsoft was Internet Explorer een manier om Netscape dwars te zitten en marktaandeel te krijgen op webpagina's bekijken. Bij zowel Apple als Google is het web een essentieel onderdeel van hun bedrijfsvoering. Google vanwege apps in de Cloud, Apple vanwege HTML5 en de belangrijke positie hiervan in iOS.
Google blijft waarschijnlijk de core van wekit nog wel gebruiken, punt 2 zal dus nog wel mee valk. De reden waarom ze een fork willen gebruiken is eigenlijk heel logisch: webkit bevat teveel functies die chrome niet gebruikt / anders implementeert. Zie ook:http://www.androidpolice.com/2013/04/03/google-no-longer-cares-for-webkit-either-apparently-forking-the-engine-into-new-project-called-blink/

[Reactie gewijzigd door Cyleo op 4 april 2013 10:43]

Het lijkt wel het kiezen tussen twee kwaden [...]
Oplossing: een simpelere webtaal die altijd werkt en waar iedereen zelf zijn render engine voor kan bouwen (of een open-source library gebruiken, naar keuze van de developer, niet de user).

Met andere woorden, denk fundamenteel.

[Reactie gewijzigd door twop op 4 april 2013 10:47]

De naam Blink refereert naar het veel bekritiseerde en niet gestandaardiseerde blink-element van html die tekst kon laten knipperen.
Gelukkig is daar altijd nog CSS:
[code]<span style="text-decoration: blink;">Text to blink here</span>[/code]

offtopic:
Welke admin wil er bij mij een html blink-tag invoegen? :D
En ook die werkt niet in Chrome hoor ;-)
en de BLINK tag zou overigens bedacht zijn door dezelfde persoon die ook de Lynx browser ontwikkelde, Lou Montulli

het was oorspronkelijk een grapje over de ontwikkeling van text-gebaseerde browsers naar visuele weergave van HTML-pagina's..
Montulli had gezegd dat als men een BLINK-tag zou toevoegen, deze ook in tekst-browsers ondersteund kon worden als grafisch effect.

http://www.montulli.org/theoriginofthe%3Cblink%3Etag
Back in 1994 I was a founding engineer at Netscape, prior to that I had written the Lynx browser, which predated all of the other popular browsers at that time. Lynx had been and still is a text only browser and is commonly used in a console window on UNIX machines. At Netscape we were building software that used a graphical user interface and could express vastly more text styles and layouts as well as images and other media. We spent a lot of time thinking about the future of the web and new technologies that would enable new classes of documents, applications and uses. A few examples of those thoughts were, HTML Tables, SSL for secure communications, Plugins for extensions, and JavaScript to enable dynamic HTML.

Sometime in late summer I took a break with some of the other engineers and went to a local bar on Castro street in Mountain View. The bar was the St. James Infirmary and it had a 30 foot wonder woman statue inside among other interesting things. At some point in the evening I mentioned that it was sad that Lynx was not going to be able to display many of the HTML extensions that we were proposing, I also pointed out that the only text style that Lynx could exploit given its environment was blinking text. We had a pretty good laugh at the thought of blinking text, and talked about blinking this and that and how absurd the whole thing would be. The evening progressed pretty normally from there, with a fair amount more drinking and me meeting the girl who would later become my first wife.

Saturday morning rolled around and I headed into the office only to find what else but, blinking text. It was on the screen blinking in all its glory, and in the browser. How could this be, you might ask? It turns out that one of the engineers liked my idea so much that he left the bar sometime past midnight, returned to the office and implemented the blink tag overnight. He was still there in the morning and quite proud of it.
Ugh nog een engine. Ik hoop dat Google er ook echt voor zorgt dat het zich aan de standaarden houd.
Twijfelachtig.
Als Google de webkit specifieke code eruitsloopt die vaak gebruikt wordt op sites gebouwd voor de iphone, loopt het het risico dat mobile sites minder werken onder Android.
Als je een code cleanup doet, dan verwijder je meestal alleen de code die niet meer nodig is. Niet de code die nodig is om websites te kunnen bouwen. Sowieso, als Google alle Webkit specifieke code zou verwijderen, dan kunnen ze vanaf scratch beginnen, want een Webkit fork is logisch gezien van voor tot achter Webkit specifiek.

Wat ze volgens mij wel zullen moeten doen is alle webkit- prefixes renamen naar blink-(?) prefixes. Gezien het marktaandel van Chrome, verwacht ik wel dat website bouwers daar effort in gaan steken, zeker als het in eerste instantie niet meer is dan een veredelde zoek en vervang.

Maar zeker voor mobiele websites is dit een redelijk gewaagde stap. Maar gelukkig wel een kleinere stap dan destijds de stap van IE6 naar Firefox. Een fork zal in eerste instantie gewoon 1 op 1 werken, dus de verschillen komen geleidelijk.
Blij dat Opera zich aansluit. Het gebeurt nogal eens dat websites in opera simpelweg niet werken en ik noodgedwongen 1 van de alternatieven moet opstarten. Super irritant.

Hoe meer partijen zich afsplitsen (en dus kleiner worden) hoe meer ze gedwongen worden rekening te houden met standaarden. Grote partijen zoals we dat vroeger kenden van MS kunnen hun "standaarden" niet langer opdringen.
Inderdaad. Het werd een beetje irritant met al die Webkit elements waarbij zaken niet correct werkten op browsers die zich echt aan standaarden hielden (IE10).
Grote partijen zoals we dat vroeger kenden van MS kunnen hun "standaarden" niet langer opdringen.
Ik snap vaak niet zo goed waarom het MS kwalijk wordt genomen. Is het erg om een browser mee te leveren bij je OS (ik ken mensen die het al raar vinden dat Office er niet standaard op zit). Dat is namelijk enige wat je ze kwalijk zou kunnen nemen. In die tijd had je simpelweg geen goed alternatief. Je had netscape, ik heb het geprobeerd, maar ik vond het maar zwaar, log en traag. Toen Firefox uitkwam ben ik meteen over gestapt omdat ze functionaliteiten hadden (bijv. tabs) dat erg handig was/is.
Als het een snellere of efficiëntere engine wordt, prima. Het nadeel wordt wel dat er dan een splitsing gaat vormen tussen Webkit-engine en Blink gebruikers, waardoor webdevelopers rekening moeten gaan houden met meer browsers als er niet (voldoende) aan de standaard wordt vastgehouden.
Waardoor webdevelopers rekening moeten gaan houden met meer browsers als er niet (voldoende) aan de standaard wordt vastgehouden.
Echt heel vervelend hoor extra werk in deze tijden ;) /sarcasme
Opera lijkt wel erg aan de leiband van Google te lopen.
Wiens brood men eet, diens woord men spreekt, hè?

Goed plan van Google om te forken. Ze zijn groot genoeg om zelf een behoorlijke renderengine te beheren, zeker in samenwerking met Opera. Webkit is dan een mooi startpunt.

Voor iedereen die denkt dat het voor standaarden een probleem gaat zijn: Ik denk dat juist doordat de markt versnippert, er beter aan standaarden gehouden wordt. Met name webdevelopers zullen zich ook steeds meer (opnieuw) realiseren dat ze niet op de pixel nauwkeurig controle over de rendering hebben.
Google probeert zo veel mogelijk Apple er uit te drukken (App Store linkjes uit zoekresultaten verwijderen, etc).
Als je een beetje tussen de regels van de acties van Google doorleest, lijkt dat inderdaad het geval te zijn. Don't be evil is veranderd in try to hide being evil...

Toen Google zelf een browser wilde ontwikkelen, vonden ze het wel prettig dat er al een boel werk voor hun gedaan was en ze Webkit als basis konden nemen. Maar nu Chrome langzamerhand een serieuze speler begint te worden, vinden ze het niet meer zo leuk dat andere partijen profiteren van het werk dat ze in Webkit steken.

Google lijkt een beetje op een paard van Troje.

[Reactie gewijzigd door Luke_msx op 4 april 2013 09:20]

Toen Google zelf een browser wilde ontwikkelen, vonden ze het wel prettig dat er al een boel werk voor hun gedaan was en ze Webkit als basis konden nemen. Maar nu Chrome langzamerhand een serieuze speler begint te worden, vinden ze het niet meer zo leuk dat andere partijen profiteren van het werk dat ze in Webkit steken.
Is dat gek Google steekt al sinds ze webkit gebruiken bijna meer tijd in webkit dan de rest bij elkaar (met 10-tallen bedrijven die bijdragen is dat best wel veel meer dan de rest doet) :D

http://photos.appleinsider.com/webkit-2013.png

Je kan ze overal van beschuldigen natuurlijk, moet je lekker zelf weten, maar als ik die statistieken bekijk is het niet meer dan logisch dat ze niet de grootste bijdrager willen zijn aan een project van een ander, voor een evil bedrijf maar ook voor een niet evil bedrijf is dit niet meer dan een logische stap, om dan voor jezelf te gaan, zodat je de grootste bijdrager bent aan je eigen project.

[Reactie gewijzigd door watercoolertje op 4 april 2013 11:05]

Jalumsx heeft wel degelijk een punt. Google heeft geprofiteerd van jarenlang werk van de andere bedrijven en als ze nu iets terug doen dan vinden ze dat opeens oneerlijk.

Anyway, als het opensource blijft kunnen ze de code denk ik ook overnemen in webkit als het interessant genoeg is.
Google ontneemt inderdaad helemaal niks, dus inderdaad hoe kan je het ze nu kwalijk nemen dat ze de afgelopen 4 jaar 2x zo veel hebben bijgedragen aan Webkit dan de initiator van het hele project :)

Alles wat Google er in heeft gestoken blijft er ook in, en Webkit blijft gewoon open source want daar heeft Google niks mee te maken...

En hun eigen fork is ook weer open source dus als iemand nog van Google wil blijven profiteren kan dat ook gewoon...
Lies, damn lies and statistics.

Er staan twee indicatoren die een indruk geven van de mate van betrokkenheid. Het aantal commits en het aantal authors.
Apple en Google hebben bij de pie die het aantal commits weergeeft een even groot percentage (bijna 38%), Apple heeft zelfs een net iets hoger percentage.
Google wint het wel op het aantal authors, maar dat zegt veel minder dan het aantal commits. Beter 10 permanente ontwikkelaars dan 100 die 1 keer per maand iets committen.

Dus, jammer maar helaas. Afgaande op deze cijfers is Apple misschien wel de grotere committer. Je betoog dat Google meer dan de rest bijdraagt is dan ook zeer duidelijk niet waar.
Nee jij loopt nu de boel te verdraaien door te rekenen vanaf 2002 terwijl ik het duidelijk heb over sinds Google Webkit gebruikt in Chrome, groot verschil natuurlijk...

Die onderste 2 grafieken gaan namelijk over 2002 tot heden dus - als je zoals ik dus aangeef meet vanaf Chrome- kan je daar helemaal NIKS uit halen...

Kijk nou is naar die bovenste 2 grafieken, reken daar vanaf 2008 toen Google Webkit uitbracht en je ziet dat Google minimaal 2x zo veel bijdraagt...

Dat Apple maar marginaal (nog geen hele %) meer bijdraagt van 2002 tot eind 2012 (8 jaar dus!) dan Google in maar 4 jaar zegt toch wel genoeg wie de afgelopen 4 jaren het meeste heet bijgedragen.

Het kan zijn dat je kleurenblind bent en de kleur groen met blauw verwisseld natuurlijk, maar ga niet zeggen dat ik lieg want dat doe ik niet! Jij loopt mij nu zwart te maken omdat jij kleurenblind bent of niet goed leest wat ik net zei (dat het mij om de laatste 4 jaren ging)...

[Reactie gewijzigd door watercoolertje op 4 april 2013 16:10]

Lies, damn lies and statistics gaat over het interpreteren van statistieken op zo'n manier dat het jezelf het beste uitkomt. En dat is precies wat je doet.

Je verdedigt Google door te zeggen dat het rechtvaardig is om te forken omdat ze de grootste bijdrages leveren. Maar dan wel pas vanaf dat ze meedoen. Dat is toch precies wat ik bedoel?
Als je het hebt over de rechtvaardiging van een fork omdat ze zoveel gemaakt hebben kijk je natuurlijk naar de gehele livecycle. En daar zijn Apple en Google in evenwicht.

En tussen twee haakje, je hoeft Google helemaal niet te rechtvaardigen. Het is Open Source, ze mogen ook forken als ze 0% hebben bijgedragen.
Ik zeg niet dat het rechtvaardig is om te forken, daar heb ik helemaal niks over te zeggen en/of oordelen. Ik zeg enkel dat ik hun keuze begrijp (om webkit te forken) en DAT verdedig ik :)

Maargoed succes met de discussie, ik ben er klaar mee...

[Reactie gewijzigd door watercoolertje op 4 april 2013 16:11]

Volgens mij lees jij de grafieken niet helemaal goed, het klopt inderdaad dat het aantal commits hoger is bij Apple, echter is Apple een jaartje of 3-4 eerder begonnen. Dus effectief gezien heeft google meer authors en commits bijgedragen.

Op dit item kan niet meer gereageerd worden.



Apple iPhone 6Samsung Galaxy Note 4Apple iPad Air 2FIFA 15Motorola Nexus 6Call of Duty: Advanced WarfareApple WatchWorld of Warcraft: Warlords of Draenor, PC (Windows)Microsoft Xbox One 500GBSamsung

© 1998 - 2014 Tweakers.net B.V. Tweakers is onderdeel van De Persgroep en partner van Computable, Autotrack en Carsom.nl Hosting door True