In ons eerdere artikel hebben we de bestaande automatiseringsprotocollen onderzocht, namelijk WebDriver "Classic" en Chrome DevTools Protocol (CDP), samen met hun respectieve voordelen en beperkingen.
Maak kennis met WebDriver BiDi, de toekomst van browserautomatisering! Het is een nieuw standaard browserautomatiseringsprotocol dat momenteel wordt ontwikkeld, met als doel het beste van zowel WebDriver “Classic” als CDP te combineren. WebDriver BiDi belooft bidirectionele communicatie, waardoor deze standaard snel is, en zit boordevol bediening op laag niveau.
| WebDriver BiDi | |
|---|---|
| WebDriver “Klassiek” | Chrome DevTools-protocol (CDP) |
| Beste ondersteuning voor meerdere browsers | Snelle, bidirectionele berichtenuitwisseling |
| W3C-standaard | Biedt controle op laag niveau |
| Gebouwd om te testen | |
De visie achter WebDriver BiDi is om u tests te laten schrijven met behulp van al uw favoriete tools en deze in elke browser of driver te automatiseren, waardoor u volledige flexibiliteit krijgt.
Standaardisatie
De WebDriver BiDi Working Group bestaat uit een diverse groep browserleveranciers, open-source browserautomatiseringsprojecten en bedrijven die browserautomatiseringsoplossingen aanbieden. Deze samenwerking zorgt voor een veelbelovende toekomst voor browserautomatisering.
Het werk wordt grotendeels gedaan in deze GitHub-repository . Er zijn maandelijkse bijeenkomsten met alle grote browserleveranciers, waarin de feitelijke voortgang wordt gerapporteerd en twijfelachtige en onbekende details worden besproken. De bedrijfsoverkoepelende werkgroep zorgt ervoor dat beslissingen op één lijn liggen met alle belanghebbenden.
Het opzetten en implementeren van een nieuw protocol is geen sinecure. Het vereist gezamenlijke inspanningen van verschillende leveranciers die samenwerken en samenwerken. Het proces omvat:
- Specificatie : een verzoek om commentaar (RFC)-proces om feedback op het voorstel te verzamelen.
- Verificatie : een reeks tests die op verschillende platforms kunnen worden uitgevoerd en die als bron van waarheid voor alle implementaties dienen.
- Implementatie : browsers implementeren de protocollen volgens de specificaties en slagen voor de verificatietests.
Uitdagingen
In dit gedeelte gaan we dieper in op de uitdagingen bij het implementeren van WebDriver BiDi, omdat het een evenwicht probeert te vinden tussen compatibiliteit, bruikbaarheid en implementeerbaarheid.
Verder dan een CDP-kloon: cross-browser compatibiliteit omarmen
CDP, met zijn Chrome- en DevTools-specifieke elementen, kan niet rechtstreeks worden gerepliceerd in de WebDriver BiDi-specificatie. Het implementeren van CDP zoals het is, zou onhaalbaar zijn voor andere browsers, waardoor een specificatie die alleen maar documenteert hoe dat moet, zinloos wordt.
Zorgen voor een lage latentie
WebDriver BiDi moet ontworpen zijn om hoge latentie aan te kunnen zonder dat dit ten koste gaat van de prestaties. Bij CDP is de latentie laag omdat client en server vrijwel altijd op dezelfde fysieke machine draaien, maar bij WebDriver BiDi is dit niet het geval. Daarom moet WebDriver BiDi het aantal benodigde roundtrips tussen client en server minimaliseren.
Ergonomie voorop stellen in BiDi
Hoewel niet van ontwikkelaars wordt verwacht dat ze WebDriver BiDi-clients helemaal opnieuw bouwen, is het van cruciaal belang om te voorkomen dat het protocol te ingewikkeld wordt. Een te complexe BiDi zou niet alleen een uitdaging zijn om te implementeren, maar ook moeilijk om mee te werken, wat de adoptie en het gebruik belemmert.
Het borgen van de implementeerbaarheid van BiDi
WebDriver BiDi moet realistisch implementeerbaar zijn, rekening houdend met de beperkingen van verschillende browsers. Het behouden van alle JavaScript-objecten die ooit door BiDi aan clients zijn blootgesteld, kan bijvoorbeeld leiden tot geheugenlekken, terwijl het niet bewaren ervan het debuggen en de interactie met het JavaScript van een pagina zou belemmeren. Het is essentieel om een evenwicht te vinden dat effectieve browserautomatisering mogelijk maakt zonder dat dit ten koste gaat van de prestaties.
Uitdagingen overwinnen
In deze sectie bespreken we de strategieën die worden gebruikt om de uitdagingen van de implementatie van WebDriver BiDi aan te pakken.
Snelle prototypering
Het aangaan van de uitdaging van implementeerbaarheid is cruciaal voor het succes van BiDi. Om de voortgang van de specificatie en tests te versnellen, hebben we een rapid prototyping-aanpak gevolgd met behulp van NodeJS. Dit stelt ons niet alleen in staat om met verschillende oplossingen te experimenteren, maar vergemakkelijkt ook de ontwikkeling van webplatformtests.
Ontwerp met prestatie in gedachten
Deze ontwerpbeslissing wordt bepaald door de prestaties, aangezien in sommige gevallen de latentie hoog is in WebDriver BiDi. Wanneer u bijvoorbeeld een object-ID en waarde uit de browser ophaalt, heeft WebDriver BiDi slechts één retour nodig, terwijl CDP er twee nodig heeft. Dit komt omdat WebDriver BiDi zowel de ID als de waarde in één antwoord kan retourneren (het resultaat mag niet JSON-serialiseerbaar zijn), terwijl CDP ze afzonderlijk moet retourneren.
Nadruk op webplatformtests (WPT)
Webplatformtests spelen een belangrijke rol in de werkzaamheden van BiDi. WPT omvat momenteel WebDriver “Classic” en WebDriver BiDi en dient als een betrouwbare referentie voor alle implementaties. Deze tests zijn ontworpen om te worden uitgevoerd en doorgegeven aan verschillende implementaties, waardoor een consistente protocoluitvoering tussen browsers wordt gegarandeerd, wat essentieel is voor het succes van WebDriver BiDi. Bekijk het laatste WPT-resultaat in het dashboard .
Wat is het plan en de huidige voortgang?
Bekijk de WebDriver BiDi-roadmap om de richting van het project te begrijpen. De routekaart is werk in uitvoering en evolueert voortdurend.
Raadpleeg de nieuwste webplatformtests voor de implementatiestatus in browsers, aangezien deze als bron van waarheid dienen.
Blijf op de hoogte van de projectmijlpalen om de voortgang ervan te volgen.
Ontdek de prestaties die in 2023 zijn behaald en blijf op de hoogte van de laatste ontwikkelingen!
Ondersteuning van WebDriver BiDi: hoe u kunt helpen
Bent u enthousiast over de toekomst van browserautomatisering met WebDriver BiDi? Zo kunt u uw steun betuigen:
- Wees een vroege tester en gebruiker en help de toekomst van WebDriver BiDi vorm te geven.
- Vertel het verder! Deel het project op sociale media met de hashtag #WebDriverBiDi .
- Vraag om ondersteuning . Dien een functieverzoek in of vraag bij uw favoriete tools naar hun plannen voor het adopteren van WebDriverBiDi.
- Neem deel aan de RFC en geef feedback op de API's.
Veelgestelde vragen
Gaat WebDriver BiDi het Chrome DevTools Protocol (CDP) vervangen?
Nee. Chromium-gebaseerde browsers zullen CDP blijven gebruiken voor foutopsporingsdoeleinden, terwijl WebDriver BiDi de nieuwe specificatie is om aan de testbehoeften te voldoen met een meer ergonomische API.
Aangezien Puppeteer CDP gebruikt, betekent dit dat Puppeteer wordt beëindigd?
Nee. WebDriver BiDi zorgt er echter voor dat Puppeteer een automatiseringstool voor meerdere browsers wordt.
Heeft u een publieke roadmap?
Ja, bezoek onze roadmap op GitHub .
,
In ons eerdere artikel hebben we de bestaande automatiseringsprotocollen onderzocht, namelijk WebDriver "Classic" en Chrome DevTools Protocol (CDP), samen met hun respectieve voordelen en beperkingen.
Maak kennis met WebDriver BiDi, de toekomst van browserautomatisering! Het is een nieuw standaard browserautomatiseringsprotocol dat momenteel wordt ontwikkeld, met als doel het beste van zowel WebDriver “Classic” als CDP te combineren. WebDriver BiDi belooft bidirectionele communicatie, waardoor deze standaard snel is, en zit boordevol bediening op laag niveau.
| WebDriver BiDi | |
|---|---|
| WebDriver “Klassiek” | Chrome DevTools-protocol (CDP) |
| Beste ondersteuning voor meerdere browsers | Snelle, bidirectionele berichtenuitwisseling |
| W3C-standaard | Biedt controle op laag niveau |
| Gebouwd om te testen | |
De visie achter WebDriver BiDi is om u tests te laten schrijven met behulp van al uw favoriete tools en deze in elke browser of driver te automatiseren, waardoor u volledige flexibiliteit krijgt.
Standaardisatie
De WebDriver BiDi Working Group bestaat uit een diverse groep browserleveranciers, open-source browserautomatiseringsprojecten en bedrijven die browserautomatiseringsoplossingen aanbieden. Deze samenwerking zorgt voor een veelbelovende toekomst voor browserautomatisering.
Het werk wordt grotendeels gedaan in deze GitHub-repository . Er zijn maandelijkse bijeenkomsten met alle grote browserleveranciers, waarin de feitelijke voortgang wordt gerapporteerd en twijfelachtige en onbekende details worden besproken. De bedrijfsoverkoepelende werkgroep zorgt ervoor dat beslissingen op één lijn liggen met alle belanghebbenden.
Het opzetten en implementeren van een nieuw protocol is geen sinecure. Het vereist gezamenlijke inspanningen van verschillende leveranciers die samenwerken en samenwerken. Het proces omvat:
- Specificatie : een verzoek om commentaar (RFC)-proces om feedback op het voorstel te verzamelen.
- Verificatie : een reeks tests die op verschillende platforms kunnen worden uitgevoerd en die als bron van waarheid voor alle implementaties dienen.
- Implementatie : browsers implementeren de protocollen volgens de specificaties en slagen voor de verificatietests.
Uitdagingen
In dit gedeelte gaan we dieper in op de uitdagingen bij het implementeren van WebDriver BiDi, omdat het een evenwicht probeert te vinden tussen compatibiliteit, bruikbaarheid en implementeerbaarheid.
Verder dan een CDP-kloon: cross-browser compatibiliteit omarmen
CDP, met zijn Chrome- en DevTools-specifieke elementen, kan niet rechtstreeks worden gerepliceerd in de WebDriver BiDi-specificatie. Het implementeren van CDP zoals het is, zou onhaalbaar zijn voor andere browsers, waardoor een specificatie die alleen maar documenteert hoe dat moet, zinloos wordt.
Zorgen voor een lage latentie
WebDriver BiDi moet ontworpen zijn om hoge latentie aan te kunnen zonder dat dit ten koste gaat van de prestaties. Bij CDP is de latentie laag omdat client en server vrijwel altijd op dezelfde fysieke machine draaien, maar bij WebDriver BiDi is dit niet het geval. Daarom moet WebDriver BiDi het aantal benodigde roundtrips tussen client en server minimaliseren.
Ergonomie voorop stellen in BiDi
Hoewel niet van ontwikkelaars wordt verwacht dat ze WebDriver BiDi-clients helemaal opnieuw bouwen, is het van cruciaal belang om te voorkomen dat het protocol te ingewikkeld wordt. Een te complexe BiDi zou niet alleen een uitdaging zijn om te implementeren, maar ook moeilijk om mee te werken, wat de adoptie en het gebruik belemmert.
Het borgen van de implementeerbaarheid van BiDi
WebDriver BiDi moet realistisch implementeerbaar zijn, rekening houdend met de beperkingen van verschillende browsers. Het behouden van alle JavaScript-objecten die ooit door BiDi aan clients zijn blootgesteld, kan bijvoorbeeld leiden tot geheugenlekken, terwijl het niet bewaren ervan het debuggen en de interactie met het JavaScript van een pagina zou belemmeren. Het is essentieel om een evenwicht te vinden dat effectieve browserautomatisering mogelijk maakt zonder dat dit ten koste gaat van de prestaties.
Uitdagingen overwinnen
In deze sectie bespreken we de strategieën die worden gebruikt om de uitdagingen van de implementatie van WebDriver BiDi aan te pakken.
Snelle prototypering
Het aangaan van de uitdaging van implementeerbaarheid is cruciaal voor het succes van BiDi. Om de voortgang van de specificatie en tests te versnellen, hebben we een rapid prototyping-aanpak gevolgd met behulp van NodeJS. Dit stelt ons niet alleen in staat om met verschillende oplossingen te experimenteren, maar vergemakkelijkt ook de ontwikkeling van webplatformtests.
Ontwerp met prestatie in gedachten
Deze ontwerpbeslissing wordt bepaald door de prestaties, aangezien in sommige gevallen de latentie hoog is in WebDriver BiDi. Wanneer u bijvoorbeeld een object-ID en waarde uit de browser ophaalt, heeft WebDriver BiDi slechts één retour nodig, terwijl CDP er twee nodig heeft. Dit komt omdat WebDriver BiDi zowel de ID als de waarde in één antwoord kan retourneren (het resultaat mag niet JSON-serialiseerbaar zijn), terwijl CDP ze afzonderlijk moet retourneren.
Nadruk op webplatformtests (WPT)
Webplatformtests spelen een belangrijke rol in de werkzaamheden van BiDi. WPT omvat momenteel WebDriver “Classic” en WebDriver BiDi en dient als een betrouwbare referentie voor alle implementaties. Deze tests zijn ontworpen om te worden uitgevoerd en doorgegeven aan verschillende implementaties, waardoor een consistente protocoluitvoering tussen browsers wordt gegarandeerd, wat essentieel is voor het succes van WebDriver BiDi. Bekijk het laatste WPT-resultaat in het dashboard .
Wat is het plan en de huidige voortgang?
Bekijk de WebDriver BiDi-roadmap om de richting van het project te begrijpen. De routekaart is werk in uitvoering en evolueert voortdurend.
Raadpleeg de nieuwste webplatformtests voor de implementatiestatus in browsers, aangezien deze als bron van waarheid dienen.
Blijf op de hoogte van de projectmijlpalen om de voortgang ervan te volgen.
Ontdek de prestaties die in 2023 zijn behaald en blijf op de hoogte van de laatste ontwikkelingen!
Ondersteuning van WebDriver BiDi: hoe u kunt helpen
Bent u enthousiast over de toekomst van browserautomatisering met WebDriver BiDi? Zo kunt u uw steun betuigen:
- Wees een vroege tester en gebruiker en help de toekomst van WebDriver BiDi vorm te geven.
- Vertel het verder! Deel het project op sociale media met de hashtag #WebDriverBiDi .
- Vraag om ondersteuning . Dien een functieverzoek in of vraag bij uw favoriete tools naar hun plannen voor het adopteren van WebDriverBiDi.
- Neem deel aan de RFC en geef feedback op de API's.
Veelgestelde vragen
Gaat WebDriver BiDi het Chrome DevTools Protocol (CDP) vervangen?
Nee. Chromium-gebaseerde browsers zullen CDP blijven gebruiken voor foutopsporingsdoeleinden, terwijl WebDriver BiDi de nieuwe specificatie is om aan de testbehoeften te voldoen met een meer ergonomische API.
Aangezien Puppeteer CDP gebruikt, betekent dit dat Puppeteer wordt beëindigd?
Nee. WebDriver BiDi zorgt er echter voor dat Puppeteer een automatiseringstool voor meerdere browsers wordt.
Heeft u een publieke roadmap?
Ja, bezoek onze roadmap op GitHub .