Alles weten over Web Components? Meld je nu aan voor de ING Live-webinar

ING, voor velen nog altijd in eerste plaats een bank, is steeds meer een it-bedrijf dat in de financiële sector werkzaam is. Nieuwe front-endtechnieken zijn bepalend voor het gebruiksgemak van miljoenen klanten en Web Components spelen hierbij een belangrijke rol. Daarover kun je binnenkort meer te weten komen in de Engelstalige webinar met ING’s front-enddevelopers.

ING Live-webinar

Meld je aan

Het belang van (de kennis over en de toepassingen van) Web Components wordt uitvoerig besproken tijdens de tweede editie van het ING Live webinar, georganiseerd door Tweakers en ING. Hierin geven ING-ers technologylead front-end Bob Bijvoet en senior front-end developer Lars den Bakker je een kijkje in de keuken. Ze nemen je mee in de developmentworkflow en architectuur van webdevelopment bij ING. Beiden laten bovendien zien hoe ING in staat is om front-endfeatures internationaal te schalen en configureren. Dit wordt in live coding gedemonstreerd, wat het interactieve karakter van de webinar onderstreept.

De werkzaamheden en daarmee de rollen van front-enddevelopers zijn in de afgelopen jaren flink veranderd. Front-endontwikkelaars worden steeds vaker gezien als sleutelfiguren in een ontwikkelteam. Web Components spelen hierbij een bepalende rol. Niet zo vreemd dat de vraag naar front-enddevelopers zo groot is. Nadat je eerder dit jaar de webinar over machinelearing met ING's datascientists kon volgen, is het daarom binnenkort de beurt aan een webinar over Web Components.

Aanmelden

Wil jij interactief je kennis van Web Components vergroten? Meld je dan nu aan via onderstaande aanmeldbutton. De webinar zelf wordt niet live uitgezonden op Tweakers, je kunt hem enkel volgen als je je hebt aangemeld.

Datum en tijd: donderdag 5 september, van 20.00 tot ongeveer 21.00 uur.

Meld je aan

Data
De data van de aanmeldingen worden niet met Tweakers gedeeld, maar komt alleen ter beschikking van Crowdale om de deelnemers een e-mail te kunnen sturen met een bevestiging van de aanmelding, een reminder-e-mail over de webinar, en een e-mail wanneer de live webinar van start gaat. Na de webinar wordt een anonieme enquête verstuurd om jullie bevindingen te horen, en zo de kwaliteit van de webinar te kunnen waarborgen en verbeteren. De gegevens worden 30 dagen bewaard.

Dit artikel is geen redactioneel artikel, maar een advertorial. Mocht je ideeën met ons willen delen over deze vorm van adverteren, dan horen wij dat graag. Hierover kun je met ons in gesprek via [Discussie] Reclame algemeen, daar zullen collega's aanwezig zijn om jouw vragen en/of opmerkingen te bespreken/beantwoorden.

Reacties (68)

[svenk91]

Al ben je waarschijnlijk niet de doelgroep als je eerst moet googlen wat web components zijn, hier toch wat uitleg:

Web components are a set of web platform APIs that allow you to create new custom, reusable, encapsulated HTML tags to use in web pages and web apps. Custom components and widgets build on the Web Component standards, will work across modern browsers, and can be used with any JavaScript library or framework that works with HTML.

Web components are based on existing web standards. Features to support web components are currently being added to the HTML and DOM specs, letting web developers easily extend HTML with new elements with encapsulated styling and custom behavior.

https://www.webcomponents.org/introduction

In het kort: Je kan dus nieuwe/eigen tags gebruiken in HTML en een javascript file importeren die je browser zegt wat die browser met die tag moet doen qua interpretatie. Mits ik het goed begrijp

[Reactie gewijzigd door svenk91 op 23 juli 2024 06:34]

[Roland p]

Eigenlijk als xsl maar dan wat dynamischer.
Werkt dit al onder iedere browser zonder polyfills?

[R4gnax]

Eigenlijk als xsl maar dan wat dynamischer.
Werkt dit al onder iedere browser zonder polyfills?

Nee. Je hebt gelijk een bult aan extra JavaScript polyfills varierend tussen de 0.5 ~ 2 MB nodig.
Waarom het ook zo lachwekkend is als je weer met een partij te maken hebt die luidkeels roept dat je het nu al kunt gebruiken.

Ja; technisch correct. Als je het niet erg vindt om een deel van je bezoek op te zadelen met een bult extra zooi om te downloaden; parsen en uitvoeren, voordat het allemaal werkt.

[Sicco2]

Nou, je hebt gelijk dat je polyfills nodig hebt. Maar je hebt denk ik wat ontwikkeling gemist.

Hier staan alle polyfill bundles die je nodig hebt:
https://unpkg.com/browse/...ponentsjs@2.2.10/bundles/
Met feature detectie pack een browser enkel wat hij nodig heeft.
Dus voor de meest gangbare browsers ws zo'n 100kb unzipped (blijft erg weinig van over, 50% van de files zijn comments.

En je gaat dit niet doen op een app van 5kb uiteraard. Maar voor grote applicaties, die clients vaak gebruiken heeft dit zeker zin. Je maakt een losse vendor bundle met de polyfills en deze kan de client fijn cachen. Dus je haalt m ook nog eens bijna nooit binnen.

Lachwekkend is het dus zeker niet. Wees blij dat een grote partij als ING deze stap al neemt en zorg dat WebComponents meer en meer gebruikt worden (en ons op termijn van de js-framework oorlog afhelpen misschien)

[R4gnax]

Nou, je hebt gelijk dat je polyfills nodig hebt. Maar je hebt denk ik wat ontwikkeling gemist.

Hier staan alle polyfill bundles die je nodig hebt:
https://unpkg.com/browse/...ponentsjs@2.2.10/bundles/
Met feature detectie pack een browser enkel wat hij nodig heeft.
Dus voor de meest gangbare browsers ws zo'n 100kb unzipped (blijft erg weinig van over, 50% van de files zijn comments.

De 111KB is de volle bundle met alle polyfills geminificeerd, dus het lijkt inderdaad tegenwoordig aardig meer ingebonden qua grootte. Zie alleen dat de website zelf nog steeds een ongeldig certificaat draagt, dus heel veel leesmateriaal om in te halen heb ik niet. (Dat probleem bestaat al een jaar of zo. Zou Google wel eens op mogen lossen. Tjee...)

[Verwijderd]

je hebt ook 5 MB aan local storage beschikbaar, spul daar neer zetten, daarna dus van je lokale computer, laadbalkje bij de eerste keer en gaan bij die revisits

[R4gnax]

je hebt ook 5 MB aan local storage beschikbaar, spul daar neer zetten, daarna dus van je lokale computer, laadbalkje bij de eerste keer en gaan bij die revisits

Het probleem met MBs aan JS is jammergenoeg niet alleen de download footprint.
Het parsen en uitvoeren telt - zeker op mobile devices met minder krachtige processoren - ook sterk mee.

[Carino]

Polyfills opslaan in LocalStorage??!
Dus we gaan het complete cache mechanisme van de browser omzeilen en een eigen mechanisme maken wat ook nog eens niet te vertrouwen is...

Goed idee! /sarcasme

[Verwijderd]

ik heb niet getest wat sneller is, cache kan ook, maar niet iedereen heeft cache aanstaan, dus wat is je punt

[Carino]

LocalStorage kan je niet vertrouwen, zeker niet als je vervolgens blind de code die erin staat inlaad en door de browser laat uitvoeren...

LocalStorage kan aangepast zijn zonder dat je dat weet en daar kom je dan pas achter als het uitgevoerd wordt.

Er zijn voor zover ik weet twee manieren: via JavaScript een script object toevoegen aan de dom en daar de code in knallen of via eval... eval=evil! (Ja, ook de jquery variant)

[Verwijderd]

Ik dacht dat ie domein specifiek was, dus de beheerder van het domein bepaalt de waarde. per domein, vervolgens per subdomein is er 5 MB local storage beschikbaar, heb al een keer php erin gezet op een local domijn, maarja dan moet je de standaard waarde van 5MB verhogen, dan kun je templates bijvoorbeeld locaal genereren. daarnaast is caching vaak wel de oplossing voor de javascript, had er ff niet aangedacht (de cache) maarja dat is ook server specifiek geconfigureerd. daarnaast kan je javascript sowieso niet vertrouwen, een methode kan worden overschreven, iets wat bij php bijvoorbeeld niet mag.

[Carino]

Dat klopt, maar het gaat erom dat de LocalStorage in feite door de gebruiker (of iets wat zich voordoet als gebruiker) aangepast kan worden.

Het resultaat is dat je, indien je het script door de browser laat uitvoeren, niet kan vertrouwen dat het script klopt. Je zou dat kunnen omzeilen door een checksum te doen, maar ook dan kunnen er trucjes toegepast worden om zaken te verstoppen...

Heel kort door de bocht: vertrouw niet blind gegevens die door een gebruiker (elk soort) opgegeven kan worden.

Edit: je laatste alinea klopt als een bus. Daarom kan je beter niet een compleet script in je LocalStorage plaatsen want als ‘ie eenmaal tainted is blijft ‘ie dat ook. Als je het script ophaalt van de server weet je zeker dat ‘ie op dat moment klopt.

[Reactie gewijzigd door Carino op 23 juli 2024 06:34]

[Verwijderd]

Browser fs is een mooie techniek, 500 mb van maken en php/ node installeren, kun je templates lokaal genereren met data van de server. Daar is local storage voor...

[RoestVrijStaal]

Werkt dit al onder iedere browser zonder polyfills?

Nee, het is een Google/Mozilla feestje.

Overigens is het maar de vraag of je het echt nodig hebt. 99% van de gevallen kun jij je probleem op een andere manier met al bestaande standaarden oplossen.

[R4gnax]

[...]
Nee, het is een Google/Mozilla feestje.

Het idee er achter dateert echter nog veel en veel verder terug. Microsoft pioneerde er al mee in IE 4 waar het concept leefde in de vorm van HyperText Components. Ja; de beruchte .htc bestanden waar iedereen dood en verdoemenis over riep.

Hoe ironisch dat het ineens wel hip; cool; aaibaar en adopteerbaar wordt zodra Google hetzelfde ding introduceert.

[OxWax]

Ik begrijp elk woord, ben geen leek en toch begrijp ik niet echt wat er speciaal aan is.
Ergens voorbeelden te vinden?

[Ereaser]

Je kunt zo makkelijk veel gebruikte stukken HTML + bijhorende logica 1x defineren en dan hergebruiken.

Neem als voorbeeld een datepicker die uiteindelijk alleen nog maar een date oplevert en de rest van de layout en logica zit in het component.

[Reactie gewijzigd door Ereaser op 23 juli 2024 06:34]

[batjes]

Soort Smarty dus aan de HTML kant?

[Devilscomrade]

Als je bv een input element plaatst met type file krijg je standaard styling van je browser op het element, denk aan drop zone en button etc.

Met dit kan je dus bv een <mijn-super-file-input> maken die je dus 1 keer definieert en dan overal in je applicatie / website kan gebruiken met de styling en functionaliteit naar keuze. Je kan zelfs dus attributes verzinnen en het component heel dynamisch maken, zoals wel of niet dragndrop of wel media, geen files etc.

Natuurlijk hangt er nog meer omheen zoals het kunnen afschermen van CSS en dergelijken die de herbruikbaarheid vergroten, maar de basis is al interessant genoeg.

[HollowGamer]

Jammer dat ik naar een externe site moet, heb liever gewoon een directe link naar de stream. Kunnen jullie het niet gewoon doorstreamen?

Ik doe nu 2 jaar iets met Vue, komt dit op hetzelfde neer?

Ben wel benieuwd overigens.

[Ed Vertijsment]

Ik doe nu 2 jaar iets met Vue, komt dit op hetzelfde neer?

Ja, en nee.

De overeenkomst is het gedachtengoed van het opsplitsen in verschillende (herbruikbare) componenten en het scopen van logica ervan.

Libraries als Vue en React gaan verder door oplossingen voor o.a. updates en state management en zijn bovendien vendor specifiek, waar web componenten op standaarden berusten en in principe zonder dependencies kunnen werken.

[418O2]

Je kan tegenwoordig wel vue componenten als Web Components bouwen. Ik heb toevallig net een Vue-applicatie uitgerold die als web-component kan worden geintegreerd door derde partijen als alternatief voor iframes. Werkt erg snel & prettig!

[Ed Vertijsment]

Het feit dat je dingen los kan shippen en plaatsen is inderdaad zeer nuttig. Overigens bepert niet je om gewoon random code te wrappen in een webcomponent en het trucje zelf te doen. Dat Vue dit kennelijk voor je kan is enkel (nuttige) automatisering.

[HollowGamer]

Maar wat is dan precies het voordeel van webcomponents enkel dat het werkt zonder een Vue/React lib? Ik neem aan dat je beide nog altijd moet omzetten zodat de browser snapt wat je bedoelt, of is dat met deze techniek niet nodig?

Het is mij nog niet heel duidelijk, maar waarom zou je dit kiezen, zeker als je verder noemt van state/update management wat wel degelijk belangrijk is.

[Reactie gewijzigd door HollowGamer op 23 juli 2024 06:34]

[watercoolertje]

Nee dit hoef je dus niet te compilen, leukste hieraan is dat die componenten ook gewoon gebruikt kunnen worden in de genoemde frameworks, vue weet het verschil niet tussen <input> en <custom-input>, dit zorgt dus dat je dezelfde componenten ook in meerdere frameworks kan gebruiken, als vue over 5 jaar ingehaald is door iets anders dan kan je die componenten daar ook gewoon weer gebruiken.

[R4gnax]

Nee dit hoef je dus niet te compilen, leukste hieraan is dat die componenten ook gewoon gebruikt kunnen worden in de genoemde frameworks, vue weet het verschil niet tussen <input> en <custom-input>, dit zorgt dus dat je dezelfde componenten ook in meerdere frameworks kan gebruiken, als vue over 5 jaar ingehaald is door iets anders dan kan je die componenten daar ook gewoon weer gebruiken.

Deze componenten encapsuleren daarentegen enkel simpele logica en bevatten geen state management, reactive data modeling, etc. Dat moet je allemaal zelf nog toevoegen. En complexiteit in UI interacties afhandelen, dat kan heel; heel snel stijgen.

Daarnaast heb je sowieso al tussen de 0.5 en 2 MB aan JavaScript polyfills nodig om Web Components volledig werkend te hebben in alle huidige browsers.

Ik zie persoonlijk meer heil in frameworks die hun eigen APIs voor reactive data, state modeling, etc. aanhouden, maar die naar de toekomst kijkende hun view/component handling richting compatibility met Web Components schuiven zodat je op een nog niet nader gespecifieerd moment makkelijker over kunt.

[Reactie gewijzigd door R4gnax op 23 juli 2024 06:34]

[watercoolertje]

Deze componenten encapsuleren daarentegen enkel simpele logica en bevatten geen state management, reactive data modeling, etc. Dat moet je allemaal zelf nog toevoegen. En complexiteit in UI interacties afhandelen, dat kan heel; heel snel stijgen.

Klopt maar die afhandeling wil je juist wel binnen je app (framework x) doen net zoals je met de al bestaande html componenten ook doet dus.

Daarnaast heb je sowieso al tussen de 0.5 en 2 MB aan JavaScript polyfills nodig om Web Components volledig werkend te hebben in alle huidige browsers.

Ja nu misschien nog wel, maar wat is precies de issue? Het is relatief nieuw en adoptie kost gewoon even tijd, moeten we het daarom links laten liggen?

Ik zie persoonlijk meer heil in frameworks die hun eigen APIs voor reactive data, state modeling, etc. aanhouden, maar die naar de toekomst kijkende hun view/component handling richting compatibility met Web Components schuiven zodat je op een nog niet nader gespecifieerd moment makkelijker over kunt.

Dat zullen ze allemaal wel doen, met vue kan je ook web components maken ondertussen.

[Devilscomrade]

Inderdaad, als je met vanilla web components wil spelen raad ik lit elements aan. (Google)

[aex351]

ING, voor velen nog altijd in eerste plaats een bank, is steeds meer een it-bedrijf dat in de financiële sector werkzaam is.

ING impliceert hiermee IT bedrijf te zijn. Maar de werkelijkheid is natuurlijk precies hoe velen het zien. ING is vooralsnog een bank dat IT toepast. Iemand met een business rol krijgt naar verhouding meer betaald dan iemand met een IT rol (wat zich ook weer vertaald naar het gegeven dat het bulk van het IT personeel uit het buitenland gerecruit wordt). Het bulk van het werk wordt uitbesteed aan derden of wordt uitgevoerd in goedkope landen, dit met als idee dat het wordt aangestuurd door iemand die een business rol heeft. Noemen we dit een IT bedrijf of een bank dat IT toepast?

[Aidix]

Volgens mij leef jij in een andere realiteit dan de ING medewerkers. Er wordt veel in house gedaan, en de mensen krijgen zeer goed betaald. De functieschaalindeling van IT is niet anders dan die van business, die mensen zitten ook op dezelfde verdieping van het pand. In beide gevallen eten ze brood met een dikke laag roomboter. Of iemand uit India komt of uit NL boeit niet voor het salaris, als hij bij INGNL intern in dienst is krijgt hij hetzelfde. Als hij een 30% regeling heeft zelfs netto meer.

[Reactie gewijzigd door Aidix op 23 juli 2024 06:34]

[aex351]

De functieschaalindeling is wel degelijk anders. Een engineer zit structureel een schaal lager dan bijvoorbeeld een customer journey expert. Het is ook niet voor niets dat ING mensen direct uit lagelonen landen recruit. Dat is echt niet omdat er te weinig Nederlanders zijn die het werk kunnen doen hoor. In elk geval met een uitbesteding van meer dan 50% van het werk aan derden. Kan je jezelf naar mijn inzicht geen IT bedrijf noemen.

[Stringer]

Jullie zitten dicht bij het vuur qua terminologie zo te horen. Nieuwe IT'ers bij dit bedrijf worden tegenwoordig minstens evenveel betaald als hun business collega's, die in hetzelfde team werken (scrum). Soms (veel) minder en soms (veel) meer (hangt af van de ervaring, kennis, kunde etc).

De schaal discussie is niet zo interessant; de schaal bepaalt niet perse het salaris, aangezien 2 schalen elkaar ruimschoots overlappen. Bij als zoveel bedrijven. Dus die discussie hoeft echt niet gevoerd te worden.

Dat ING alsnog voor bepaald IT werk uitwijkt naar lage lonen landen (de Filipijnen bijvoorbeeld) staat is echter ook waar. En dat vind ik ondoorzichtiger. Hoe is de beloning daar? En de kwaliteit van het werk? Enfin, voer voor een ander topic.

On topic: leuk initiatief, interessant om te volgen denk ik.

[Reactie gewijzigd door Stringer op 23 juli 2024 06:34]

[aex351]

De schaal is wel relevant want dit bepaald tot op een zekere hoogte je startpunt. Dat schalen overlappend zijn is leuk en aardig. Maar tegen de tijd dat je op het overlappende gedeelte bent ben je alweer een aantal jaar verder.

[Stringer]

Daar doe je een aanname dat je startpunt het begin van de schaal is. Er worden dikwijls mensen aangenomen met een salaris in schaal X, waarbij het salaris in schaal X +1 ligt. Sterker, nog dat is vrij gebruikelijk.

Tenzij je er van overtuigd bent dat men over de linie een schaal achter ligt, maar dan vraag ik mij af waar jij je informatie vandaan haalt

Volgens mij is dit bedrijf zo groot, dat er discrepanties zijn in de bedrijfsvoering. Op één plek werkt men full blown 'hip' Agile en gaat alles met duur betaalde Nederlandse en buitenlandse arbeidskrachten, IT én business. Waarbij we het hebben over buitenlandse werknemers in Nederland. Wel eens in Amstelveen geweest? Of moet ik zeggen Mumbai aan de Amstel . Als je denkt dat die voor een appel en een ei hier werken, dan heb je het aardig mis.

Aan de andere kant heb je de zware back-end legacy, het vervangen van de mainframes en decommen van oude meuk waarbij nog steeds veel op de waterval methode gaat, met zo goedkope mogelijke offshore krachten. Er bestaat dan nog wel zoiets als offshore 'visie' vanuit de directie, maar
een enkele afdeling of een enkel project kan prima autonoom besluiten om het via A, B of C te doen. Enfin, te groot om te generaliseren dat IT minder betaald wordt in ieder geval.

[Reactie gewijzigd door Stringer op 23 juli 2024 06:34]

[aex351]

De schaal vertegenwoordigt het gewicht van de functie. Dat iemand intreed in een hogere trede is irrelevant. Want datzelfde kan gezegd worden van iemand die wel in een hogere schaal begint.

[ryderb]

Waar baseer je dit op? Kan je uit eigen ervaring vertellen dat het exact omgekeerd is, een CJE zit met dezelfde titel (ervaring) een schaal lager dan engineers.

[aex351]

Ik baseer dit op hoe de situatie daadwerkelijk is bij ING NL. Werk wordt aangestuurd vanuit iemand met een business rol, veelal een Nederlander. En iemand met een interne IT rol is al snel buitenlands. Zie eerdere reactie, om kosten te drukken. Dit staat los van de uitgesproken ambitie om een IT bedrijf te worden. Maar ze zijn het niet. Je ziet nu zelfs weer een verschuiving om alles te offshoren terwijl een aantal jaar geleden ze binnen een enkele afdeling juist veel meer personeel wilden aantrekken. Maar dat is dus een enkele afdeling.

[StrikerOwner]

Ingeschreven! Zelf ook wel eens mee bezig geweest. Ik ben wel benieuwd welke use-cases ze hier voor hebben gevonden , sinds vele devs (na mijn idee) toch wel met een framework bezig zijn.

[OddTech]

Er zijn inderdaad frameworks zat die al een hoop voor je doen. Als nog moet je soms een bepaalde structuur opzetten met aantal elementen. Is het niet makkerlijk om een one-liner te typen die een button maakt en je icon er direct in zet. Er zijn al verschillende webcomponenten voor frameworks.

Neem bijvoorbeeld:

• https://vaadin.com/components
• https://github.com/morbidick/bootstrap-webcomponents

[ddt15]

Ik snap niet wat dit doet of beter doet dan wat al bestond.

[418O2]

Dan raadt ik je aan dit even te lezen.

https://web.dev/web-components-io-2019/

Als je het dan nog niet in ziet dan zal het wel nooit komen

[yade]

Ben ik de enige die WebComponents een ontiegelijk slecht idee vind? Straks zie je dus tags die overal een andere betekenis kunnen hebben. Diegene die dit bedacht heeft moet echt een hekel hebben aan web developers.

Ok, ik zie net dat de tags zijn te onderscheiden van reguliere tags omdat er een koppelteken gebruikt moet worden, maar dan nog.

[Reactie gewijzigd door yade op 23 juli 2024 06:34]

[Ed Vertijsment]

Meh, wat is er nou principe anders dan nu wat dat betreft? Via web components kun je gewoon:

<ui-datagrid />

gebruiken in plaats van

(pseudo maar you get get the point).
<aside class="datagrid">
<form class="datagrid__filter">
<input class="datagrid__search" />
</form>
<table class="datagrid__table"></table>
<nav class="datagrid__paginator"></nav>
</aside>

Bij zijn zo specifiek dat ze niet zomaar ergens anders te gebruiken zijn. Web components stellen je echter in staat om alles op 1 manier (en plek) te kunnen definieren en het makkelijker te kunnen hergebruiken en delen.

Dat gezegd hebbende gebruik ik het zelf niet maar gebruik ik vaak React componenten of vanilla HTML indien dat volstaat. Maar het is wel een mooie techniek.

[siteoptimo]

Het is maakt het semantisch een pak onduidelijker. Bij je voorbeeld weet je tenminste dat er een form in staat en wat je kan verwachten.

Html is niet de plek waar je imo zoiets moet willen doorvoeren. Ik zie zo al complexe projecten nog moeilijker worden vanaf je met een team samen werkt.

Je codevoorbeeld heb je bovendien door de vele classes ook onnodig complex gemaakt.

[Castor385]

Het is juist de bedoeling dat het samenwerken makkelijker maakt. Zo kan iemand bijvoorbeeld een date picker maken

<date-picker></date-picker>

Wat anderen dan weer kunnen hergebruiken zonder het iedere keer opnieuw te maken.

[siteoptimo]

Klinkt toch als een hel als iedereen zelf kan/mag bepalen wat die naamgeving is?
Dit voelt aan als het begin van <datepicker-new> en <datepicker-alternate> en <datepicker-final>.

Ik ben all-in voor componenten, maar niet in HTML met custom eigen gekozen naamgeving.

[BarôZZa]

Dat heb je toch ook met classes, id's, NPM packages, entities en eigenlijk alles waar mensen het beestje zelf een naam mogen geven?

Bekijk bijvoorbeeld eens hoeveel html-code er achter elke comment hier zit, plus alle javascript die erop inhaakt. Stel je dan voor dat je het vervangt met:

<tweakers-comment comment-id="555" user="siteoptimo" user-id="123" avatar="siteoptimo.jpg" time="2019-08-02 14:55" rating="2">
Mooie comment tekst
</tweakers-comment>

En de web-component zorgt ervoor dat alles prima wordt gerenderd, met quote buttons etc en een standaard styling zodat je niet bang hoeft te zijn dat je een classname gebruikt waar al CSS regels voor staan.

Een ander scenario is bijvoorbeeld: stel je wil een code editor tekstveld op je site hebben met syntax highlighting etc. Dan kan je allemaal javascript erop knallen, of je installeert een web-component en doet:
<code-editor language="javascript">
alert('hoi');
</code-editor>

Als je het op de juiste manier gebruikt wordt het juist veel overzichtelijker. Het dwingt je ook om te denken in herbruikbare componenten in plaats van dat je zaken steeds op een net wat andere manier worden opgelost.

[Ed Vertijsment]

Het is maakt het semantisch een pak onduidelijker. Bij je voorbeeld weet je tenminste dat er een form in staat en wat je kan verwachten.

Maar weet je bij een <video> tag ook wat je kan verwachten? En maakt dat uit? Technisch gezien is dit namelijk veelaal geimplementeerd als webcomponent (bijvoorbeeld in Chrome). Wat je verwacht is een video player. Het is niet belangrijk hoe de slider is geïmplementeerd, tenzij je aan de player zelf werkt.

Overigens kun je prima de HTML structuur van een webcomponent inzien in de insepector, Je styling is echter afgezonderd door een eigen scope waardoor je niet bang hoeft te zijn dat de play button styling de boel in je menu vernaggeld. Wat me op het volgende brengt:

Je codevoorbeeld heb je bovendien door de vele classes ook onnodig complex gemaakt.

Zonder afgezonderde scope zijn IMO classes de veiligste manier om styling te definieren:

- Tagnamen kunnen veranderen en moeten kunnen elkaar makkelijk beinvloeden.
- ID's zijn niet herbruikbaar.

Daarnaast vind ik die complexiteit van een class wel meevallen, gewoon een descriptive name waar een tagnaam niet in volstaat (er is namelijk niet echt een tag voor datagrid, en wie zegt dat het een aside moet zijn?).

Html is niet de plek waar je imo zoiets moet willen doorvoeren. Ik zie zo al complexe projecten nog moeilijker worden vanaf je met een team samen werkt.

Dat hangt er natuurlijk helemaal van af hoe je codebase is opgedeeld. Intern kan je natuurlijk gewoon in de broncode van het webcomponent kijken en zien dat er een form in zit, en hoef je ook geen classes te definieren (al zal ik dat nog steeds doen) omdat de styling veel beter gescoped is.

Dat (frontend) code niet complex moet zijn is een mooie droom maar de realiteit is anders. We leven niet meer 1995 en UI's zijn veel complexer geworden, of dat moet is een andere discussie maar om het werkbaar te houden wordt code nou eenmaal opgesplitst. Web component zijn slechts een vorm om dat te doen. De veel kleinere scope maakt het niet per definitie minder complex maar zet wel een grens om de impact van die complexiteit wat de kans op bugs zeer sterk verkleint, iets waar we nu lapmiddelen (zoals BEM naming conventies) voor nodig hebben.

Overigens moeten we stoppen met het benaderen van websites als pagina's maar als een verzameling blokken (componenten, hoe dan ook geimplementeerd). Als het echt zo complex is ga je als team aan een component werken, niet aan een pagina. Omdat je, je dan enkel hoeft te focussen op de code in dat component en niet dat van de buurman hoef je al rekening te houden met een stuk minder complexiteit.

[Reactie gewijzigd door Ed Vertijsment op 23 juli 2024 06:34]

[siteoptimo]

We maken de comments onnodig lang als ik op alle punten in ga, maar wat styling betreft kan je perfect een class op het hoofdelement zetten om vervolgens die te gebruiken om subelementen te targetten.

Van een video tag verwacht ik...een video. De manier waarop maakt niet uit, maar je weet tenminste dat er een video staat. Heb je niet bij custom elementen die niet een goede naamgeving kregen. Hier draait het uiteindelijk om voor mij.

Ik ben pro componenten en component libraries in general, maar raken aan de naamgeving van HTML tags gaat mij te ver voor wat "simpeler" te kunnen targeten qua styling. Sinds 1995 zijn de mogelijkheden dan ook voldoende aangepast (zie oa css grid, flexbox,...).
Daarvoor heb je geen custom naamgeving html-elementen voor nodig. Ik hecht gewoon (te?) veel belang aan semantiek en scheiding tussen styling en code. Dit wordt een fragmentatie.
Web Components voelt aan als een ongemakkelijke in-between, voor mij vergelijkbaar met de vele generic TLD's. Geen meerwaarde, enkel verwarring zaaiend.

[Ed Vertijsment]

Ik houd het ook ff kort want onderweg, maar qua semantiek zie ik veel meer in een beschrijvend custom element (met daarin gewoon structurele tags zoals h1/2/3 etc.) dan een nietszeggende div. Ik zie het dan ook meer als wrapper voor een subdeel van de applicatie (laten we alsjeblieft geen vervangers voor built-ins maken).

Qua CSS targetting houd ik ervan alles op 1 manier te doen, wel zo voorspelbaar. En op tag is gewoon een no-go voor mij, veel te strikte koppeling tussen betekenis en vormgeving. Als een h1 een h2 moet worden wil ik immers niet dat zomaar de lay-out overhoop gaat.

De naamgeving is natuurlijk aan de developer, dat is niet anders dan een andere module, component of bibliotheek, lijkt me dus niet echt een discussie.

Het is zeker niet zo dat geen nadelen zijn, die zijn er en vors ook. Zo is afhankelijkheid van JS om het te renderen een blocker voor mij, maar dat maakt het idee niet automatisch slecht of semantisch incorrect. We hebben het immers niet over het vervangen van standaard tags maar het groeperen ervan in meer betekenisvolle componenten.

[Reactie gewijzigd door Ed Vertijsment op 23 juli 2024 06:34]

[R4gnax]

Ik hecht gewoon (te?) veel belang aan semantiek en scheiding tussen styling en code. Dit wordt een fragmentatie.

Ik ben benieuwd of je weet wat Houdini is en in hoeverre je daar dan een rolberoerte van krijgt.

[RoestVrijStaal]

En niet vergeten dat je voor de meest triviale formulier per se JavaScript aan moet hebben staan, omdat de webdeveloper weer per se een Custom Element van zijn formulier heeft gemaakt

[Sicco2]

voor het gebruik van bijna elke site moet je tegenwoordig Javascript aan hebben staan. behalve een paar geeks heeft niemand het uitstaan. Ik snapte dit soort argumentatie halverwege de jaren 90 nog wel... Maar nu dus niet ;-)

[RoestVrijStaal]

Voor een simpel formulier is JavaScript ECHT niet nodig. Bij HTML5 zijn nieuwe attributten en input-typen toegevoegd waardoor je al via HTML-code de input kan valideren.

Laat staan dat voor statische content JavaScript nodig is.

Maar de meeste developers doen alles domweg in JavaScript omdat ze niet weten over dat soort nieuwigheden van HTML5 of jouw ad populum drogreden gebruiken uit pure onwil.

[Sicco2]

dat neemt niet weg dat het argument dat je Javascript aan moet hebben staan nog steeds een beetje onzin argument is als 99.9999% van je bezoekers dit heeft aanstaan. Of het nodig is: tsja, dat is een ander verhaal

[itsleon]

Ik dacht ik schrijf mij wel in.
Ow je moet je registeren
Maar wacht een facebook login
Moet daarna als nog als handmatig invullen, laat maar zitten dus...

[DrPoncho]

ING, voor velen nog altijd in eerste plaats een bank, is steeds meer een it-bedrijf dat in de financiële sector werkzaam is.

Wut? Het is gewoon een bank, die net als zoveel bedrijven tegenwoordig veel gebruik maakt van IT. Beetje hippe verwoording zo, net als hun mooie recruitment reclame 'de bank die aanvoelt als een startup'. Right.

[Frank!in]

Jammer dat ik me op een of andere website moet registreren om de webinar te zien

[OxWax]

Dit artikel is geen redactioneel artikel, maar een advertorial.

[HerrPino]

Web Components, zijn een beetje too-little-too-late, of iig voor professionele web apps. Daar heb je inmiddels Web Assembly die middels een dun js interop laagje componenten genereerd. Daardoor is er weinig toekomst voor web components en relatief trage js libraries als: Angular, Polymer, React, etc