Opera wordt Chromium-browser met Webkit-engine
Browserbouwer Opera ruilt zijn eigen render-engine Presto in voor Webkit, de engine die onder meer Apple en Google gebruiken voor hun browsers. Toekomstige versies van Opera zullen bovendien gebaseerd zijn op Chromium.
De overgang waarbij Opera op Chromium wordt gebaseerd, vindt dit jaar geleidelijk plaats, zegt Opera. Vermoedelijk zullen mobiele browsers als eerste gebruikmaken van de Webkit-engine. Enige tijd geleden kwam er informatie naar buiten over Ice, een Opera-browser voor iOS en Android, die gebruikmaakt van de Webkit-engine.
Chromium is de opensourcebrowser waarop Googles Chrome gebaseerd is. Opera zal later deze maand, op telecombeurs Mobile World Congress, zijn eerste Webkit-browser tonen. Die browser zal draaien op Android. Wanneer de desktopversie van Opera precies zal overgaan en of er versies blijven met Opera's eigen render engine Presto is onduidelijk. Opera zal actief bijdragen aan Webkit en Chromium met patches.
Dankzij de overstap hoopt Opera meer tijd en mankracht te hebben voor de implementatie van nieuwe features. Het ontwikkelen van een eigen render-engine kost veel tijd. Door de overgang van Opera naar Webkit blijven er drie 'grote' render-engines over: Webkit van Chrome, Chromium, Safari en Opera, Gecko van Firefox, en Trident van Internet Explorer. Veel mobiele browsers, van onder meer iOS, Android en BlackBerry 10, zijn ook gebaseerd op Webkit.
Opera heeft op de markt voor desktopbrowsers een marktaandeel van rond 1 procent volgens Statcounter. Op Tweakers ligt dat percentage iets hoger; in de afgelopen maand gebruikte 1,76 procent van de bezoekers een browser van Opera.
Reacties (223)
Dit is goed nieuws. Hoe minder verschillende reders, des te makkelijker voor ontwikkelaars!
En hoe groter de kans op een nieuw IE-debacle. Je ziet nu al dat er steeds meer developers webkit-only optimalisaties doorvoeren.
IE werd maar door één bedrijf onderhouden, straks wordt Webkit door meerdere bedrijven onderhouden, ik denk niet dat het een slechte stap is is.
Correctie: straks wordt webkit door nog meer bedrijven onderhouden. Maar idd, als fervent Opera-gebruiker juich ik dit toe.
Webkit word al door meerdere bedrijven onderhouden. Het is door Apple gestart, maar het lijkt me dat ook Google eraan werkt.
Webkit is niet door apple gestart. Het is een fork van KHTML, de render engine van de KDE browser Konqueror.Het is door Apple gestart, maar het lijkt me dat ook Google eraan werkt.
Jammer dat dit door mensen, alsook in dit artikel, volledig word genegeerd!
[Reactie gewijzigd door Emielvenlo op woensdag 13 februari 2013 21:29]
Het is inderdaad jammer dat er volledig aan dit feit voorbij wordt gegaan op een website als Tweakers.net. Sowieso is er niets mis met wat meer achtergrond informatie, maar dat geheel terzijde.
[Reactie gewijzigd door kevinv2u op woensdag 13 februari 2013 21:55]
Je kan KHTML zo hard omhoog prijzen als je wil, maar feit blijft dat sinds de 'fork' (zelfs de eerste WebKit was veel meer dan slechts een KHTML fork) WebKit echt heel wat meer is geworden dan wat KHTML was.
Sure, je kan de bron van WebKit wel toeschrijven aan KHTML, maar dat is dan ook dat. Het is Apple die WebKit zo gemaakt heeft als het nu is, waarbij Google sinds WebKit opensource en op zichzelf gegaan is ook aan het bijdragen is.
Maakt dit KDE, Apple of Google de WebKit baas? Nee, maar behalve KDE en Apple is er niemand te bedanken voor de kwaliteit van WebKit. Google heeft geowoon toen WebKit mature genoeg was 'ook even een browser gemaakt'. En nu schrijft iedereen Google Chrome als de grote WebKit baas, terwijl het toch echt Apple was die er wat van gemaakt heeft, met KHTML als bron. Zonder KTHML had Apple wel een andere engine gevonden, of gewoon zelf een gemaakt... maar dat deden ze niet, ze hebben KHTML gepakt, en dat zegt wel wat over de kwaliteit van KHTML.
Stel dat WebKit genoemd wordt, en daarna een browser als voorbeeld genoemd moet worden, dan is Safari toch wel het 1e voorbeeld, dat is gewoon de definitie van WebKit! Daarna zou je Chromium en dan misschien nog Chrome kunnen noemen, maar dat constante gedoe alsof WebKit van Google is.. bah. Het was van Apple, en nu is het van zichzelf. The end.
Sure, je kan de bron van WebKit wel toeschrijven aan KHTML, maar dat is dan ook dat. Het is Apple die WebKit zo gemaakt heeft als het nu is, waarbij Google sinds WebKit opensource en op zichzelf gegaan is ook aan het bijdragen is.
Maakt dit KDE, Apple of Google de WebKit baas? Nee, maar behalve KDE en Apple is er niemand te bedanken voor de kwaliteit van WebKit. Google heeft geowoon toen WebKit mature genoeg was 'ook even een browser gemaakt'. En nu schrijft iedereen Google Chrome als de grote WebKit baas, terwijl het toch echt Apple was die er wat van gemaakt heeft, met KHTML als bron. Zonder KTHML had Apple wel een andere engine gevonden, of gewoon zelf een gemaakt... maar dat deden ze niet, ze hebben KHTML gepakt, en dat zegt wel wat over de kwaliteit van KHTML.
Stel dat WebKit genoemd wordt, en daarna een browser als voorbeeld genoemd moet worden, dan is Safari toch wel het 1e voorbeeld, dat is gewoon de definitie van WebKit! Daarna zou je Chromium en dan misschien nog Chrome kunnen noemen, maar dat constante gedoe alsof WebKit van Google is.. bah. Het was van Apple, en nu is het van zichzelf. The end.
Hopelijk gaat IE ook nog eens over op webkit!
Als ze niet volledig overgaan op webkit hoop ik dat ze een directive introduceren om toch webkit te kunnen gebruiken. Iets in de trant van "<meta renderer=webkit />" ofzo.
Dat zou een ware zegen zijn voor developers.
Als ze niet volledig overgaan op webkit hoop ik dat ze een directive introduceren om toch webkit te kunnen gebruiken. Iets in de trant van "<meta renderer=webkit />" ofzo.
Dat zou een ware zegen zijn voor developers.
Dat zou een zeer slechte ontwikkeling zijn: iedereen dezelfde browser iedereen dezelfde bugs en dus iedereen dezelfde exploits.... Eigenlijk hetzelfde als de IE6 tijd dus. Fijn dat je dat iedereen toewenst.
Nee, dat is gewoon niet waar. Het zou heerlijk zijn; met zoveel bedrijven die er geld in steken zullen bugs en exploits snel worden gefixt. En het is niet zo dat Trident geen exploits en bugs heeft.
Waarom zouden ze dan bugs snel fixen? Het is een leuk idee dat ze dan allemaal gezellig samenwerken en het daardoor sneller gefixed wordt, maar zo werkt het meestal toch niet.
Het probleen van IE6 was dan ook niet dat ze het niet konden fixen, dat is duidelijk dat het kon, maar dat ze bijzonder weinig reden hadden om het te fixen en standaarden te volgen. Je zal exact hetzelfde probleem hebben als webkit zwaar dominant wordt. Waarom zouden ze moeilijk doen met standaarden, ze zijn dan de standaard.
Ik zie dan ook geen enkele reden om aan te nemen dat er meer geld in webkit gestoken zal worden als die dominant is dan dat er in IE6 werd gestoken. Dat is juist des te meer het geval als meerdere bedrijven eraan werken, leuke illusie dat ze dan allemaal hard eraan werken, veel geld erin steken en snel bugs fixen, maar nogmaals, waarom zouden ze dat doen? Het is voor je bedrijf veel handiger als je zo min mogelijk eraan doet. Al je concurenten hebben ook last van diezelfde bug, dus dat maakt jou niks uit, en beter nog, uiteindelijk lost een concurent het ook wel op, laat die dus maar lekker ervoor betalen.
Nee meerdere render engines die allemaal wel redelijk netjes standaarden volgen en elkaar beconcureren is een veel beter idee.
Het probleen van IE6 was dan ook niet dat ze het niet konden fixen, dat is duidelijk dat het kon, maar dat ze bijzonder weinig reden hadden om het te fixen en standaarden te volgen. Je zal exact hetzelfde probleem hebben als webkit zwaar dominant wordt. Waarom zouden ze moeilijk doen met standaarden, ze zijn dan de standaard.
Ik zie dan ook geen enkele reden om aan te nemen dat er meer geld in webkit gestoken zal worden als die dominant is dan dat er in IE6 werd gestoken. Dat is juist des te meer het geval als meerdere bedrijven eraan werken, leuke illusie dat ze dan allemaal hard eraan werken, veel geld erin steken en snel bugs fixen, maar nogmaals, waarom zouden ze dat doen? Het is voor je bedrijf veel handiger als je zo min mogelijk eraan doet. Al je concurenten hebben ook last van diezelfde bug, dus dat maakt jou niks uit, en beter nog, uiteindelijk lost een concurent het ook wel op, laat die dus maar lekker ervoor betalen.
Nee meerdere render engines die allemaal wel redelijk netjes standaarden volgen en elkaar beconcureren is een veel beter idee.
Dat vind ik nogal een gedurfde uitspraak om het zo neer te zetten alsof het de enige juiste mogelijkheid is
Het ligt puur aan de bedrijven zelf of dit goed of slecht zal zijn
Als je kijkt naar Google en Opera hebben zei enorm veel belang bij een goed functionerende render engine. Vooral Google omdat die toch veel meer in de browser willen doen dan nu het geval is
Die zullen dus wel hoge prioriteit geven aan bugs ed aangezien dit 1 van de belangrijke producten is van Google
Het ligt puur aan de bedrijven zelf of dit goed of slecht zal zijn
Als je kijkt naar Google en Opera hebben zei enorm veel belang bij een goed functionerende render engine. Vooral Google omdat die toch veel meer in de browser willen doen dan nu het geval is
Die zullen dus wel hoge prioriteit geven aan bugs ed aangezien dit 1 van de belangrijke producten is van Google
[Reactie gewijzigd door Mellow Jack op woensdag 13 februari 2013 13:01]
Het probleem van IE6 is dat Microsoft een monopolie-positie had. Webkit is nu wel behoorlijk groot, maar IE en FF hebben nog wel een veel groter marktaandeel dan Netscape destijds, en ik hoop en verwacht dat ze dat nog wel houden. En zolang IE en Firefox goede vervangers zijn voor webkit, zullen ze zich niet kunnen veroorloven om achter te blijven.
Het grootste probleem is dat er nu webkit-only wordt ontwikkeld, mede dankzij de -webkit-prefix. Maar dat is vooral een probleem voor developers: 45 tot 75% is nu IE en Firefox (bron: https://en.wikipedia.org/...eb_browsers#Summary_table). Webkit-only websites zijn leuk als proefballonnetjes en testprojectjes, maar geen enkele professionele webdeveloper zal de helft van zijn potentiele bereik uitsluiten.
Het grootste probleem is dat er nu webkit-only wordt ontwikkeld, mede dankzij de -webkit-prefix. Maar dat is vooral een probleem voor developers: 45 tot 75% is nu IE en Firefox (bron: https://en.wikipedia.org/...eb_browsers#Summary_table). Webkit-only websites zijn leuk als proefballonnetjes en testprojectjes, maar geen enkele professionele webdeveloper zal de helft van zijn potentiele bereik uitsluiten.
Dit probleem is er momenteel al wel op het mobiele gebied. Daar is de overgrote meerderheid webkit, op enkele nokia's en mensen die zelf opera installeren na.
Hier gebeurt het al regelmatig dat alleen voor webkit gebouwd wordt, gebruikers van andere platformen kunnen dan in de feces zakken. Inderdaad praktijken uit het IE6 tijdperk.
Hier gebeurt het al regelmatig dat alleen voor webkit gebouwd wordt, gebruikers van andere platformen kunnen dan in de feces zakken. Inderdaad praktijken uit het IE6 tijdperk.
Nokia gebruikt in S40 ook Webkit.
Hij doelt op Windows Phone.
Je vergeet zomaar even de mobiele markt voor het gemak zeker?
Hangt van af, het kan zijn dat je mee kan doen als je aan bepaalde voorwaarden voldoet. Stel je doet helemaal niks aan bugfixes, dan kunnen ze op een gegeven moment ook besluiten om een feature van jou niet op te nemen, want je helpt ook niet mee met bugfixes.
Kijk maar naar Linux, daar werken ook verschillende grote bedrijven aan mee, maar er zijn afspraken waar je aan dient te houden om het project te beschermen.
Kijk maar naar Linux, daar werken ook verschillende grote bedrijven aan mee, maar er zijn afspraken waar je aan dient te houden om het project te beschermen.
Met als verschil dat er dan dus verschillende bedrijven/instanties zijn die zullen bijdragen aan de ontwikkeling van WebKit. :-) Als dat goed blijft gaan en ze krijgen geen ruzie waarop een fork volgt zal dat alleen maar bijdragen aan de ontwikkeling.
Het gaat nu al niet meer goed, als het even kan, volgt Webkit de standaard niet.
Voorbeelden?Het gaat nu al niet meer goed, als het even kan, volgt Webkit de standaard niet.
Of heb je het nu over de experimentele (prefixed) features, die nodig te zijn om webontwikkelaars de mogelijkheid te geven nieuwe standaarden die nog in ontwikkeling zijn zelf te kunnen testen en feedback aan de W3C te kunnen leveren? Want dat laatste lijkt me niet echt een slechte zaak, en zelfs nodig als je wilt dat we straks niet met allemaal slecht uitgedachte standaarden komen te zitten.
Ik vind het ook geen goede zaak dat veel ontwikkelaars doen alsof prefixed standaarden gewoon zonder fallback gebruikt kunnen worden, maar dat is toch echt een probleem wat door die ontwikkelaars zelf veroorzaakt wordt - veel dingen die nu in ontwikkeling zijn moeten gewoon daadwerkelijk gebruikt kunnen worden door ontwikkelaars om te kijken of sommige APIs handig werken en niet makkelijker gemaakt kunnen worden etc. Het gebeurt toch zo nu en dan dat een experimentele HTML5 standaard geschrapt/aangepast word omdat het in de praktijk niet lekker bleek te werken
Onderandere, want gradients worden nog steeds niet ondersteund zoals het hoord. Ik denk ook aan touch, waar zij ook hun eigen systeem gebruiken terwijl de overgrote meerderheid voorstander is van Microsofts versie. En ga zo maar door...
Als je dat zo graag wil, dan verplicht je toch al je IE gebruikers om Chrome Frame te installeren? 
Ja, lekker gebruiksvriendelijk. "Dag, welkom in ons huis. Ik zie dat u een groene broek aan heeft. Ons systeem kan dat niet aan, we zijn te lui om daar iets voor te bouwen. U moet even hier om de hoek een andere broek halen. Dag!"
Mijn inziens net iets gebruiksvriendelijker dan helemaal geen upgrade mogelijkheid aan te bieden aan gebruikers van XP/IE.
XP is ondertussen meer dan 10 jaar geleden uitgebracht en we zitten al 3 versies verder van Windows. Jammer voor hen die het per se willen blijven gebruiken, maar er wordt nu eenmaal vooruitgang gemaakt in de rest van de wereld en soms kan je niet anders dan meegaan. Er is tijd genoeg geweest om de overstap te maken, ondersteuning heeft lang genoeg geduurd en het is helemaal niet onredelijk dat deze nu gewoon stopt.
Als webkit nou gewoon alle webstandaarden gaat volgen op dit moment, is er helemaal geen reden om over te moeten stappen. Maar nee, webkit moet weer een heleboel eigen functies toevoegen en daarbij meteen de -webkit- prefix gebruiken om ervoor te zorgen dat er ook geen enkele andere browserfabrikant gebruik van kan maken. Voor developers zijn de veranderingen aan webkit juist heel onoverzichtelijk aan het worden, waardoor je nu al niet meer weet of bepaalde functies nou wel of niet ondersteund worden.
Het gebruik van prefixes is juist goed om te zorgen dat de browsers allemaal een kans hebben om een standaard te maken, ipv de eerste die met een idee komt.
Is dit serieus ? Browsers moeten helemaal geen eigen standaard maken, zij moeten zich aan de standaarden houden die hogere organisaties bedenken. Wat jij zegt is precies wat er nu gebeurd en waardoor het een mengelmoes is van prefixes per browser.Het gebruik van prefixes is juist goed om te zorgen dat de browsers allemaal een kans hebben om een standaard te maken, ipv de eerste die met een idee komt.
De standaardenorganisaties schieten niet op. Kijk maar hoelang HTML5 heeft bedoeld. Daarom innoveert Google Chrome bijvoorbeeld door. Als we zouden wachten totdat de standaard formeel klaar is hadden we nu nog amper functionaliteit.
het grappige is dat MS net hetzelfde deed met IE5 en IE6 (eigen dingen toevoegen) en toen was MS opeens pure evil...
standaarden gaan traag omdat er over nagedacht wordt
niemand (ik toch niet) zit te wachten op allerhande functies die overlappen, nutteloos zijn,... het maakt de engine ook nodeloos trager, logger en moeilijker om te onderhouden
standaarden gaan traag omdat er over nagedacht wordt
niemand (ik toch niet) zit te wachten op allerhande functies die overlappen, nutteloos zijn,... het maakt de engine ook nodeloos trager, logger en moeilijker om te onderhouden
MS deed het niet met prefixes, maar gebruikte de standaard-namen met een eigen implementatie. Doordat ze de grootste partij in de browsermarkt waren, werd daardoor de officiele standaard teniet gedaan. Dat is evil ja.
Browser prefixes zijn er JUIST voor gemaakt om experimentele features te implementeren. Als jij als developer er vanuit gaat dat deze prefixes altijd blijven werken, zit de fout bij jou, niet bij de browsermaker.
Browser prefixes zijn er JUIST voor gemaakt om experimentele features te implementeren. Als jij als developer er vanuit gaat dat deze prefixes altijd blijven werken, zit de fout bij jou, niet bij de browsermaker.
Prefix of niet, het heeft dezelfde slechte invloed op het internet, dus ja, ook Webkit is hier evil.
Ja precies, vooruitziend als ik ben gebruik ik nu alvast, naast de bestaande -o, -moz, -webkit, -ms, ook de -tba prefix (to be announced) [/sarcasm]
Aan de ene kant jammer die verschraling van engines, aan de andere kant, als ze toch bijna allemaal van de standaarden afwijken, schiet je er eigenlijk ook niets mee op met al die engines. Ikzelf vond Opera trouwens wel fijn om ertussen te hebben.
Ik heb net weer zo'n responsive html5 (video/touch) project achter de rug, en eerlijk gezegd werd ik er niet vrolijk van. De theorie klinkt leuk, maar de praktijk blijkt telkens weer geknoei, dirty gefix, om uiteindelijk iets meer dan alleen maar iets stricts neer te zetten, maar iets wat gewoonweg wérkt.
Aan de ene kant jammer die verschraling van engines, aan de andere kant, als ze toch bijna allemaal van de standaarden afwijken, schiet je er eigenlijk ook niets mee op met al die engines. Ikzelf vond Opera trouwens wel fijn om ertussen te hebben.
Ik heb net weer zo'n responsive html5 (video/touch) project achter de rug, en eerlijk gezegd werd ik er niet vrolijk van. De theorie klinkt leuk, maar de praktijk blijkt telkens weer geknoei, dirty gefix, om uiteindelijk iets meer dan alleen maar iets stricts neer te zetten, maar iets wat gewoonweg wérkt.
Dat is juist een afspraak tussen de W3C en de browserbouwers....en daarbij meteen de -webkit- prefix gebruiken om ervoor te zorgen...
Van elke standaard met een 'Release candidate' status wordt de implementatie in de browser gestimuleerd door de W3C om het in de praktijk te testen op tekortkomingen.
Door per engine een prefix te gebruiken kan je als ontwikkelaar zorgen dat de verschillende implementaties elkaar niet bijten.
En als de definitieve standaard vast komt te liggen dan kan je de definitieve standaard met een 'zoek en vervang' implementeren.
Je klaagt dus eigenlijk dat Webkit voorop loopt met de implementatie van release candidate standaarden.
Het is meer dat webkit uiteindeliijk ondersteuning laat bestaan voor die prefixed features ook als ze eenmaal de officiele standaard ondersteunen die dan vaak anders werkt.
Ze zouden of de ondersteuning voor de prefixed versies moeten laten vallen als ze de officiele versie van een feature ondersteunen ofwel de prefixed versie ook conform die standaard moeten laten werken.
Doordat de webkit code dat niet doet en de afwijkende werking voor prefixed code laat bestaan krijg je een soort eeuwige beta code die blijft hangen waardoor er steeds meer afwijkende pagina's onstaan.
Je krijgt een soort nieuwe quirksmode.
Ze zouden of de ondersteuning voor de prefixed versies moeten laten vallen als ze de officiele versie van een feature ondersteunen ofwel de prefixed versie ook conform die standaard moeten laten werken.
Doordat de webkit code dat niet doet en de afwijkende werking voor prefixed code laat bestaan krijg je een soort eeuwige beta code die blijft hangen waardoor er steeds meer afwijkende pagina's onstaan.
Je krijgt een soort nieuwe quirksmode.
Want backward compatibility is niet nodig? Als sites gebruik maken van "-webkit-"-varianten, zou het lullig zijn als dat na een tijdje opeens niet meer werkt. Dan moeten bedrijven weer kosten maken omdat het in nieuwe versies niet werkt.
Daarnaast weet ik niet of het wel "beta code" blijft, het zal me niets verbazen als het gewoon dezelfde achterliggende code gebruikt als de niet-"-webkit-"-variant.
Daarnaast weet ik niet of het wel "beta code" blijft, het zal me niets verbazen als het gewoon dezelfde achterliggende code gebruikt als de niet-"-webkit-"-variant.
Developers kunnen zich natuurlijk ook gewoon realiseren dat er een reden is dat die prefix gebruikt wordt; de standaard is nog niet af en niet bedoeld voor productiesites. Als je het wel doet moet je niet gaan huilen dat het na een jaar niet meer ondersteund wordt: dat was de afspraak.Want backward compatibility is niet nodig? Als sites gebruik maken van "-webkit-"-varianten, zou het lullig zijn als dat na een tijdje opeens niet meer werkt. Dan moeten bedrijven weer kosten maken omdat het in nieuwe versies niet werkt.
Daarnaast weet ik niet of het wel "beta code" blijft, het zal me niets verbazen als het gewoon dezelfde achterliggende code gebruikt als de niet-"-webkit-"-variant.
[Reactie gewijzigd door gerrymeistah op woensdag 13 februari 2013 13:45]
Klopt helemaal
Wij gebruiken deze features ook, maar beseffen heel goed dat het nog experimenteel is en dat het risico bestaat dat we het moeten aanpassen
Al voegen we wel altijd ook de variant zonder prefix toe
Wij gebruiken deze features ook, maar beseffen heel goed dat het nog experimenteel is en dat het risico bestaat dat we het moeten aanpassen
Al voegen we wel altijd ook de variant zonder prefix toe
Of die bedrijven moeten geen expirementele features gebruiken die nog niet definitief zijn en daarmee wachten totdat ze dat wel zijn?
Dat nu gebeurt dus ook.
Neem bijvoorbeeld de box-shadow property.
Als jij zowel -webkit-box-shadow als box-shadow declaraties hebt, dan negeert webkit tegenwoordig de eerste ten gunste van de non-prefix declaratie.
Neem bijvoorbeeld de box-shadow property.
Als jij zowel -webkit-box-shadow als box-shadow declaraties hebt, dan negeert webkit tegenwoordig de eerste ten gunste van de non-prefix declaratie.
Webkit is deze prefixes gaan gebruiken omdat ze niet wilden wachten totdat de standaard eindelijk eens definitief was.
Veel van de standaarden zijn aangedragen vanuit webkit, maar omdat daar 5 jaar over gediscussieerd moet worden hebben Apple en Google besloten om door te gaan met ontwikkelen en dit met een prefix te doen.
Het is niet helemaal terecht om de schuld bij WebKit te leggen.
Veel van de standaarden zijn aangedragen vanuit webkit, maar omdat daar 5 jaar over gediscussieerd moet worden hebben Apple en Google besloten om door te gaan met ontwikkelen en dit met een prefix te doen.
Het is niet helemaal terecht om de schuld bij WebKit te leggen.
"Hopelijk gaat IE ook nog eens over op webkit!"
Liefst niet. IE krijgt slechts 1x per jaar een nieuwe versie. Ik kan me nu al voorstellen dat je een jaar lang met een verouderde versie van de webkit zou moeten gaan werken. En dat is ook niet echt waar iedereen op zit te wachten.
Bovendien is concurrentie altijd gezond
Liefst niet. IE krijgt slechts 1x per jaar een nieuwe versie. Ik kan me nu al voorstellen dat je een jaar lang met een verouderde versie van de webkit zou moeten gaan werken. En dat is ook niet echt waar iedereen op zit te wachten.
Bovendien is concurrentie altijd gezond
[Reactie gewijzigd door sirnh1 op woensdag 13 februari 2013 12:37]
Voor luie developers ja. Maar voor developers in het algemeen juist niet, bij minder browsers en minder uitzonderingen heb je ook minder webdevelopers nodig.Dat zou een ware zegen zijn voor developers.
Nou dat is leuk en motiverend werk! Allemaal vage uitzonderingsafhandelingen schrijven voor crappy browers.
Dat zal denk ik ook wel meevallen, de meeste developers gebruiken toch frameworks, het enige resultaat zou dan moeten zijn dat die frameworks kunnen afslanken dankzij minder uitzonderingen. En dat zou denk ik de kwaliteit van de code en de onderhoudbaarheid wel ten goede komen.
Als er een groep mensen is die daardoor minder werk krijgen dan zouden dat testers moeten zijn lijkt me...
Als er een groep mensen is die daardoor minder werk krijgen dan zouden dat testers moeten zijn lijkt me...
Het grote IE probleem wordt niet altijd goed begrepen in web dev land. Het probleem is namelijk niet de rendering engine (die van IE10 is bijvoorbeeld erg goed), het probleem is dat oude IE versie maar niet willen uitsterven.
IE6 - 10 waren allemaal goed op het moment dat ze uitkwamen, het punt is alleen dat ze op een gegeven moment sterk verouderd zijn maar in het wild niet verdwijnen. Zelfs als IE11 een webkit engine zou krijgen, zouden we nog heel veel jaren IE8-10 moeten ondersteunen.
Kortom, het IE probleem is geen rendering engine probleem, het is een update probleem.
IE6 - 10 waren allemaal goed op het moment dat ze uitkwamen, het punt is alleen dat ze op een gegeven moment sterk verouderd zijn maar in het wild niet verdwijnen. Zelfs als IE11 een webkit engine zou krijgen, zouden we nog heel veel jaren IE8-10 moeten ondersteunen.
Kortom, het IE probleem is geen rendering engine probleem, het is een update probleem.
Er is nu eenmaal een verschil tussen wat HTML ooit had moeten zijn en wat het is geworden. Het was een meer beschrijvende taal: dit is een kop, dit een alinea, dit is een link en hier ergens komt een plaatje: zie maar hoe je het weergeeft. Het voordeel daaraan is dat je niet om een bepaalde schermresolutie of zelfs scherm hoeft te vragen. Ook voor blinden kan een site dan heel toegankelijk worden gemaakt.
Geheel tegen alle verwachtingen in wilden mensen niet alleen functionele websites maar ook mooie websites. Developers gebruikten frames en tables en andere elementen die bedoeld zijn om data gestructureerd weer te geven, om een website er op een gewenste manier uit te laten zien. Uiteindelijk is daar met HTML5 rekening mee gehouden, maar de oorspronkelijke keuzevrijheid van een HTML-engine is hiermee verdwenen: webdevelopers willen een website pixelperfect kunnen maken. Dat betekent dat ofwel iedere render-engine precies hetzelfde moet doen (waarom dan niet maar 1 engine hebben), of iedere website moet voor alle gebruikte render-engines worden aangepast.
Geheel tegen alle verwachtingen in wilden mensen niet alleen functionele websites maar ook mooie websites. Developers gebruikten frames en tables en andere elementen die bedoeld zijn om data gestructureerd weer te geven, om een website er op een gewenste manier uit te laten zien. Uiteindelijk is daar met HTML5 rekening mee gehouden, maar de oorspronkelijke keuzevrijheid van een HTML-engine is hiermee verdwenen: webdevelopers willen een website pixelperfect kunnen maken. Dat betekent dat ofwel iedere render-engine precies hetzelfde moet doen (waarom dan niet maar 1 engine hebben), of iedere website moet voor alle gebruikte render-engines worden aangepast.
edit:
@latka: Webdevelopers willen misschien helemaal geen website hebben, dat willen hun klanten.
@mcDavid: Als de specificaties zo strikt moeten zijn dat websites pixel voor pixel hetzelfde zijn in elke browser die de specificatie volgt, dan hebben we mijn eerste optie: iedere render-engine doet exact hetzelfde. De manier waarop, de snelheid waarmee en het platform waar onder kan dan natuurlijk wel verschillen.
@latka: Webdevelopers willen misschien helemaal geen website hebben, dat willen hun klanten.
@mcDavid: Als de specificaties zo strikt moeten zijn dat websites pixel voor pixel hetzelfde zijn in elke browser die de specificatie volgt, dan hebben we mijn eerste optie: iedere render-engine doet exact hetzelfde. De manier waarop, de snelheid waarmee en het platform waar onder kan dan natuurlijk wel verschillen.
[Reactie gewijzigd door 84hannes op woensdag 13 februari 2013 15:20]
Kleine correctie: " developers willen een website pixelperfect kunnen maken" dat willen klanten/marketing/management. De meeste ontwikkelaars die ik ken vinden een zwart/wit website al goed genoeg.
Ik kan me niet voorstellen dat er web developers zijn die jouw mening delen over zwart/wit websites.
Maar inderdaad, het zijn andere afdelingen die eerder gericht zijn op pixelperfect maken van een website.
Maar inderdaad, het zijn andere afdelingen die eerder gericht zijn op pixelperfect maken van een website.
ik ben zelf web developer, en vermoed dat jij dan toch echt niet de juiste web developers ben tegengekomen...
Of optie 3: render-engines houden zich aan de geldende specificaties zodat developers makkelijk volgens die specificatie kunnen ontwikkelen, en er toch gezonde concurrentie blijft op de browsermarkt.
Kun je mij uitleggen waarom verschillende renderengines bijdragen aan gezonde concurrentie tussen browsers?
Dat een gebruiker de features van Firefox boven Chrome prefereert kan ik goed begrijpen. Maar een voorkeur voor Gecko boven Webkit of andersom begrijp ik niet (als gebruiker, niet als developer). Niemand - niet gebruikers, webdevelopers of browserontwikkelaars - heeft er *echt* belang bij dat er verschillende renderengines zijn: dat is historisch alleen zo gegroeid.
Mozilla heeft al zijn technologie rond XUL en daarmee Gecko gebouwd, en Microsoft heeft Internet Explorer verwoven met Windows. Als dit niet het geval was geweest waren ook zij waarschijnlijk overgestapt naar Webkit of hadden dat in ieder geval overwogen.
Dat een gebruiker de features van Firefox boven Chrome prefereert kan ik goed begrijpen. Maar een voorkeur voor Gecko boven Webkit of andersom begrijp ik niet (als gebruiker, niet als developer). Niemand - niet gebruikers, webdevelopers of browserontwikkelaars - heeft er *echt* belang bij dat er verschillende renderengines zijn: dat is historisch alleen zo gegroeid.
Mozilla heeft al zijn technologie rond XUL en daarmee Gecko gebouwd, en Microsoft heeft Internet Explorer verwoven met Windows. Als dit niet het geval was geweest waren ook zij waarschijnlijk overgestapt naar Webkit of hadden dat in ieder geval overwogen.
Als het toch zo onbelangrijk is ga ik even iedereen terug op IE6 zetten.
Dit maakt wel degelijk uit. Webkit is dominant als mobiele render engine, en dat is ENORM slecht.
Dit maakt wel degelijk uit. Webkit is dominant als mobiele render engine, en dat is ENORM slecht.
Je vergelijking is zo krom als een banaan. Het gaat er als gebruiker niet om welke render-engine er gebruikt word maar dat het gewoon weergegeven word zoals het bedoelt is. En dat betekent niet dat een niet gepatchte engine goed genoeg is, het geeft alleen aan dat een up-to-date enigine goed genoeg is.
Omdat als er maar één render engine is, er geen enkele drive meer is om bugs eruit te halen en te innoveren, gezien dat dat geen enkel voordeel voor een bedrijf oplevert.
Nu als bijvoorbeeld alle engines behalve webkit bewegende gifjes kunnen laten zien, enkel webkit niet, dan kan ik je verzekeren dat dat bijzonder snel erin gegooid wordt, anders hebben immers de browsers die webkit gebruiken een flink probleem. Zonder concurentie hebben ze geen reden om dat te implementeren, het is niet alsof de consument kan overstappen naar een browser die het wel aankan. En als er een bug in zit dan maakt het je niks uit als browsermaker als er nog maar één renderengine is, immers de concurentie heeft er net zoveel last van, laat het hun maar lekker oplossen.
Nu als bijvoorbeeld alle engines behalve webkit bewegende gifjes kunnen laten zien, enkel webkit niet, dan kan ik je verzekeren dat dat bijzonder snel erin gegooid wordt, anders hebben immers de browsers die webkit gebruiken een flink probleem. Zonder concurentie hebben ze geen reden om dat te implementeren, het is niet alsof de consument kan overstappen naar een browser die het wel aankan. En als er een bug in zit dan maakt het je niks uit als browsermaker als er nog maar één renderengine is, immers de concurentie heeft er net zoveel last van, laat het hun maar lekker oplossen.
De drive om een renderengine te verbeteren zou moeten zijn om een beter web te maken. Dit is de primaire motivatie van Google om aan Webkit te werken (en het uberhaupt in eerste instantie te kiezen) en die van Mozilla. Het gaat hen niet primair om de prestige van de beste renderingengine maar om het maken van een sneller en featurerijker web. In het geval van Mozilla gaat het om idealen die ze nastreven, en Google om meer geld te verdienen met een betere ervaring in webapplicaties.
Hoewel Microsoft en Apple de concurrentiestrijd misschien wat sterker voelen, is het niet alsof het verbeteren van een renderengine primair wordt gemotiveerd door concurrentiespelletjes. Met die redenatie zou ook niemand gemotiveerd moeten zijn om aan de Linux-kernel te werken. Die heeft, genomen over het gehele toepassingsgebied van de Linux-kernel, ook geen significante concurrentie. Het is hierbij van belang dat het product open source is, en dat zijn Webkit en Gecko.
Als Webkit (of Gecko, of een open source Trident of Presto) gekozen zou worden als dé referentie-implementatie van het W3C, zouden de verbeteringen erin aangebracht met dezelfde motivatie als het W3C nog bezig is een nieuwe HTML-standaard te ontwikkelen: het verbeteren van het web.
Dat gaat niet gebeuren. Maar als het wel zou gebeuren, zou het veel minder moeite kosten om standaarden te definiëren, zouden browserontwikkelaars geen dubbel werk meer hoeven doen, zouden webdevelopers veel tijdwinst kunnen hebben, en zouden gebruikers beter gedragende webapps hebben. Los van de legacy-perikelen die dit op zou leveren voor met name Microsoft is dat een absolute win-win-situatie mijns inziens.
Hoewel Microsoft en Apple de concurrentiestrijd misschien wat sterker voelen, is het niet alsof het verbeteren van een renderengine primair wordt gemotiveerd door concurrentiespelletjes. Met die redenatie zou ook niemand gemotiveerd moeten zijn om aan de Linux-kernel te werken. Die heeft, genomen over het gehele toepassingsgebied van de Linux-kernel, ook geen significante concurrentie. Het is hierbij van belang dat het product open source is, en dat zijn Webkit en Gecko.
Als Webkit (of Gecko, of een open source Trident of Presto) gekozen zou worden als dé referentie-implementatie van het W3C, zouden de verbeteringen erin aangebracht met dezelfde motivatie als het W3C nog bezig is een nieuwe HTML-standaard te ontwikkelen: het verbeteren van het web.
Dat gaat niet gebeuren. Maar als het wel zou gebeuren, zou het veel minder moeite kosten om standaarden te definiëren, zouden browserontwikkelaars geen dubbel werk meer hoeven doen, zouden webdevelopers veel tijdwinst kunnen hebben, en zouden gebruikers beter gedragende webapps hebben. Los van de legacy-perikelen die dit op zou leveren voor met name Microsoft is dat een absolute win-win-situatie mijns inziens.
[Reactie gewijzigd door DCK op woensdag 13 februari 2013 15:10]
Natuurlijk wel, de grote reden dat grote commerciele spelers als Oracle, IBM, Novell, Google etc allemaal aan Linux zijn gaan werken is om gezamenlijk meer concurrentie voor Microsoft te kunnen bieden, want in hun eentje is het een vrij lastige taak.Met die redenatie zou ook niemand gemotiveerd moeten zijn om aan de Linux-kernel te werken.
[Reactie gewijzigd door Dreamvoid op woensdag 13 februari 2013 19:10]
Het probleem speelt zich vooral in de CSS implementatie. Het gaat dus niet om features of platform-verwevenheid.Kun je mij uitleggen waarom verschillende renderengines bijdragen aan gezonde concurrentie tussen browsers?
Maar de vice voorzitter van het W3C kan het misschien beter voor je uitleggen waarom de dominantie van Webkit de open standaarden van het web bedreigt:
http://www.glazman.org/we...HE-OPEN-WEB-NEEDS-YOU-NOW
Inderdaad, verschillende renderengines zijn problematisch als er één standaard wordt nagestreefd. Daarom zou het beter zijn als er maar één renderengine zou zijn waar rekening mee wordt gehouden.
Je vergeet de [sarcasme] tag.
Als eindgebruiker wil ik de best mogelijke ervaring als ik aan het surfen ben.Kun je mij uitleggen waarom verschillende renderengines bijdragen aan gezonde concurrentie tussen browsers?
Idealiter wil ik eigenlijk alle websites binnen de milliseconde op mijn scherm zien staan en 5000 browservensters kunnen openen zonder dat mijn laptop / tablet / smartphone traag wordt.
Browserbouwers kunnen hier met elkaar concurreren door steeds betere renderengines op de markt te brengen. Mensen zullen heus niet verlopen elke keer een nieuwe browser 'de snelste' is. Maar als hun browser ter plaatse blijft trappelen terwijl anderen altijd maar 'sneller' worden, dan zullen ze toch wel overschakelen.
Een 'gezonde concurrentie' hebben we trouwens al gezien de laatste jaren tussen de verschillende JavaScript-engines (wikipedia)
Het is zelfs zo dat het parsen van websites, inclusief alles wat daarin mis kan gaan, gestandardiseerd is in HTML. Dat betekent dat bij een correct implementatie, het verschil tussen rendering engines nog kleiner is geworden (wat goed is). Dus inderdaad, het voordeel van verschillende engines wordt echt steeds kleiner.
Je vergeet 1 belangrijke optie: iedere website stuurd zijn eigen render/scripting engine mee met de HTML. Dit lijkt misschien een enorme overhead en security risk te impliceren maar als je dit goed implementeerd met caching en sandboxing (*) dan kan dit een enorm gemak voor de developer betekenen, en tevens een enorm flexibiliteit geven.Dat betekent dat ofwel iedere render-engine precies hetzelfde moet doen (waarom dan niet maar 1 engine hebben), of iedere website moet voor alle gebruikte render-engines worden aangepast.
Dan kun je dus ook ineens bijvoorbeeld python, perl of zelfs scheme of haskell in een webpagina gebruiken. Of zelfs C++. En wat render engines betreft zal er dan uiteindelijk ook een verscheidenheid aan keuzes ontstaan (veel daarvan open-source). Dat lijkt mij een gezondere situatie...
PS: ja ik weet dat je met "emscripten" ook andere talen naar javascript kunt compileren, maar dat is performancetechnisch natuurlijk maar een B-oplossing.
(*) lijkt mij, ik heb hier eerlijk gezegt niet veel verstand van.
[Reactie gewijzigd door twop op woensdag 13 februari 2013 11:25]
Zullen Google en andere webcrawlers leuk vinden... Je genereert een *enorme* overhead aan verkeer, ook inclusief caching en weet ik wat. Een rendering engine is geen klein / triviaal stukje software. Bovendien loop je dan ook al tegen platform-specifieke beperkingen aan. Je moet dan je website geschikt maken voor Windows, Linux en Mac OS X in plaats van voor IE, Firefox en Chrome, of het daar nou echt beter van wordt...
Verder zal het wel een paar graden warmer worden in de diverse datacentra als elke webpagina vergezeld wordt van een rendering-engine...
Verder zal het wel een paar graden warmer worden in de diverse datacentra als elke webpagina vergezeld wordt van een rendering-engine...
Ooit van shared object files gehoord? Je weet wel, die libraries op je computer die gedeeld kunnen worden tussen applicaties, om disk en geheugenruimte te besparen? Nou surprise, het zelfde concept kun je ook op het web toepassen.
Kijk als je einmal bijvoorbeeld WebKit hebt gedownloadt hoef je dat voor dezelfde site EN voor andere sites natuurlijk niet meer te downloaden!
Wat platform specifiekheid betreft, ooit van NaCl gehoord? Low level platform-onafhankelijke code. Ga maar eens in de google code repositories snuffelen.
Er is al veeeeel meer mogenlijk dan jij denkt.
Kijk als je einmal bijvoorbeeld WebKit hebt gedownloadt hoef je dat voor dezelfde site EN voor andere sites natuurlijk niet meer te downloaden!
Wat platform specifiekheid betreft, ooit van NaCl gehoord? Low level platform-onafhankelijke code. Ga maar eens in de google code repositories snuffelen.
Er is al veeeeel meer mogenlijk dan jij denkt.
[Reactie gewijzigd door twop op woensdag 13 februari 2013 12:02]
Ik ben goed op de hoogte van wat wel en niet kan. En er is een reden voor het bestaan van projecten als Wine of Darwine: platform onafhankelijke software is dan wel zwaar inefficient (scripting-talen, Java), dan wel ontzettend beperkt in wat het kan.
Je kunt platform dependence verminderen met dingen als Python of Java, maar je blijft er rekening mee moeten houden.
Shared Objects, ja heel leuk. Dan moet je dus binnen de rendering-engine-loze browser een library / shared object manager gaan bouwen om te trachten om dat in goede banen te leiden en dependency hells te voorkomen. Bovendien krijg je ongetwijfeld websites die niet zo actief bijgehouden worden en een 'oude' versie van 'webkit' serveren, waar weer bugs in zitten die de de PC van de gebruiker investeren met allerhande puinzooi. Zo eenvoudig is dat dus niet.
Dan heb je nog security. Met deze aanpak zou je een willekeurige website toestaan om code op jouw PC uit te voeren, die een rendering-engine zou moeten implementeren. Maar misschien doet die rendering engine nog weer hele andere dingen, waar de gebruiker helemaal niet op zit te wachten. Java op internet is niet voor niets aardig in diskrediet geraakt op websites: feitelijk zou je daarmee kunnen doen wat jij omschrijft. Echter, er kan veel meer gebeuren, er kunnen bugs zitten in de Java VM en weet ik wat allemaal niet. Je opent een gigantische mogelijkheid om de gebruikers aan te vallen, en al die willekeurige code zal op de een of andere manier gecontroleerd moeten worden op veiligheid. Bouwers van virusscanners zullen je dankbaar zijn mocht dit doorgang vinden.
En dan nog een knelpunt: smartphones / tablets. Met hun beperkte resources, opslagruimte en rekenkracht zullen die het een stuk zwaarder krijgen om custom code uit te moeten voeren om elke website te renderen. Bovendien zal het datagebruik ook hier flink moeten stijgen, zelfs met efficiente caching van de rendering code.
Ook voor krachtigere PC's is dit rampzalig: elke website die een slightly different rendering engine heeft zal apart geladen moeten worden, waardoor het geheugengebruik flink zal stijgen, terwijl ze grofweg hetzelfde doen.
Je kunt platform dependence verminderen met dingen als Python of Java, maar je blijft er rekening mee moeten houden.
Shared Objects, ja heel leuk. Dan moet je dus binnen de rendering-engine-loze browser een library / shared object manager gaan bouwen om te trachten om dat in goede banen te leiden en dependency hells te voorkomen. Bovendien krijg je ongetwijfeld websites die niet zo actief bijgehouden worden en een 'oude' versie van 'webkit' serveren, waar weer bugs in zitten die de de PC van de gebruiker investeren met allerhande puinzooi. Zo eenvoudig is dat dus niet.
Dan heb je nog security. Met deze aanpak zou je een willekeurige website toestaan om code op jouw PC uit te voeren, die een rendering-engine zou moeten implementeren. Maar misschien doet die rendering engine nog weer hele andere dingen, waar de gebruiker helemaal niet op zit te wachten. Java op internet is niet voor niets aardig in diskrediet geraakt op websites: feitelijk zou je daarmee kunnen doen wat jij omschrijft. Echter, er kan veel meer gebeuren, er kunnen bugs zitten in de Java VM en weet ik wat allemaal niet. Je opent een gigantische mogelijkheid om de gebruikers aan te vallen, en al die willekeurige code zal op de een of andere manier gecontroleerd moeten worden op veiligheid. Bouwers van virusscanners zullen je dankbaar zijn mocht dit doorgang vinden.
En dan nog een knelpunt: smartphones / tablets. Met hun beperkte resources, opslagruimte en rekenkracht zullen die het een stuk zwaarder krijgen om custom code uit te moeten voeren om elke website te renderen. Bovendien zal het datagebruik ook hier flink moeten stijgen, zelfs met efficiente caching van de rendering code.
Ook voor krachtigere PC's is dit rampzalig: elke website die een slightly different rendering engine heeft zal apart geladen moeten worden, waardoor het geheugengebruik flink zal stijgen, terwijl ze grofweg hetzelfde doen.
Ja, wat is daar het probleem van? De gebruiker hangt al aan het internet, dus dependencies kunnen gewoon middels urls worden aangeduidt, en worden opgelost. Websites kunnen zelf hun dependencies hosten, dus van een "hell" hoeft geen sprake te zijn.Shared Objects, ja heel leuk. Dan moet je dus binnen de rendering-engine-loze browser een library / shared object manager gaan bouwen om te trachten om dat in goede banen te leiden en dependency hells te voorkomen.
Kijk je gaat toch ook niet je ".png" plaatjes op een ander domein hosten? Zelfs niet als je plaatjes uit een clip-art bibliotheek komen?
En je doet gewoon een SHA checksum bij je shared objects om dubbel downloaden te voorkomen. Geen rocket science.
Niet als die websites gewoon linken naar de "meest-recente versie" van browser X. Ik geef toe, het is wel een beetje thinking out-of-the-box, maar het kan gewoon hoor.Bovendien krijg je ongetwijfeld websites die niet zo actief bijgehouden worden en een 'oude' versie van 'webkit' serveren, waar weer bugs in zitten die de de PC van de gebruiker investeren met allerhande puinzooi.
Kijk alsjeblieft een keer naar NaCl. Dat is een low-level virtual machine. Dingen als garbage collecting zit daar niet eens in. En dus volledig niet te vergelijken met Java (!) Het idee is om de virtuele machine zo simpel mogelijk te maken zodat zoveel mogelijk optimalisaties mogelijk zijn en op dit nivo zo min mogelijk security problemen kunnen optreden.Dan heb je nog security. Met deze aanpak zou je een willekeurige website toestaan om code op jouw PC uit te voeren, die een rendering-engine zou moeten implementeren.
Omdat HTML en Javascript vele malen ingewikkelder zijn dan zo'n intermediate instructieset implementeren, zou de security juist vergroot kunnen worden (!)
Dingen als toegang tot files kun je natuurlijk in een aparte layer stoppen. Dat is niet zo ingewikkeld als renderen of een scripttaal.
Nogmaals kijk eens naar NaCl. De techniek schrijdt voort. Opslagruimte word steeds groter en energiegebruik per MB wordtsteeds kleiner, moderne compilers kunnen prima intermediate code omzetten naar efficiente processor-afhankelijke code.En dan nog een knelpunt: smartphones / tablets. Met hun beperkte resources, opslagruimte en rekenkracht zullen die het een stuk zwaarder krijgen om custom code uit te moeten voeren om elke website te renderen.
En dan nog verder iets: wat heb je nou liever? Code die NU misschien werkt op 1 browser en volgende week op alle browsers gewoon brak is omdat de HTML spec gewoon te ingewikkeld is voor browser vendors om volledig na te volgen, OF heb je nu liever gewoon dat je code altijd werkt, met misschien een paar procentjes overhead?
Persoonlijk heb ik graag het laatste of TENMINSTE de keuze.
[Reactie gewijzigd door twop op woensdag 13 februari 2013 13:39]
Ik héb naar NaCl gekeken. Ik beweer niet dat het een slechte techniek is, maar dat waar jij het voor wilt gebruiken is mijns inziens puur misbruik.
NaCl is een methode om zware berekeningen die voor een bepaalde webapp noodzakelijk zijn te kunnen implementeren op een manier die betere performance levert dan datzelfde in Javascript doen. Want voor het keiharde number-crunching blijven scripting talen als Javascript gewoon niet echt geschikt. Daarvoor kan het zeker handig zijn: ook Java zou hiervoor gebruikt kunnen worden als applet.
NaCl is inderdaad geen programmeertaal, maar een soort virtuele machine waarin programma's gedraaid kunnen worden die in een selectie programmeertalen geschreven zijn. Sandboxing is inderdaad een goede mogelijkheid, maar komt, net als het hele virtual machine gebeuren overigens, de prestaties niet ten goede, ondanks dat deze beter zullen zijn dan in Javascript.
Wat je echter over het hoofd ziet is dat ook bij verschillende implementaties van deze virtuele machine implementieverschillen kunnen optreden. Er mag dan wel een standaard zijn waar men zich aan dient te houden, die is er met HTML ook en ook daar blijkt het een uitdaging.
Bovendien, websites draaien om tekst en plaatjes, en een aantrekkelijke grafische weergave daarvan. Eventueel verrijkt met bepaalde scripting als webshops en dergelijke. Dat geldt voor praktisch *iedere* website. Om dus de code om deze representatie, samen met de inhoud, naar de client te sturen, is en blijft ontzettend omslachtig, aangezien elke website deze nodig zal hebben, en deze ook zal moeten bijhouden bij updates.
Jouw suggestie van 'gebruik de laatste versie' is natuurlijk rampzalig ten opzichte van jouw hele punt, want die laatste versie is ongetwijfeld een andere versie dan degene waarmee je je website ontwikkeld hebt, en kan dus incompatible zijn of een ander resultaat hebben. Dan schiet je er dus niets mee op.
Je overdrijft het probleem dramatisch. Ben je zelf een web-developer? Code die NU misschien werkt op 1 browser is slechte code. Code werkt, of werkt niet. Als het misschien werkt dan moet je er nog eens flink naar kijken en de bugs eruit halen.
Als je NU code hebt die op een moderne browser werkt, zeg Firefox, dan werkt deze code NU waarschijnlijk rechtstreeks op Chrome, Safari, Opera en IE >= 9 ook. Is dat niet het geval, dan zijn er over het algemeen vrij weinig wijzigingen nodig om te zorgen dat dat wel zo is. En dan hoef je echt niet bang te zijn dat dat volgende week niet meer werkt: dergelijke regressies zijn zeldzaam. Bugs in de implementatie worden wel opgelost. Mocht je een workaround voor een bug in een bepaalde browser in je code moeten opnemen, dan dien je dat op een manier te doen wat controleert of de bug uberhaubt nog bestaat, zodat, mocht deze bug opgelost worden, je code blijft werken. Zo moeilijk is dat niet.
De problemen doen hun intrede pas als je support voor IE < 9, en dan met name IE 6 en in mindere mate IE 7 wilt hebben. Maar ook hier de goede kant van de zaak: de development van IE 6 staat al jaren stil, dus krijg je je code daadwerkelijk aan de praat op IE 6 dan kun je er vanuit gaan dat daar ook niets aan veranderd.
Om je idee maar even in dezelfde lijn door te zetten: lijkt het je ook een goed idee om geen Word documenten meer rond te sturen, maar voortaan een tekstverwerker rond te mailen waarmee jouw brief / document kunt openen?
NaCl is een methode om zware berekeningen die voor een bepaalde webapp noodzakelijk zijn te kunnen implementeren op een manier die betere performance levert dan datzelfde in Javascript doen. Want voor het keiharde number-crunching blijven scripting talen als Javascript gewoon niet echt geschikt. Daarvoor kan het zeker handig zijn: ook Java zou hiervoor gebruikt kunnen worden als applet.
NaCl is inderdaad geen programmeertaal, maar een soort virtuele machine waarin programma's gedraaid kunnen worden die in een selectie programmeertalen geschreven zijn. Sandboxing is inderdaad een goede mogelijkheid, maar komt, net als het hele virtual machine gebeuren overigens, de prestaties niet ten goede, ondanks dat deze beter zullen zijn dan in Javascript.
Wat je echter over het hoofd ziet is dat ook bij verschillende implementaties van deze virtuele machine implementieverschillen kunnen optreden. Er mag dan wel een standaard zijn waar men zich aan dient te houden, die is er met HTML ook en ook daar blijkt het een uitdaging.
Bovendien, websites draaien om tekst en plaatjes, en een aantrekkelijke grafische weergave daarvan. Eventueel verrijkt met bepaalde scripting als webshops en dergelijke. Dat geldt voor praktisch *iedere* website. Om dus de code om deze representatie, samen met de inhoud, naar de client te sturen, is en blijft ontzettend omslachtig, aangezien elke website deze nodig zal hebben, en deze ook zal moeten bijhouden bij updates.
Jouw suggestie van 'gebruik de laatste versie' is natuurlijk rampzalig ten opzichte van jouw hele punt, want die laatste versie is ongetwijfeld een andere versie dan degene waarmee je je website ontwikkeld hebt, en kan dus incompatible zijn of een ander resultaat hebben. Dan schiet je er dus niets mee op.
Je overdrijft het probleem dramatisch. Ben je zelf een web-developer? Code die NU misschien werkt op 1 browser is slechte code. Code werkt, of werkt niet. Als het misschien werkt dan moet je er nog eens flink naar kijken en de bugs eruit halen.
Als je NU code hebt die op een moderne browser werkt, zeg Firefox, dan werkt deze code NU waarschijnlijk rechtstreeks op Chrome, Safari, Opera en IE >= 9 ook. Is dat niet het geval, dan zijn er over het algemeen vrij weinig wijzigingen nodig om te zorgen dat dat wel zo is. En dan hoef je echt niet bang te zijn dat dat volgende week niet meer werkt: dergelijke regressies zijn zeldzaam. Bugs in de implementatie worden wel opgelost. Mocht je een workaround voor een bug in een bepaalde browser in je code moeten opnemen, dan dien je dat op een manier te doen wat controleert of de bug uberhaubt nog bestaat, zodat, mocht deze bug opgelost worden, je code blijft werken. Zo moeilijk is dat niet.
De problemen doen hun intrede pas als je support voor IE < 9, en dan met name IE 6 en in mindere mate IE 7 wilt hebben. Maar ook hier de goede kant van de zaak: de development van IE 6 staat al jaren stil, dus krijg je je code daadwerkelijk aan de praat op IE 6 dan kun je er vanuit gaan dat daar ook niets aan veranderd.
Om je idee maar even in dezelfde lijn door te zetten: lijkt het je ook een goed idee om geen Word documenten meer rond te sturen, maar voortaan een tekstverwerker rond te mailen waarmee jouw brief / document kunt openen?
Mijn punt is dat het heel wat simpeler is om een beperkte instructieset te ondersteunen dan een ingewikkeld en harig beest als de HTML spec.Wat je echter over het hoofd ziet is dat ook bij verschillende implementaties van deze virtuele machine implementieverschillen kunnen optreden.
Dit komt de interoperabiliteit ten goede, alsmede het ontwikkelgemak voor developers, alsmede waarschijnlijk de security.
Dat kan de default instelling zijn. Dan werkt het allemaal zoals nu. Eventueel kan die browser dan geoptimaliseerd zijn voor verschillende architecturen (uiteraard met certificering, zodat deze code gedraaid mag worden).Jouw suggestie van 'gebruik de laatste versie' is natuurlijk rampzalig ten opzichte van jouw hele punt, want die laatste versie is ongetwijfeld een andere versie dan degene waarmee je je website ontwikkeld hebt, en kan dus incompatible zijn of een ander resultaat hebben. Dan schiet je er dus niets mee op.
Met andere woorden, als jij als ontwikkelaar in een archaische omgeving wilt blijven werken, dan kan dat in deze opzet gewoon
Niet als de code juist wordt hergebruikt over verschillende websites.Om dus de code om deze representatie, samen met de inhoud, naar de client te sturen, is en blijft ontzettend omslachtig
Ik gok dat er, met deze techniek, net als nu een paar grote (open-source) projecten kunnen bestaan die renderaars leveren. Als iedereen (of het merendeel van de websites) code gebruikt van deze projecten, dan valt het allemaal wel mee met het downloaden. Plus je hebt de flexibiliteit voor situaties waarin je het anders wilt.
Verder, je vergeet dat er steeds meer grote projecten op internet komen, geschreven in javascript (denk aan gmail). Die gebruiken ook allemaal bibliotheken. En die moeten ook gedownload worden (!!!)
Ik merk alleen dat code die ik 40 jaar geleden schreef altijd veel robuuster was dan code die ik nu schrijf. En die code kan ik nu nog steeds draaien in een emulator.Je overdrijft het probleem dramatisch.
Verder, en dat is het belangrijkste punt, ik kan eigenlijk voor het web alleen in javascript programmeren op dit moment. Wel een beetje beperkend. Als de code meer dan 10.000 regels lang wordt, dan heb ik toch graag iets van een typechecker ofzo. Het is gewoon allemaal zo knullig. En daarom doe ik ook eigenlijk ook vrij weinig met web-development.
Om eerlijk te zijn ... ja!Om je idee maar even in dezelfde lijn door te zetten: lijkt het je ook een goed idee om geen Word documenten meer rond te sturen, maar voortaan een tekstverwerker rond te mailen waarmee jouw brief / document kunt openen?
Dan heb ik tenminste een redelijke kans dat ik het bestand over 10 jaar nog steeds kan openen!
[Reactie gewijzigd door twop op woensdag 13 februari 2013 16:42]
Een situatie waarin elke website zijn eigen renderer meelevert noem ik net zo archaisch als eentje waarbij de document standaard gestandaardiseerd is en waar het leeuwendeel van de websites zich ook behoorlijk aan houdt.Met andere woorden, als jij als ontwikkelaar in een archaische omgeving wilt blijven werken, dan kan dat in deze opzet gewoon
Correct. Echter hoeven die heel wat minder te doen dan een complete grafische interface te renderen. De basis UI components zijn al beschikbaar inclusief een mooie API om de boel aan te sturen, die de client al beschikbaar heeft. Hierdoor blijft de download beperkt tot enkele honderden kilobytes, en vaak veel minder dan dat als compressie en minification toegepast wordt.Verder, je vergeet dat er steeds meer grote projecten op internet komen, geschreven in javascript (denk aan gmail). Die gebruiken ook allemaal bibliotheken. En die moeten ook gedownload worden (!!!)
Dat jij wel een IDE wilt voor je Javascript code maar deze klaarblijkelijk niet gebruikt dat is jouw eigen keuze, niet de schuld van Javascript of web-development in het algemeen. Er zijn prima IDE's beschikbaar die precies doen wat jij wilt.Verder, en dat is het belangrijkste punt, ik kan eigenlijk voor het web alleen in javascript programmeren op dit moment. Wel een beetje beperkend. Als de code meer dan 10.000 regels lang wordt, dan heb ik toch graag iets van een typechecker ofzo. Het is gewoon allemaal zo knullig. En daarom doe ik ook eigenlijk ook vrij weinig met web-development.
Juist het belangrijkste voordeel van HTML: dat kun je over 10 jaar desnoods nog met het blote oog lezen.Om eerlijk te zijn ... ja!
Dan heb ik tenminste een redelijke kans dat ik het bestand over 10 jaar nog steeds kan openen!
En voor je Word-document is daar PDF voor uitgevonden. Ik zou er nog meer in zien om het hele web als PDF te publiceren dan om het als binary / custom renderer te serveren.
Ik denk dat we er niet uit gaan komen
Maar bedankt voor de discussie!
Maar bedankt voor de discussie!
In principe zouden de render-engines pixel moeten werken als ze zich houden aan de specificaties van HTML5.
Maar dan is de voorwaarde dus dat een website met HTML5 markup moet worden gemaakt, je kan dat niet verwachten; zeker van oude pagina's niet, die ook goed weergegeven moeten worden.In principe zouden de render-engines pixel moeten werken als ze zich houden aan de specificaties van HTML5.
Inderdaad. Specifieke optimalisaties zijn nooit goed. Ze moeten gewoon zorgen dat ze voor HTML5 programmeren zodat alle websites er optimaal gebruik van maken. De Engines moeten gewoon zorgen dat ze dat goed kunnen doen.
Mwah... Opera was dan niet zo groot, maar minder renderers is niet noodzakelijk beter. Als Chromium erg groot wordt kunnen ze te makkelijk non-standaard elementen/attributen introduceren. En dan krijg je op termijn hetzelfde probleem dat we ook met IE hadden (websites die alleen in browser X werken).
Opera was is weldegelijk groot. Opera Mini is in Azië, delen van Oost-Europa en India erg populair. Dit omdat het draait op elk toestel, ook de waar normaal gesproken geen volledige render engine op zal draaien. Bijvoorbeeld een Nokia 6230.
http://gs.statcounter.com...-as-monthly-201201-201301
(okee, ze worden wereldwijd ingehaald door (budget-)android-toestellen, maar dan nog. 24% voor een heel continent is best veel)
http://gs.statcounter.com...-as-monthly-201201-201301
(okee, ze worden wereldwijd ingehaald door (budget-)android-toestellen, maar dan nog. 24% voor een heel continent is best veel)
Om nog maar te zwijgen over geintegreerde implementaties zoals de Nintendo Wii en bepaalde TV's.
Oja, da's waar. M'n eigen tv draait Opera, net zoals elke niet-kpn glazvezel-settopbox (van Amino) in nederland.
Ik zie veel liever dat de rendering alleen maar afhangt van de W3C-standaarden dan van browsers ...
Ja ik wil dat er altijd en overal vrede is. Maarja onmogelijke dingen gaan gewoon niet gebeuren, kan je hopen/willen maar is gewoon niet realistisch...
Ik wil gewoon dat mijn sites overal goed werken, welke standaard daar ook voor nodig is
Ik wil gewoon dat mijn sites overal goed werken, welke standaard daar ook voor nodig is
[Reactie gewijzigd door watercoolertje op woensdag 13 februari 2013 10:59]
Tsja. Beperk je dan gewoon tot een table met cellen van 1px hoog/breed en regel alles in ECMAScript 1.0. Werkt altijd (waarschijnlijk zelfs in IE old en Netscape antiek) maar dat wil je vast ook niet....
Tables are evil!
Zou prettig zijn.... maar zolang de W3C standaarden achter lopen bij de browser, is daar weinig hoop op...
Des te meer reden om het bij HTML5 nu gewoon meteen goed te doen. De standaard staat zo goed als vast, haal in ieder geval die -webkit- prefixes dan weg (of bied er ook ondersteuning voor), dan kan een ontwikkelaar echt vele malen beter ontwikkelen voor websites. Tuurlijk kun je voor elke browser een aparte prefix toevoegen, maar dat werkt niet overzichtelijk en zorgt alleen maar voor een grotere download. En dat wil je ook niet.
Die -webkit (en -o, en -ie, en -firefox, en watdanook) prefixes zijn voor extensies die nog niet standaard zijn, maar wat een standaard in wording is. Je ageert tegen iets wat juist heel duidelijk is afgesproken.
Wat jij feitelijk zegt is dat browsers zich niet aan de standaarden houden.Zou prettig zijn.... maar zolang de W3C standaarden achter lopen bij de browser, is daar weinig hoop op...
Hoe kunnen standaarden nu achter lopen? Op wat? Op eigen wensen en verzinsels van de browsermakers? IE-praktijken van weleer dus.
Een standaard is een afspraak die NU geldt. Per definitie kan die dus niet achterlopen.
Dat is niet hoe het W3C tegenwoordig werkt. Het is niet zo dat het W3C zelf standaarden bedenkt en deze oplegt aan browser makers. De meeste ideeen worden door een browser maker zonder standaard geimplementeerd, en als deze aanslaat, en de W3C deelnemers vinden dit nuttig om in de standaard te verwerken, dan wordt het mogelijk een W3C standaard.
Bijna alle standaarden in HTML5 en CSS3 zijn ontstaan uit browsermakers. De implementatie komt dus eerder dan de standaard.
Bijna alle standaarden in HTML5 en CSS3 zijn ontstaan uit browsermakers. De implementatie komt dus eerder dan de standaard.
Ik vraag me af of je dat echt wil. Er zijn heel veel dingen nog steeds geen officiële standaard, die iedereen al wel gebruikt. Als men zich beperkt tot wat al gestandaardiseerd is komen we nooit verder.
Hoe minder verschillende renders, hoe slechter voor het web. Dit is alle, behalve goed nieuws. Of moet ik je helpen herinneren aan IE6?
IE6 is niet te vergelijken. Webkit wordt door meerdere bedrijven actief ontwikkeld, waaronder bedrijven die belang hebben in een snelle evolutie van het web. Tevens auto-updaten bijna alle web browsers.
Microsoft had in die tijd een belang om juist het web tegen te houden, en liet de browser versloffen. Ook deed het geen enkele moeite om oude versies op te ruimen. Twee heel belangrijke verschillen.
We hebben nog steeds 3 verschillende main engines, en dat is meer dan genoeg. Het probleem is helemaal niet webkit, het probleem is incompetente developers die webkit-only features bakken, in gevallen waar dit niet gepast is.
Microsoft had in die tijd een belang om juist het web tegen te houden, en liet de browser versloffen. Ook deed het geen enkele moeite om oude versies op te ruimen. Twee heel belangrijke verschillen.
We hebben nog steeds 3 verschillende main engines, en dat is meer dan genoeg. Het probleem is helemaal niet webkit, het probleem is incompetente developers die webkit-only features bakken, in gevallen waar dit niet gepast is.
Niet helemaal mee eens, immers is Presto goed standardscompliant. Alleen IE is brak.
Trident is minder brak dan Webkit...
ROFL
Of jij weet niet waar je het over hebt of je bent een mega troll
Als er een renderings-engine is die vervloekt wordt door webontwikkelaars is het trident.
toegegeven het is tegenwoordig beter dan vroeger, maar nog steeds rare bugs en loopt het achter.
Hier heb ik je btw al een keer of 10 op gewezen dus ik hou het maar even op troll ipv onwetend.
Of jij weet niet waar je het over hebt of je bent een mega troll
Als er een renderings-engine is die vervloekt wordt door webontwikkelaars is het trident.
toegegeven het is tegenwoordig beter dan vroeger, maar nog steeds rare bugs en loopt het achter.
Hier heb ik je btw al een keer of 10 op gewezen dus ik hou het maar even op troll ipv onwetend.
[Reactie gewijzigd door hackerhater op woensdag 13 februari 2013 20:15]
Ja ik heb dagelijks te maken met deze dingen.
Er zitten verschillen in en dat is niks verwondelijk voor spul dat nog niet af is.
Echter vergeleken met dat piep trident is het NIKS. Vandaag nog 2 uitzonderingen moeten schrijven voor IE om de muis positie op te vragen aan een event. Zelfs IE 9 & 10 ondersteunen de standaard niet!
Ook een "leuke" : De case van de accepted languages in IE verschilt tussen een directe en Ajax call
Er zitten verschillen in en dat is niks verwondelijk voor spul dat nog niet af is.
Echter vergeleken met dat piep trident is het NIKS. Vandaag nog 2 uitzonderingen moeten schrijven voor IE om de muis positie op te vragen aan een event. Zelfs IE 9 & 10 ondersteunen de standaard niet!
Ook een "leuke" : De case van de accepted languages in IE verschilt tussen een directe en Ajax call
[Reactie gewijzigd door hackerhater op donderdag 14 februari 2013 14:37]
Persoonlijk vind ik dit een hele goede actie.
Opera vind ik een van de betere browsers als het om de gebruiksvriendelijkheid en functies aan komt.
Helaas is het voor mij ook de browser waar ik de meeste fouten tegen kom op webpagina's inclusief mijn eigen website.
Speciaal voor opera heb ik in een frame een scrollbar toegevoegd omdat de autoresize er niet op werkt (Zelfs IE7 heeft hier geen moeite mee).
Als de nieuwe versie uit is zal ik zeker overwegen om over te stappen.
Opera vind ik een van de betere browsers als het om de gebruiksvriendelijkheid en functies aan komt.
Helaas is het voor mij ook de browser waar ik de meeste fouten tegen kom op webpagina's inclusief mijn eigen website.
Speciaal voor opera heb ik in een frame een scrollbar toegevoegd omdat de autoresize er niet op werkt (Zelfs IE7 heeft hier geen moeite mee).
Als de nieuwe versie uit is zal ik zeker overwegen om over te stappen.
Straks is het dus een van de betere skins op WebKit, want veel meer is het dan niet meer. Dus of dit een hele goede actie is weet ik niet.
Safari, Chrome, Opera v.s. Internet Explorer is het dan meer, want tussen de eerste drie zijn nagenoeg geen verschil op het uiterlijk na.
Safari, Chrome, Opera v.s. Internet Explorer is het dan meer, want tussen de eerste drie zijn nagenoeg geen verschil op het uiterlijk na.
oh jawel, verschillen genoeg. webkit is een html rendering engine, maar er zijn nog andere dingen die verwerkt moeten worden. Wat dacht je bijvoorbeeld van javascript? Een techniek die vandaag in moderne webapps toch ook niet onbelangrijk is. Daarnaast heb je ook nog altijd andere keuzes te maken. Welke codecs ga je bijvoorbeeld ondersteunen in de <video> tag? Heb je het geld om h.264 te implementeren of ga je het houden op webm?
Beetje jammer dat webkit zo nog een groter marktaandeel krijgt.
Op zich niks mis mee, maar we gaan nu wel weer naar het tijdperk toe dat sites ontworpen worden voor 1 specifieke engine/browser (denk aan IE vroeger) en dat is niet goed voor de standaarden.
Op zich niks mis mee, maar we gaan nu wel weer naar het tijdperk toe dat sites ontworpen worden voor 1 specifieke engine/browser (denk aan IE vroeger) en dat is niet goed voor de standaarden.
Zolang Webkit de standaarden blijft volgen, is er geen probleem. Het wordt pas een probleem als Webkit plots een eigen leven gaat leiden en van de standaard gaat afwijken. Dan worden de rollen omgekeerd en wordt Webkit wat IE vroeger was.
Dat is juist het probleem, webkit volgt de standaarden niet zo nauw, ze willen OF te ver voorlopen en voeren webkit-specifieke dingen in (CSS3 is vrij goed uitgezet, maar toch zijn er dingen als:
webkit-border-radius
en
border-radius
Border Radius is iets wat niet eens zo lang geleden tot standaard gebombardeerd wordt. Je geeft het een paar nummertjes mee, en voila, je objectje heeft een mooi afgeronde border. Het punt is dat webkit iets te snel was met het invoeren van een draft-standaard (in plaats van afwachten tot de echte standaard), en hun eigen implementatie maakte wat EXACT hetzelfde doet, maar dan twee nummertjes heeft omgedraait... en een webkit-tag er voor.
Het resultaat? Tsja... veel "techies" die zeuren dat een browser niet webkit-compatible is, als hij 100% HTML5 & CSS3 volgt... en een hoop webdevvers die, zoals eerder omschreven, pietje precies webkit ontwikkelen.
Webkit is hard op weg om een nieuw IE6 te worden: de tijd vooruit, engine-specifieke rendertags, en een groot marktaandeel... het is eigenlijk een gevaar. Gecko is overigens niet zo handig bezig als je het mij vraagt door SOMS wel en SOMS niet webkit-tags te renderen... zo krijg je nog meer webkit-specifiek ontwikkelwerk (met de motivatie: het werkt toch wel onder firefox), en nog meer onverwachte eigenaardigheden, zoals op dit moment met fileapi en notifications...
Ik zou haast hierdoor de switch maken naar IE10. Eigenlijk... ik denk dat ik dat ga doen.
webkit-border-radius
en
border-radius
Border Radius is iets wat niet eens zo lang geleden tot standaard gebombardeerd wordt. Je geeft het een paar nummertjes mee, en voila, je objectje heeft een mooi afgeronde border. Het punt is dat webkit iets te snel was met het invoeren van een draft-standaard (in plaats van afwachten tot de echte standaard), en hun eigen implementatie maakte wat EXACT hetzelfde doet, maar dan twee nummertjes heeft omgedraait... en een webkit-tag er voor.
Het resultaat? Tsja... veel "techies" die zeuren dat een browser niet webkit-compatible is, als hij 100% HTML5 & CSS3 volgt... en een hoop webdevvers die, zoals eerder omschreven, pietje precies webkit ontwikkelen.
Webkit is hard op weg om een nieuw IE6 te worden: de tijd vooruit, engine-specifieke rendertags, en een groot marktaandeel... het is eigenlijk een gevaar. Gecko is overigens niet zo handig bezig als je het mij vraagt door SOMS wel en SOMS niet webkit-tags te renderen... zo krijg je nog meer webkit-specifiek ontwikkelwerk (met de motivatie: het werkt toch wel onder firefox), en nog meer onverwachte eigenaardigheden, zoals op dit moment met fileapi en notifications...
Ik zou haast hierdoor de switch maken naar IE10. Eigenlijk... ik denk dat ik dat ga doen.
Ik merk nu al dat Google hun services specifiek voor webkit aan lijkt te passen. De laatste tijd draait Google Maps echt voor geen meter meer op Firefox. Slome laadtijden, haperend inzoomen. Op een chromium browser gaat het dan ineens 3x zo snel.
De wereld op z'n kop.
Google investeert heeft veel tijd en moeite in de optimalisatie van hun Javascript engine voor dit soort complexe applicaties. (De performance van Google earth hangt af van Javascript, niet zozeer Webkit/HTNL).
Je ziet dat andere browsers daar nog in achter lopen, hoewel het verschil minder is dan het was.
Google investeert heeft veel tijd en moeite in de optimalisatie van hun Javascript engine voor dit soort complexe applicaties. (De performance van Google earth hangt af van Javascript, niet zozeer Webkit/HTNL).
Je ziet dat andere browsers daar nog in achter lopen, hoewel het verschil minder is dan het was.
Leek me heel vreemd en dus heb ik het maar even getest. Firefox 18.0.2 en alles werkt reuze soepel.Ik merk nu al dat Google hun services specifiek voor webkit aan lijkt te passen. De laatste tijd draait Google Maps echt voor geen meter meer op Firefox.
De oplossing is simpel:
Je doet EERST je browser specifieke CSS3 (-webkit, -moz e.d) en dan de "prefixloze" CSS3 property zodat dze als laatste word uitgeveord en de browser zich aan de standaard houd.
Je doet EERST je browser specifieke CSS3 (-webkit, -moz e.d) en dan de "prefixloze" CSS3 property zodat dze als laatste word uitgeveord en de browser zich aan de standaard houd.
Waarom zou ik prefixes moeten gebruiken als er al een prefix-vrije standaard is?De oplossing is simpel:
Je doet EERST je browser specifieke CSS3 (-webkit, -moz e.d) en dan de "prefixloze" CSS3 property zodat dze als laatste word uitgeveord en de browser zich aan de standaard houd.
Als er zoals in het voorbeeld van border-radius een standaard is dan moet de prefix-versie uit webkit-gesloopt worden.
Zal voor sites die jouw methode niet geïmplementeerd hebben voor problemen kunnen zorgen. Het geeft wel aan wat het probleem met prefixes is. De vervuilende rijtjes met prefixes blijven bestaan omdat men bang is dat dingen opeens niet meer werken.
De reden waarom webkit dat blijft ondersteunen is backwards compatibility voor sites die nog niet zijn bijgewerkt.
Dat webdevers de prefixes moeten weghalen voor onderdelen die final zijn ben ik met je eens.
Dat webdevers de prefixes moeten weghalen voor onderdelen die final zijn ben ik met je eens.
Dat is expres, en precies met die reden: daarmee kun je dus als browserbouwer alvast die standaarden implementeren voordat ze standaard zijn en als dan later de standaard toch aangepast wordt tov de draft (zoals hier blijkbaar gebeurd is) heb je geen sites die kapot gaan. En Firefox kan dan juist geimplementeerd hebben wat later wel tot standaard gebombardeerd wordt (dus met die nummertjes omgedraaid, wat men blijkbaar logischer vindt), en dan heb je terwijl de standaard nog geen standaard is geen sites die op webkit 't een doen en op firefox het ander. In plaats daarvan zeg je als webbouwer dus tegen webkit X-Y en tegen firefox Y-X, tegelijk. Eenmaal de standaard geaccepteerd voeg je de standaard (Y-X) toe.Border Radius is iets wat niet eens zo lang geleden tot standaard gebombardeerd wordt. Je geeft het een paar nummertjes mee, en voila, je objectje heeft een mooi afgeronde border. Het punt is dat webkit iets te snel was met het invoeren van een draft-standaard (in plaats van afwachten tot de echte standaard), en hun eigen implementatie maakte wat EXACT hetzelfde doet, maar dan twee nummertjes heeft omgedraait... en een webkit-tag er voor.
Laat die zin eens goed tot je doordringen en je hebt meteen het probleem te pakken.... daarmee kun je dus als browserbouwer alvast die standaarden implementeren voordat ze standaard zijn...
Veel mensen wilden border-radius al kunnen gebruiken voor dat het een standaard was. Het is toch van de zotte dat dat vanuit zo'n stugge organisatie jaren moet duren voordat zoiets triviaals als een radius op randen kon. Webkit innoveert dan tenminste in plaats van geen oplossing bieden totdat het daadwerkelijk een standaard is. En nu ondersteunen ze toch gewoon border-radius, dus wat is het probleem? Had je verwacht dat ze webkit-border-radius ineens onklaar zouden maken? Dat is toch superslecht, dan dwing je miljarden websites om dergelijke trivialiteit nog weer om te zetten naar de standaard.
Dat is toch ook het doel van de standaarden. Dat iedereen ze gaat gebruiken. Of was al dat gejammer of IE destijds ook onzin?
Nu is IE10 zo'n beetje als het hoort zitten we met nieuwe ellende. Noem het triviaal maar ik wordt doodmoe van al die prefix-rijtjes. De lijst groeit en groeit.
En dan is het nog niet eens letterlijk er een prefix voorzetten, de code is vaak ook (flink) anders. Vroeger was het enkel fixen voor IE, nu fix je overal voor.
Dat web-kit innoveert is prima en het duurt inderdaad te lang voor iets een standaard wordt. Maar je er om die reden niet aan houden zorgt over een paar jaar voor soortgelijke ellende als we kennen bij de fixes die we voor de verschillende IE-versies moeten aanbrengen.
Nu is IE10 zo'n beetje als het hoort zitten we met nieuwe ellende. Noem het triviaal maar ik wordt doodmoe van al die prefix-rijtjes. De lijst groeit en groeit.
En dan is het nog niet eens letterlijk er een prefix voorzetten, de code is vaak ook (flink) anders. Vroeger was het enkel fixen voor IE, nu fix je overal voor.
Dat web-kit innoveert is prima en het duurt inderdaad te lang voor iets een standaard wordt. Maar je er om die reden niet aan houden zorgt over een paar jaar voor soortgelijke ellende als we kennen bij de fixes die we voor de verschillende IE-versies moeten aanbrengen.
Er is een groot verschil in deze onderdelen die nog niet final zijn/waren waarvan je kan verwachten dat ze nog veranderen en de oudere IE's die final onderdelen niet goed doen renderen.
Vergelijk het met software ontwikkeling. In beta's (delen van CSS 3 spec) kunnen bugs zitten, das normaal. Bugs in final versies (CSS 1 & 2) zijn minder wenselijk.
Vergelijk het met software ontwikkeling. In beta's (delen van CSS 3 spec) kunnen bugs zitten, das normaal. Bugs in final versies (CSS 1 & 2) zijn minder wenselijk.
[Reactie gewijzigd door hackerhater op woensdag 13 februari 2013 20:00]
Wat veel ontwikkelaars niet weten is dat vendor-prefixes wel degelijk standaarden zijn: het is de standaard manier om niet-produktie-rijpe features op te leveren.
Het is vervolgens aan ontwikkelaars om te besluiten om deze al te gebruiken of niet. Hierin lijkt het alsof men iets te gretig is.
De oplossing is in de meeste gevallen simpel: gebruik een CSS preprocessor. Als ik een border-radius wil, doe ik dit:
@include border-radius(5);
Vervolgens mag de preprocessor uitvogelen welke extensies en syntaxen nodig zijn.
Het is vervolgens aan ontwikkelaars om te besluiten om deze al te gebruiken of niet. Hierin lijkt het alsof men iets te gretig is.
De oplossing is in de meeste gevallen simpel: gebruik een CSS preprocessor. Als ik een border-radius wil, doe ik dit:
@include border-radius(5);
Vervolgens mag de preprocessor uitvogelen welke extensies en syntaxen nodig zijn.
En dat is nu al het geval. De webkit implementatie voor touch interactie is volledig webkit specifiek. Er zitten zelfs patenten op, waardoor andere browsers het niet kunnen implementeren zonder aan Apple te betalen. Dus ook die ontwikkeling is echt niet goed.
Dat van touch is inderdaad even uitzoeken, maar daar is prima omheen te werken. Gewoon de webkit prefix gebruiken, maar het probleem zit hem meer in de andere tags die bv op animaties of het box-model van toepassing zijn.
Nu IE10 weer wat meer ondersteund is het jammer om te zien dat sommige websites niet werken omdat ze er geen generieke tag onder gehangen hebben (dus -webkit-border-radius blijven gebruiken en er desnoods niet border-radius naast zetten, idem voor achtergronden).
Nu IE10 weer wat meer ondersteund is het jammer om te zien dat sommige websites niet werken omdat ze er geen generieke tag onder gehangen hebben (dus -webkit-border-radius blijven gebruiken en er desnoods niet border-radius naast zetten, idem voor achtergronden).
Jammer genoeg zijn we het tijdperk dat Webkit netjes de standaarden volgt ook weer enkele maanden voorbij: -webkit-, weet je wel...
En -o-, en -ie-, en -firefox- dan? Die tellen niet mee?
Ja, maar -o- en -moz- worden tenminste vervangen. -ms- is niet eens perse nodig doordat IE dan ook (99%) de standaard ondersteund, dus hetzelfde, zonder prefix.
-webkit- wordt ook vervangen, alleen halen ze wellicht niet de -prefixversie direct weg. Eenmaal een standaard krijgt webkit ook gewoon de standaard versie.
Ik zei niet dat het niet af en toe even duurt. Webkit mag zelf kiezen in waar ze prioriteit aan geven.
-webkit is WEL een standaard. Het is de standaard manier om een experimentele feature te lanceren. Ze doen hierin alles correct, 100% volgens standaarden.
Het is een fout van ontwikkelaars om vendor prefixes verkeerd in te zetten.
Het is een fout van ontwikkelaars om vendor prefixes verkeerd in te zetten.
Zolang Internet explorer/trident nog meer marktaandeel heeft dan gecko/webkit, zal dit probleem waarschijnlijk niet voorkomen, aangezien programmeurs hun site, zeker weten, ook geoptimaliseerd willen hebben voor de meest gebruikte browser.
Wikimedia , veel SVG, rendert niet in explorer. Dus Safari, Chrome, Firefox... Opera
Voor mobiele websites (waar mogelijk een hoop optimalisaties bij komen kijken) is IE/trident vrijwel niet bestaand.
Als ik statcounter mag geloven is IE ook al geen marktleider meer, met een neergaande trend. De demografie die ze nog hebben bestaan vervolgens voor een aanzienlijk deel uit gebruikers van verouderde browsers.
Begrijp me niet verkeerd, ik vind dat een web-developer zoveel mogelijk platformen moet ondersteunen (we moeten niet naar een IE6 tijd). Aan de andere kant kan ik me voorstellen dat IE relevantie verliest bij mobiele sites of web-applicaties die profiteren van moderne browsers.
Bovendien blijft Microsoft de eigen glazen ingooien door zo weinig platformen te ondersteunen. Hun eigen OS Windows XP werd vanaf IE9 al niet meer ondersteund, terwijl dat zelf nu nog 38% marktaandeel heeft. Geen ondersteuning voor Linux, android, OSX, ios...
Ik ontwikkel op een OSX apparaat en om voor IE te testen moet je rommelen met Wine, VirtualBox weet ik het. Als ik de keuze had gehad zou ik een Linux apparaat gebruiken, maar dan heb je hetzelfde gezeur. Developers, developers, developers.
edit:verspreking
Als ik statcounter mag geloven is IE ook al geen marktleider meer, met een neergaande trend. De demografie die ze nog hebben bestaan vervolgens voor een aanzienlijk deel uit gebruikers van verouderde browsers.
Begrijp me niet verkeerd, ik vind dat een web-developer zoveel mogelijk platformen moet ondersteunen (we moeten niet naar een IE6 tijd). Aan de andere kant kan ik me voorstellen dat IE relevantie verliest bij mobiele sites of web-applicaties die profiteren van moderne browsers.
Bovendien blijft Microsoft de eigen glazen ingooien door zo weinig platformen te ondersteunen. Hun eigen OS Windows XP werd vanaf IE9 al niet meer ondersteund, terwijl dat zelf nu nog 38% marktaandeel heeft. Geen ondersteuning voor Linux, android, OSX, ios...
Ik ontwikkel op een OSX apparaat en om voor IE te testen moet je rommelen met Wine, VirtualBox weet ik het. Als ik de keuze had gehad zou ik een Linux apparaat gebruiken, maar dan heb je hetzelfde gezeur. Developers, developers, developers.
edit:verspreking
[Reactie gewijzigd door snirpsnirp op woensdag 13 februari 2013 12:21]
Ook dat is al te laat. Het is nog niet zo zeer slecht voor desktops, maar voor mobiele browsers als Firefox en IE wordt dit een zeer groot probleem vanwege de laksheid van veel ontwikkelaars.
Of juist wel goed voor de ontwikkeling omdat je al je programmeertijd kunt steken in één engine in plaats van te moeten spreiden en telkens weer testen in 3 of meer engines.
Je zou het eigenlijk helemaal niet moeten hoeven testen in 3 browsers als de standaarden al gewoon prima in elkaar zitten. Omdat HTML5 nog niet zo heel lang definitief is geworden (ok, het hele proces is nog niet klaar, maar er zit nu al wat schot in) lopen nog niet alle browsers bij. Doordat webkit echter een heleboel features al had toegevoegd, zitten we nu op het punt waarop vele websites weer aanpassingen moeten doen om browsers compatibel te maken aan de originele standaard.
Voordat HTML5 kwam, had ik geen problemen om een site die ik in chrome heb opgebouwd in firefox te laten werken. Maar omdat men bij webkit op een gegeven moment concept webstandaarden is gaan gebruiken, werkte die manier opeens niet meer.
Voordat HTML5 kwam, had ik geen problemen om een site die ik in chrome heb opgebouwd in firefox te laten werken. Maar omdat men bij webkit op een gegeven moment concept webstandaarden is gaan gebruiken, werkte die manier opeens niet meer.
Je gebruikt onderdelen die nog niet final zijn en gaat dan klagen dat het nog veranderd?
Kijk in de spiegel en dan weet je who to blame.
Er is niet voor niets gezegd dit niet voor productie te gebruiken tenzij je kan leven met de concequenties.
Kijk in de spiegel en dan weet je who to blame.
Er is niet voor niets gezegd dit niet voor productie te gebruiken tenzij je kan leven met de concequenties.
Voor Opera werdt toch al praktisch nooit geoptimaliseerd en Webkit wint met Opera-gebruikers gemiddeld waarschijnlijk minder dan een procent op de browsermarkt, dus het loopt wel los denk ik.
[Reactie gewijzigd door Aham brahmasmi op woensdag 13 februari 2013 11:06]
Jammer ik vindt Opera erg prettig en het feit dat het behoorlijk compacte browser is zonder bloatware.
Onder linux zowel als windows gaat het nog steeds als een trein.
Dat het percentage laag ligt betekend niet veel.....
Onder linux zowel als windows gaat het nog steeds als een trein.
Dat het percentage laag ligt betekend niet veel.....
Volgens mij veranderd er verder niks aan de features van de browser, dus waarom zou je dit jammer vinden? Het blijft gewoon de browser die je gewent bent, maar dan met een andere render engine.
Er ligt ook een stukje veiligheid wat er aan te pas komt. Van Opera weet ik zeker dat hun code erg klein is dit laat weinig ruimte over voor backdoors enzovoort. Als dit wordt overgeheveld op een webkit zit je eigenlijk weer in een grotere vijver en wordt het makkelijker voor mensen die kwaad willen.
De vijver word ook bewaakt door meerdere mensen...
koffie dik kijken imo..
koffie dik kijken imo..
Sterker nog, Opera wil zelf bijdragen aan Webkit. Een deel van de mensen die de vijver bewaken blijft dus hetzelfde!
Ik las in een andere reactie hier dat een aantal developers zeggen dat het eerste wat ze gaan doen de css-ondersteuning van Webkit op Presto-niveau brengen.
Ik las in een andere reactie hier dat een aantal developers zeggen dat het eerste wat ze gaan doen de css-ondersteuning van Webkit op Presto-niveau brengen.
Het is een bekend gegeven des te groter de broncode des te groter de kans dat er fouten in zitten.
Ik gebruik Opera op windows en op Android, o.a. vanwege de snelheid en vloeiendheid van de renderengine.
Maar in OSX is Opera vergeleken met Webkit (Chrome) onwijs traag.
Maar in OSX is Opera vergeleken met Webkit (Chrome) onwijs traag.
Ik gebruik ook Opera op Windows maar het is absoluut niet snel en vloeiend meer. Opera heeft steeds meer moeite met zware sites als Facebook en Google maps. Scrollen gaat extreem haperend en de browser loopt soms half vast met een paar van deze tabs open. Ook het geheugen gebruik zit binnen de kortste keren tegen de 2GB aan.
Ik hoop dat met deze stap Opera weer een beetje bruikbaar wordt.
Ik hoop dat met deze stap Opera weer een beetje bruikbaar wordt.
- Oops, tekst een beetje verkeerd gelezen -
[Reactie gewijzigd door bstudio op woensdag 13 februari 2013 10:49]
Ik vind het een begrijpelijke keuze van Opera, maar jammer op de lange termijn.
Gaan wesites zich conformeren aan standaarden of aan Webkit als dit defacto standaard is?
Concurrentie is positief voor innovatie.
Gaan wesites zich conformeren aan standaarden of aan Webkit als dit defacto standaard is?
Concurrentie is positief voor innovatie.
Nu kan je wegkomen met zeer slecht geprogrammeerde websites zoals http://www.ziggo.nl dan heb je met een web-engine het probleem niet meer.
Chrome wordt officieel niet ondersteund
triest...
https://www.ziggo.nl/#klantenservice/browserondersteuning
triest...
https://www.ziggo.nl/#klantenservice/browserondersteuning
Ik vind dit gewoon triest, word Ziggo gesponsord door Microsoft ?Chrome wordt officieel niet ondersteund
triest...
https://www.ziggo.nl/#klantenservice/browserondersteuning
Volgens mij is IE die positie al kwijt aan Chrome.Internet Explorer 7 en Internet Explorer 8
's Werelds meest gebruikte browser Internet Explorer komt uit de stal van, hoe kan het anders: Microsoft. 'Verhoogde veiligheid, meer gebruikersvriendelijkheid en verbeteringen onder de motorkap' zijn ingebakken in de nieuwste versie van Internet Explorer 8.
Ben het met Athlon-pv eens, de ontwikkelaars van Ziggo zijn gewoon lui geweest.
Aan de ene kant jammer, voelt het net wat minder "Speciaal" door. Maar aan de andere kant, ik gebruik Opera omdat ik het een fijne browser vind en omdat het gewoon goeie features heeft en daarin meestal stilletje voorop loopt. Als ze daar nu nog meer op kunnen focussen dan lijkt mij dat alleen maar beter.
Ben ik het niet mee eens. Nu ze op webkit overstappen hebben ze meer tijd om nieuwe features te maken. Dit zou ze juist kunnen helpen om een groter marktaandeel te kunnen veroveren. Maar dat zullen we dan wel zien.
Hoewel ik Opera nooit gebruikt heb, is het op zich wel fijn dat je hiermee geen Opera-specifieke trucjes meer hoeft toe te passen om je pagina's cross-browser werkend te krijgen. En dat scheelt altijd tijd die je liever in andere dingen steekt.
Het lijkt me voor een browser-maker dan ook wel fijner om je over het renderen van pagina's in elk geval niet druk te maken en je inderdaad alleen maar te hoeven richten op de features die jouw browser uniek maken.
Het enige nadeel dat ik me nu kan bedenken, is dat er straks minder keuze is qua render-engines. Keuzes hebben is altijd wel enigszins fijn.
Het lijkt me voor een browser-maker dan ook wel fijner om je over het renderen van pagina's in elk geval niet druk te maken en je inderdaad alleen maar te hoeven richten op de features die jouw browser uniek maken.
Het enige nadeel dat ik me nu kan bedenken, is dat er straks minder keuze is qua render-engines. Keuzes hebben is altijd wel enigszins fijn.
Naar mijn weten zijn er nooit Opera-specifieke trucjes geweest. Als je de standaarden volgde deed de website het altijd prima in Opera.
Die zijn er wel hoor, maar vaak zijn dat dingen die je niet direct nodig hebt op een normale website. Maar ze hebben eens wat gedaan met camera support, wat andere browsers niet deden bijvoorbeeld.Naar mijn weten zijn er nooit Opera-specifieke trucjes geweest. Als je de standaarden volgde deed de website het altijd prima in Opera.
Jawel hoor, er zijn diverse -o- CSS extensies
Wat volgens mij alleen precies dezelfde extensies zijn waarvoor je ook een -moz-, -webkit- of -ms- prefix voor nodig hebt.
Nee, er zijn er die enkel in Opera met een o-prefix werken. Zaken die nog niet in de andere browsers werken. Maar het gaat inderdaad om weinig gebruikte zaken.
Ik ben benieuwd wat voor opera-specifieke truukjes jij moest uitvoeren dan. Als je firefox en chrome goed had, was er in mijn beleving weinig wat er nog aan opera moest gebeuren.
Overigens gaat Opera zich nog wel druk maken over de renderer:
"Our first patch to WebKit (so for all WK browsers) is to bring CSS multi-col to Presto levels."
Overigens gaat Opera zich nog wel druk maken over de renderer:
"Our first patch to WebKit (so for all WK browsers) is to bring CSS multi-col to Presto levels."
Het is alweer even geleden, maar toen webkit zaken als border radius, box shadow en background gradients ging ondersteunen, zag het er in Opera anders heel anders uit.
Welke Opera-specifieke trucjes heb jij het dan over? Voor zover ik weet werken alle pagina's die ik heb gemaakt gewoon in Opera zolang je je maar aan de standaard houd. Opera heeft zich als een van de weinige browsers hier stug aan vast gehouden.
Het ging me hier alleen om CSS. Ik meen in het verleden (bij mijn oude werkgever) een aantal Opera specifieke CSS rules te hebben gezien, ook in externe libraries die we indertijd gebruikten. Het is overigens niet zo dat ik zelf dergelijke trucjes heb hoeven toepassen. Google heeft in elk geval wel wat hits op Opera-specifieke CSS hacks.
Maar inderdaad, met het volgen van de standaarden kom je een heel eind. Het enige probleem zat/zit hem in de implementatie van die standaarden in de browsers.
Maar inderdaad, met het volgen van de standaarden kom je een heel eind. Het enige probleem zat/zit hem in de implementatie van die standaarden in de browsers.
Afwachten of ik hier nu zo blij mee ben.
Ik vond Opera juist zo fijn omdat hij lekker snel is en eigenlijk een van de meest stabiele browsers is waar ik mee gewerkt heb. Ik hoop niet dat het veranderen van de renderengine hier verandering inbrengt. Webkit is prima, maar in mijn ogen haalt geen enkele webkitbrowser het bij Opera. Hopelijk zorgt deze verandering er niet voor dat Opera meer richting de andere webkitbrowsers gaat.
Ik vond Opera juist zo fijn omdat hij lekker snel is en eigenlijk een van de meest stabiele browsers is waar ik mee gewerkt heb. Ik hoop niet dat het veranderen van de renderengine hier verandering inbrengt. Webkit is prima, maar in mijn ogen haalt geen enkele webkitbrowser het bij Opera. Hopelijk zorgt deze verandering er niet voor dat Opera meer richting de andere webkitbrowsers gaat.
Ik sluit me volledig bij je aan! Ik gebruik Opera al sinds versie 4, juist omdat het zo'n lekker kleine en vooral snelle browser was. Het was indertijd de enige die nog een beetje vooruit te branden was onder Linux op mijn overgeclockte Pentium 1 
Maar ook nu vind ik hem nog steeds een stuk vlotter lopen dan elke keer als ik even achter bijvoorbeeld Firefox zit. En deze performance zal toch het meest gebaseerd zijn op de renderengine, dus wat dat betreft ben ik wel huiverig voor de overstap naar Webkit.
Aan de andere kant, zoals veel mensen hierboven ook al zeggen, maar wat Opera zelf ook al aangeeft; de overstap naar Webkit scheelt een boel development effort, en het is juist misschien daardoor beter dat er meer browsers op een lijn zitten. Wat ik me afvraag is hoe Opera dan nog wel zijn eigen toegevoegde waarde gaat behouden boven de andere browsers. Of zou het misschien zo zijn dat het eigenlijk niet zo goed gaat met Opera (als bedrijf)? En dat het stoppen van de ontwikkeling van Presto en overstap naar Webkit in feite een bezuinigingsmaatregel is?
Maar ook nu vind ik hem nog steeds een stuk vlotter lopen dan elke keer als ik even achter bijvoorbeeld Firefox zit. En deze performance zal toch het meest gebaseerd zijn op de renderengine, dus wat dat betreft ben ik wel huiverig voor de overstap naar Webkit.Aan de andere kant, zoals veel mensen hierboven ook al zeggen, maar wat Opera zelf ook al aangeeft; de overstap naar Webkit scheelt een boel development effort, en het is juist misschien daardoor beter dat er meer browsers op een lijn zitten. Wat ik me afvraag is hoe Opera dan nog wel zijn eigen toegevoegde waarde gaat behouden boven de andere browsers. Of zou het misschien zo zijn dat het eigenlijk niet zo goed gaat met Opera (als bedrijf)? En dat het stoppen van de ontwikkeling van Presto en overstap naar Webkit in feite een bezuinigingsmaatregel is?
Je vergeet wel even Chrome te noemen die ook op Webkit draait en de vloer aanveegt met Opera. Firefox draait trouwens op Gecko.
Ik snap wel dat je een Opera-fan bent, maar het heeft weinig met de engine te maken.
Ik snap wel dat je een Opera-fan bent, maar het heeft weinig met de engine te maken.
Chrome voelt hier anders een stuk trager aan dan Opera. Op m'n (snelle) desktop merk ik dat niet erg, maar op m'n notebook (dat een simpele AMD E2-1800 is) scheelt het toch best veel. Opera lijkt alles wat soepeler te doen. Of hij echt sneller is zou ik moeten meten, maar de ervaring is in elk geval zo dat Opera vlotter aanvoelt.Je vergeet wel even Chrome te noemen die ook op Webkit draait en de vloer aanveegt met Opera. Firefox draait trouwens op Gecko.
Ik snap wel dat je een Opera-fan bent, maar het heeft weinig met de engine te maken.
Op dit item kan niet meer gereageerd worden.
Populair: Tablets Samsung Websites en communities Mobiele telefoons Google Apple Microsoft Sony Games Politiek en recht
© 1998 - 2013 Tweakers.net B.V. Contact Over Tweakers Jouw privacy Algemene voorwaarden Cookies
Tweakers wordt uitgegeven door De Persgroep en wordt gehost door True
