Wor­king Draft

SCREENGUIDE - - Inneres - TExT: Chris­ti­an Schae­fer

Ko­lum­ne: War­ten auf Web Com­po­n­ents

Ich er­in­ne­re mich noch, wie be­ein­druckt ich war, als Googles Alex Rus­sell 2011 auf der Fron­te­ers-Kon­fe­renz das ers­te Mal sei­ne Ide­en des so­ge­nann­ten „Ex­ten­si­ble Web Ma­ni­fes­to” und da­mit der „Web Com­po­n­ents” skiz­zier­te. Das ist nun mehr als fünf Jah­re her, und trotz­dem war­ten wir noch heu­te dar­auf, dass die Brow­s­er­her­stel­ler die „Web Com­po­n­ents” auf die Stra­ße brin­gen. Was ist da los? Noch ein­mal zur Er­in­ne­rung: „Web Com­po­n­ents” ist ein Über­be­griff für im We­sent­li­chen vier ver­schie­de­ne Tech­no­lo­gi­en, die zu­sam­men da­für sor­gen sol­len, dass wir auch mit rei­nen na­ti­ven APIs kom­ple­xe kom­po­nen­ten­ba­sier­te Web­pro­jek­te ent­wi­ckeln kön­nen: • Da wä­ren zu­nächst die „Cust­om Ele­ments”, die es er­mög­li­chen, kom­plett neue HTML-Ele­men­te zu er­sin­nen, sie per Skript­spra­che dem Brow­ser be­kannt zu ma­chen und so­wohl ih­re At­tri­bu­te als auch ihr In­ter­ak­ti­ons­ver­hal­ten zu de­fi­nie­ren. Ähn­lich wie bei Re­act gibt es oben­drauf noch di­ver­se Lifecy­cle-Hooks, um z.B. Event­lis­tener beim „Hoch­fah­ren” zu in­itia­li­sie­ren und sie vor dem Ent­fer­nen des Ele­ments auch wie­der zu de­ak­ti­vie­ren. • Dann gibt es das „Sha­dow DOM”, das als ei­ne Art Do­cu­ment Root für das in­ne­re DOM ei­nes Cust­om Ele­ments fun­giert und das all sei­ne Kind­ele­men­te von der Au­ßen­welt ab­schirmt. Von au­ßen kön­nen dann we­der Skrip­te noch Sty­le­s­heets in die in­ne­re Mecha­nik hin­ein­gu­cken oder hin­ein­pfu­schen. • Da nie­mand Lust hat, gro­ße Men­gen HTML in solch ei­nem „Sha­dow DOM” per Hand, al­so per crea­teE­le­ment(), set­At­tri­bu­te() und ap­pen­dChild(), zu­sam­men­zu­bau­en, gibt es das <tem­pla­te>-Tag für na­ti­ves Tem­pla­ting. Mark­up in­ner­halb des <tem­pla­te>-Tags wird vom Brow­ser igno­riert, kann aber von Skrip­ten auf­ge­grif­fen und ver­ar­bei­tet wer­den. Das Gan­ze ist da­mit zu ver­glei­chen, wie z.B. Hand­le­bars sei­ne Tem­pla­tes in HTML un­ter­bringt. • Und zu gu­ter Letzt gibt es noch die „HTML Im­ports”, die da­zu die­nen sol­len, al­le zu ei­nem Cust­om Ele­ment ge­hö­ren­den De­fi­ni­tio­nen, Skrip­te, Sty­lings und As­sets ex­tern ab­zu­le­gen und sie von dort im­por­tier­bar zu ma­chen. Es han­delt sich da­mit al­so um ei­ne Art Pa­cka­ge-oder De­pen­den­cy-Ma­nage­ment in HTML. Das klingt al­les de­fi­ni­tiv nach ei­ner Technologie, die Web­wor­ker ger­ne ein­set­zen wür­den. Das fan­den üb­ri­gens auch al­le Brow­s­er­her­stel­ler. Aber wo liegt dann das Pro­blem? Wie­so sind die­se Din­ge bei all der Be­geis­te­rung auf al­len Sei­ten nach fünf Jah­ren im­mer noch nicht ein­satz­be­reit? Nun, die Ant­wort ist viel­schich­tig. Haupt­grund dürf­te aber sein, dass Goog­le ziem­lich früh, mut­maß­lich vor lau­ter Be­geis­te­rung und Vor­freu­de, den Feh­ler ge­macht hat, den neu­en Stan­dard nicht zu En­de zu den­ken und ab­zu­stim­men. Statt­des­sen hat das Un­ter­neh­men ihn schon sehr früh in den Chro­me-Brow­ser in­te­griert und zur all­ge­mei­nen Ver­wen­dung frei­ge­schal­tet. Das al­ler­dings stell­te sich bei solch ei­nem kom­ple­xen Ge­werk als Kar­di­nal­feh­ler her­aus, denn es of­fen­bar­ten sich in der Fol­ge im­mer mehr Sze­na­ri­en, an die Goog­le nicht ge­dacht hat­te. Was ehr­lich ge­sagt auch kein Wun­der ist, wenn man sich so tief in Par­ser, DOM und Ren­de­rer ein­klinkt, wie es die Web Com­po­n­ents tun müs­sen.

So kam es, dass be­stimm­te Teil-Tech­no­lo­gi­en nach­träg­lich über­ar­bei­tet wer­den muss­ten und sie nun – ähn­lich wie es über meh­re­re Jah­re hin­weg bei CSS Flexbox pas­siert ist – von ver­schie­de­nen Brow­sern in ver­schie­de­nen Ver­sio­nen un­ter­stützt wer­den. Chro­me un­ter­stützt zum Bei­spiel Cust­om Ele­ments und Sha­dow DOM in den bei­den Ver­si­on 0 und 1, wäh­rend Fi­re­fox der­zeit je­weils nur die äl­te­re Ver­si­on 0 un­ter­stützt, al­ler­dings hin­ter ei­nem Brow­ser-Flag. Der frisch ge­ba­cke­ne Sa­fa­ri 10.1 ist der ers­te Sa­fa­ri, der Web Com­po­n­ents ver­steht. Weil er neu da­bei ist, un­ter­stützt er nur die Ver­si­on 1 der je­wei­li­gen Stan­dards. Und Edge schließ­lich kann nichts von al­le­dem, mit Aus­nah­me des Tem­pla­te-Ele­ments, wel­ches aber auch den tri­vi­als­ten al­ler vier Baustei­ne dar­stellt. Dass Sa­fa­ri und Edge zeit­lich so weit hin­ten­dran sind, liegt schlicht an Ka­pa­zi­täts­eng­päs­sen in bei­den Teams in den ver­gan­ge­nen Jah­ren. Das Sa­fa­ri-Team war per­so­nell nicht be­son­ders gut für die Um­set­zung neu­er Web-APIs ge­rüs­tet und kon­zen­trier­te sich lie­ber auf Ren­de­ring-Fea­tu­res und Ja­vaS­cript-Com­pi­lerPer­for­mance, in de­nen sie kaum zu schla­gen wa­ren. Das wan­delt sich nun lang­sam, und so wer­den in mehr und mehr Brow­ser APIs im­ple­men­tiert oder ge­ra­de ge­zo­gen (z.B. In­de­xe­dDB). Das Edge-Team war sei­ner­seits da­mit be­schäf­tigt, den In­ter­net Ex­plo­rer kom­plett zu ent­ker­nen und ihn in den neu­en, zu­kunfts­fä­hi­gen Edge-Brow­ser um­zu­bau­en. Das hat mäch­tig viel Zeit und Res­sour­cen ge­kos­tet, die nicht in die Web Com­po­n­ents flie­ßen konn­ten. Au­ßer­dem lie­fer­te der Um­bau auch die neue tech­ni­sche Ba­sis, auf der die Web Com­po­n­ents über­haupt auf­set­zen konn­ten. Auch die­se Zei­ten sind nun vor­bei, und so sit­zen bei­de Teams nun­mehr mit Hoch­druck an ih­ren Im­ple­men­ta­tio­nen der „Web Com­po­n­ents”. Googles Al­lein­gang hat das Pro­jekt aber nicht nur in sei­ner so­li­den Aus­ar­bei­tung zu­rück­ge­wor­fen, man hat zu­dem auch das Mo­zil­la-Team mäch­tig vor den Kopf ge­sto­ßen. Je­nes wä­re si­cher­lich schnel­ler mit­ge­zo­gen, wenn es in der Pla­nung be­rück­sich­tigt wor­den wä­re. Ei­ne Sa­che, die Mo­zil­la z.B. am Her­zen lag, war ei­ne Har­mo­ni­sie­rung der „Web Com­po­nent”-Mecha­ni­ken mit neu­en Ent­wick­lun­gen im Ja­vaS­cript-Be­reich (da­mals ES6). So hät­ten sie es ger­ne ge­se­hen, wenn manch neue API sich an die neue ES6-Klas­sen­syn­tax an­ge­lehnt hät­te (was mitt­ler­wei­le ge­sche­hen ist). Des Wei­te­ren be­zwei­fel­te und be­zwei­felt Mo­zil­la auch heu­te noch die Not­wen­dig­keit ei­nes „HTML Im­ports”-Stan­dards, wenn doch im Rah­men des nächs­ten Ja­vaS­cripts ge­ra­de ver­gleich­ba­re, so­ge­nann­te Mo­du­le-Loa­der in der Ma­che sind, die oben­drein auch noch uni­ver­sel­ler funk­tio­nie­ren. Statt­des­sen hat­te Mo­zil­la al­so sei­nen Bei­trag zur Ent­wick­lung erst ein­mal zu­rück­ge­schraubt und ist des­halb bei Ver­si­on 0 von Cust­om Ele­ments und Sha­dow DOM ste­hen ge­blie­ben. Mitt­ler­wei­le ist es aber so, dass Goog­le sei­ne Lek­ti­on ge­lernt und die Feh­ler kor­ri­giert hat. Auch die zwi­schen­mensch­li­chen. Da­mit ist al­so das Mo­zil­la-Team wie­der an Bord und ar­bei­tet jetzt an der Im­ple­men­ta­ti­on der Ver­si­on 1 der oben ge­nann­ten APIs in den Fi­re­fox. Ein­zig bei dem The­ma „HTML Im­ports” bleibt das Mo­zil­la-Team ab­war­tend, was ich ehr­lich ge­sagt auch gar nicht so ver­kehrt fin­de. Rück­bli­ckend muss man sa­gen, dass die Goog­le-Mann­schaft ih­re ei­ge­ne Cle­ver­ness und Markt­macht da­mals ein­fach zu sehr über­schätzt und dem Pro­jekt da­mit letzt­end­lich mehr ge­scha­det als ge­nützt hat. Auch wä­re es si­cher­lich gut ge­we­sen, wenn Goog­le sei­ne „Web Com­po­n­ents” nicht so sehr in der Öf­fent­lich­keit be­wor­ben hät­te, wie es in den letz­ten Jah­ren der Fall ge­we­sen ist (ins­be­son­de­re über das Web Com­po­nent Frame­work Po­ly­mer). Mo­zil­la macht vor, wie es rich­tig geht: Dort bleibt man in vie­len Be­rei­chen am Ball, hält sich bis zur Fer­tig­stel­lung je­doch vor­nehm zu­rück und ver­steckt neue Tech­no­lo­gi­en lie­ber hin­ter Brow­ser-Flags, um nicht aus Ver­se­hen Fak­ten zu schaf­fen, die man spä­ter nicht mehr aus der Welt be­kommt. Bei all den Feh­lern der Ver­gan­gen­heit muss man aber auch klar fest­stel­len, dass die „Web Com­po­n­ents” de­fi­ni­tiv nicht tot sind und sie mit Si­cher­heit kom­men wer­den. Es wird nur wohl noch zwei, drei Jah­re dau­ern, bis es so weit ist – aber sie wer­den dann bes­ser funk­tio­nie­ren denn je. Und dar­auf freue ich mich im­mer noch so sehr wie vor fünf Jah­ren!

Das Wor­king Draft Team be­steht aus ei­nem hal­ben Dut­zend Front­end-Ent­wick­lern aus Ös­ter­reich und Deutsch­land und pod­cas­tet wö­chent­lich un­ter working­draft.de über die neu­es­ten Trends und Tech­no­lo­gi­en in der Webentwicklung. Dies­mal schrieb für Sie: Chris­ti­an Schae­fer. Twit­ter: @working­draft / @derSchepp Kom­men­tie­ren: screen­gui.de/34/working­draft

Abb. 1: Im­ple­men­ta­ti­ons­sta­tus der ver­schie­de­nen Brow­ser

Abb. 2: Googles Po­ly­mer Frame­work setzt auf Web Com­po­n­ents

Newspapers in German

Newspapers from Germany

© PressReader. All rights reserved.