Keywords

botasaurus review, webscraping, open source, benchmark

Content

Botasaurus is een Python-webscrapingframework van Omkar Cloud dat zichzelf neerzet als een alles-in-één toolkit om scrapers te bouwen. Je schrijft gewoon een functie, zet daar @browser, @request of @task boven, en het framework regelt de browserdriver, een browserachtige HTTP-client, caching, parallelle uitvoering en export in meerdere formaten eromheen. Het is een meta-package, en dát is precies het relevante punt: pip install botasaurus zet niet één bibliotheek in je omgeving, maar bouwt een klein pakket van first-party wheels op, plus een brede transitive dependency tree. Dat technische detail bleek uiteindelijk het interessantste dat ik eerlijk kon meten.

Botasaurus profileert zich rond anti-detectie, en precies die invalshoek raakt deze review niet. Ik heb het framework geïnventariseerd — wat er wordt geïnstalleerd, wat het importeert, welke methoden bestaan, hoeveel het weegt en onder welke licentie het valt — in plaats van het te toetsen aan live verdedigingen. Alle footprint- en importcijfers hieronder komen uit pip, uit python -c "import ...", en uit het inspecteren van classes die wel werden aangemaakt maar nooit de opdracht kregen om een pagina op te halen; er is geen browser gestart om deze metingen te produceren. Later heb ik wél browsers gestart, maar alleen op pagina’s die ik zelf schreef en serveerde op 127.0.0.1, om te zien wat de driver over zichzelf meldt en of hij content kan ophalen van een pagina die zichzelf met JavaScript opbouwt. Er kwam geen live website aan te pas, er is geen anti-botservice benaderd of gemeten, en er is geen CAPTCHA aangeraakt. Effectiviteit op echte websites valt bewust buiten scope, en dat zeg ik liever vooraf dan een benchmark te suggereren die ik niet heb gedraaid.

Met die afbakening in place is de hoofdconclusie vooral een footprint-verhaal, en wel een relatief onschuldig. Een schone installatie levert een 122,3 MB site-packages-map op, verspreid over 44 packages, op een machine waar de browserdriver in het midden van dit geheel ongeveer 4 MB groot is. Het framework is niet zwaar omdat de driver zwaar is; het is zwaar omdat “all-in-one” betekent dat het numpy, lxml, gevent en een dozijn andere onderdelen meebrengt voor een taak die HTML ophaalt. En het tweede deel van de conclusie is een getal dat vaak als pluspunt wordt geciteerd, maar dat je niet moet vertrouwen: import botasaurus komt uit op 0,08 ms, wat klinkt als een ultralicht framework maar in werkelijkheid vooral een lege voordeur is.

Wat Botasaurus eigenlijk is

Botasaurus — omkarcloud/botasaurus op GitHub, met 5.561 stars, 486 forks en 58 open issues toen ik op 14 juli 2026 de metadata ophaalde — is een Python-framework, geen library voor één specifiek doel. De versies die ik testte waren botasaurus 4.0.97 voor het meta-package en botasaurus-driver 4.0.92 voor de engine eronder. Het meta-package eist requires-python >=3.7 (de driver >=3.5), en de PyPI-classifiers claimen ondersteuning tot en met 3.11. Op mijn machine installeerde het en slaagde het voor een import-smoketest op Python 3.14.2. Dat is bewijs over deze installatie, geen compatibiliteitsgarantie voor elk onderdeel.

Het categorie-label is belangrijk, omdat het bepaalt wat “goed” betekent. Botasaurus zit aan de framework-kant van het spectrum, in dezelfde hoek als Scrapy en Crawlee: je neemt de structuur, de decorators en de conventies over, en in ruil daarvoor regelt het de plumbing. Dat is iets anders dan een gerichte driver zoals nodriver, die je een Chrome DevTools Protocol-verbinding geeft en verder zo veel mogelijk uit de weg blijft. Botasaurus bundelt een driver (namelijk botasaurus-driver), maar verpakt die in een task runner, een cachinglaag, output-serializers en een request-client. Je koopt dus niet alleen een driver; je koopt een uitgesproken workflow mét driver erin.

De drie decorators zijn in het klein het hele ontwerp, en alle drie de ingangen bestaan echt — ik heb bevestigd dat botasaurus.browser.browser, botasaurus.request.request en botasaurus.task.task allemaal aanwezig zijn en importeerbaar. @browser laat je functie draaien op de gehumaniseerde browserdriver. @request draait hem op een lichte HTTP-client die op een browser lijkt. @task is de generieke wrapper voor alles wat niet duidelijk bij de eerste twee hoort. Decorate, en Botasaurus levert de omliggende machinerie: parallelle uitvoering, hergebruik van de driver, result caching en schrijvers voor JSON, CSV, Excel en HTML. Het is een coherent idee. Of je zoveel framework rondom een scraper wilt, is de echte vraag — en dat is een smaakvraag, geen defect.

De conclusie, en de grens eromheen

Botasaurus is degelijk, goed vormgegeven en doet wat frameworks horen te doen: het maakt het meest voorkomende gebruik kort. Het decorator-model is strak. De MIT-licentie is echt royaal. De installatie verloopt zonder drama. Als ik de ergonomie van de API zou beoordelen, scoort die prima.

Wat me blijft opvallen is dat de eigen hoofdpropositie van het framework — anti-detectie — precies het enige is waar een verantwoordelijke review niets over kan zeggen zonder het tegen iemands productiebeveiliging aan te houden. De driver levert wél een expliciet anti-detectie-gekleurd API-oppervlak: methoden waarvan ik het bestaan heb bevestigd, maar waarvan ik het gedrag niet tegen een target heb getest. Dat is het enige wat ik erover claim. Ik heb het niet op een beschermde site losgelaten, geen succespercentage gemeten, geen mechanisme gereverse-engineerd en ga dat ook niet impliceren via formulering. De methoden bestaan in de class. Wat ze in het wild doen, is een aparte review die dit niet is.

Wat volgt is een inventaris van mogelijkheden, installatie, resources en licenties, plus wat de driver doet op een pagina die ik zelf beheer — een smallere claim dan de meeste reviews van deze tool maken, en precies die smalheid is het punt.

Wat het over zichzelf prijsgeeft

Hier is een vraag die je kunt beantwoorden zonder ook maar in de buurt van een echte verdediging te komen: wat vertelt een browser die door Botasaurus wordt bestuurd over zichzelf aan de pagina die hij bezoekt? Ik schreef een pagina die de voor de hand liggende signalen uitleest — navigator.webdriver, de user-agent, platform, talen, plugin- en hardware-aantallen, de vorm van window.chrome, wat de Permissions API meldt, en window- en schermgeometrie — serveerde die op 127.0.0.1, en zette er vier stacks op: Botasaurus, nodriver, en stock Playwright en stock Puppeteer als controles. Alle vier stuurden exact dezelfde Chrome-build aan (Chrome for Testing 151.0.7922.10), dus alles wat verschilt, komt door de library en niet door de browser. Headless en headed, drie runs per variant. Alle waarden hieronder bleven in alle drie de runs gelijk.

Welke verschillen je ziet, hangt af van welke control je gebruikt. Tegen stock Puppeteer veranderde Botasaurus navigator.webdriver; de talenlijst en de venstergeometrie met nulafmetingen kwamen overeen, terwijl de user-agent alleen in versie-opmaak afweek. Tegen stock Playwright zaten de waargenomen verschillen ook in de talenlijst en venstergeometrie. Tegen nodriver kwamen de boolean en talen overeen, met alleen een ander user-agentformaat in de velden die hier zijn getoond. Dit zijn observaties over standaarddisclosures, geen anti-detectiescore.

Twee details maken dit interessanter dan alleen die false. Het eerste is hoe die waarde daar komt. In alle vier de stacks is de property nog steeds de native getter van de browser zelf op Navigator.prototype — function get webdriver() { [native code] } — nooit een eigen property die op de instance wordt geplakt, nooit een vervangen functie. Botasaurus herschrijft die property dus niet nadat de pagina geladen is; de waarde wordt bepaald zodra de browser start, en de property zelf blijft ongemoeid.

Het tweede detail nuanceert de marketing. In headless mode meldt de user-agent van Botasaurus nog steeds HeadlessChrome/151.0.0.0 — identiek aan stock Puppeteer en identiek aan stock Playwright. In headed mode wordt het Chrome/151.0.0.0, opnieuw identiek. De Driver-constructor accepteert een parameter user_agent, dus een eigen user-agent instellen is een kwestie van een keyword argument, maar de standaardconfiguratie maskeert de bekendste zelf-identificerende string in browserautomatisering niet.

Bijna alles verder was identiek over de vier stacks heen, en dat is belangrijk om hardop te zeggen omdat het verhaal daarmee smaller wordt — elke property hieronder las hetzelfde op Botasaurus, nodriver, Playwright en Puppeteer:

Die oude klassieker waarin de Permissions API en Notification.permission elkaar tegenspreken, kwam nergens voor — alle vier rapporteerden default en prompt consistent. Ik heb ook document en window gescand op de cdc_-achtige restanten waar oudere WebDriver-stacks om bekendstonden: in alle vier leeg.

Nog één ding om te weten vóór je het uitrolt: ondanks zijn 122 MB levert Botasaurus geen browser mee en downloadt het er ook geen. find_chrome_executable() wijst gewoon naar Chrome dat al op je machine staat — op die van mij /Applications/Google Chrome.app, versie 150.0.7871.187 — en precies die versie wordt vervolgens via de user-agent zichtbaar. Je omgeving meldt dus wat er toevallig al geïnstalleerd is, en voor een framework dat zo uitgesproken is, is dat een verrassend onopvallende standaard.

Zeg wat dit is en wat het niet is. Dit is een registratie van wat een geautomatiseerde stack prijsgeeft wanneer niemand hem vraagt iets te verbergen — nuttig als je aan de verdedigende kant zit, nuttig als je wilt weten wat je eigen tooling uitzendt. Het is niet een meting van hoe relevant dat voor een specifieke service is. Ik heb dat niet getest, en geen enkele regel hierboven moet als zo’n uitkomst worden gelezen.

Een wat vergevingsgezindere standaardlezing van deze fixture

Jezelf melden is één ding; de juiste HTML teruggeven is het echte werk. Ik draaide Botasaurus tegen dezelfde fixture met drie contentklassen die ook de rest van deze benchmarkrepo gebruikt, zodat de cijfers gelijklopen met de andere hier gemeten tools. De pagina bevat drie dingen: A, een statische link waarvan de marker letterlijk in de bytes van de response zit; B, een node die tijdens het parsen door een inline script wordt opgebouwd, met marker en URL uit fragmenten samengesteld zodat je ze alleen ziet als je de JavaScript uitvoert; en C, een node die 800 ms ná het load event wordt geïnjecteerd, op dezelfde manier samengesteld. Klasse C is de lastige: een uitlezing op het load event kan die niet zien.

Botasaurus landt waar de zwaargewichten landen. driver.get() gevolgd door direct driver.page_html is een snapshot op load-tijd: JavaScript wordt correct gerenderd — klasse B bewijst dat, want klasse B staat nergens in de aangeleverde bytes — maar content die 800 ms later verschijnt, wordt gemist. Voeg driver.wait_for_element("#delayed-injected") toe en je krijgt alle drie. Stabiel over drie herhalingen en drie aparte runs van de hele suite, zonder flakes.

Het interessante deel zie je wanneer je de injectievertraging doorschuift om te vinden waar de standaardlezing van elke stack opgeeft:

Elke andere stack verliest klasse C zodra de injectie 100 ms of meer na load plaatsvindt. Botasaurus pakt die nog op bij 300 ms, en geeft pas op bij 400. Dit is Botasaurus als framework, en de oorzaak staat gewoon in de constructor: wait_for_complete_page_load=True is de standaard, dus get() keert merkbaar later terug dan een kaal load event. Concreet kost de standaardlezing 401–431 ms wall-clock waar nodriver 119–129 ms nodig heeft en Puppeteer 125–171 ms.

Op deze lokale delayed-injection fixture betaalde je dus grofweg 250 ms per navigatie voor een latere default snapshot. Daarmee werd content opgepikt die in deze runs tot 300 ms na load werd geïnjecteerd; dat bewijst niet dat Botasaurus op willekeurige sites correcter is. Als je snelle scrapers schrijft zonder expliciete wait-conditions, kan die extra marge een gemiste late node voorkomen. Bij hoge navigatievolumes, of als je toch al op een precieze conditie wacht, is het gewoon overhead.

Nog twee timings voor het gevoel van schaal. Het opstarten van de browser bracht Botasaurus ongeveer op het niveau van nodriver en Puppeteer, en ruim achter Playwright:

En wait_for_element() kost tot aan een vertraging van 300 ms niets extra — get() was toen al voorbij het injectiemoment — en loopt daarna op naar ongeveer 1,42 s bij 400–800 ms en 2,43 s bij 1500 ms.

De vraag van 122 MB: wat een meta-package eigenlijk installeert

Hier is de rekensom, omdat dit het nuttigste is dat ik je kan geven. Een schone pip install botasaurus in een verse virtuele omgeving leverde een site-packages-boom op van 122,3 MB verdeeld over 44 dist-info packages. Haal pip zelf eruit (10,9 MB, dus venv-overhead en niet iets wat Botasaurus expliciet vroeg) en je zit op ongeveer 111 MB framework plus dependencies. De browserdriver — het onderdeel dat daadwerkelijk de browserautomatisering uitvoert — is daarvan ongeveer 4 MB. Dus zo’n 107 MB is alles wat het meta-package verder nodig vond.

Waar gaat die ruimte naartoe? Alleen al de vijf zwaarste transitive dependencies verklaren het grootste deel (elke rij is een install_footprint.heaviest_deps_mb-entry in artifacts/raw/runs/resource_baseline.run1.json; het totaal is mijn optelsom, niet een veld in het bestand):

Dat numpy het grootste losse onderdeel is, maakte me even fronsen — dat is een lineaire-algebra-bibliotheek in een tool die webpagina’s ophaalt en parset. Het is niet per se fout; frameworks stapelen nu eenmaal hulpbibliotheken op, en blijkbaar heeft iets in de boom array-mathematica nodig. Het is alleen wel veel machine voor zo’n klusje.

Ter vergelijking: de gerichte driver nodriver weegt op dezelfde machine ongeveer 17,2 MB over 6 packages — dus ruwweg 7x lichter. (Dat cijfer komt niet uit deze bundel: het is install_footprint.site_packages_total_mb in nodriver’s eigen artifacts/raw/runs/resource_baseline.run1.json, gemeten in een aparte run op dezelfde host, en 122,3 ÷ 17,2 = 7,1.) Geen van beide cijfers is een defect en dit is geen ranglijst van capaciteiten; het is simpelweg het mechanische kostenverschil tussen een batteries-included framework en een gerichte driver. In een container telt de gemeten site-packages-footprint mee in de applicatielaag. Het is niet de totale imagegrootte, en deze test heeft build- of cold-deploytijd niet gemeten.

Nog één footprint-detail: tijdens inspectie zorgde het eerste gebruik van from botasaurus.request import request voor een eenmalige download van ongeveer 12,8 MB. De vastgelegde run identificeerde het artefact en de bestemming niet goed genoeg om dat als stabiele toevoeging aan de geïnstalleerde footprint te behandelen. Wel laat het zien dat deze codepath bij eerste gebruik netwerktoegang kan nodig hebben, en dat is iets wat je in je eigen image moet reproduceren vóór een air-gapped deployment.

Het importgetal dat liegt

Cold-start importtijd is waar een oppervlakkige lezing van de cijfers de mist in gaat. Gemeten over zeven verse subprocess-imports kwam import botasaurus op topniveau uit op een mediaan van 0,08 ms. Dat afzonderlijk citeren doet vermoeden dat dit het lichtste framework in de categorie is.

Dat is het niet. Het is snel omdat er bijna niets in zit. Het topniveau botasaurus-pakket exposeert geen __version__ en heeft een bijna lege publieke namespace — importeren kost nauwelijks iets, simpelweg omdat er bijna niets wordt geladen. Het getal dat voor een CLI-tool of serverless cold start echt telt, is het importeren van de engine: from botasaurus_driver import Driver duurt ongeveer 135 ms, stabiel binnen een paar milliseconden over de runs heen. Dat is de echte vaste kost voordat er ook maar één pagina wordt opgehaald. En zodra de drivermodule geladen is, zit het resident memory rond 29–30 MB — opnieuw nog vóór er een Chrome-proces bestaat. Start je echt een browser, dan loopt dat flink op; ik heb geheugen niet gemeten terwijl er één liep, dus ik plak daar geen getal op.

De les is klein maar scherp: dat import botasaurus instant is, zegt iets over het feit dat het top-level-pakket hol is, niet over het framework goedkoop is. Als je een cold start wilt inschatten, meet dan de import waarop je werkelijk vertrouwt.

API-vorm: 99 methoden achter een bijna lege voordeur

De Driver-class van de engine biedt 99 publieke methoden — een brede surface voor navigatie, elementqueries, cookies en local storage, muis- en toetsenbordacties, screenshots, tabbeheer, CDP-passthrough en file uploads. De constructor neemt 18 parameters, wat een redelijk beeld geeft van het afstembare oppervlak: headless, proxy, profile, tiny_profile, block_images, block_images_and_css, wait_for_complete_page_load, chrome_executable_path, extensions, arguments, user_agent, window_size, lang en nog een handvol andere. Als constructor-API dekt het de gebruikelijke browserwrapper-opties af.

De valkuil zit bovenin, en die is onschuldig maar reëel. import botasaurus geeft je een bijna lege namespace — geen __version__, praktisch geen publieke namen op topniveau. Alles wat je echt gebruikt zit in submodules: from botasaurus.browser import browser, Driver, from botasaurus.request import request, from botasaurus.task import task. Als je op zoek gaat naar botasaurus.__version__ om je build te loggen, vind je die niet; dan moet je importlib.metadata gebruiken. Niets daarvan breekt iets. Het is gewoon niet de indeling die de meeste Pythonontwikkelaars intuïtief verwachten, en dat weten scheelt je op dag één een verwarrende vijf minuten.

Een observatie over de methoden die ik eerder markeerde is ook eerlijk en blijft binnen mijn afbakening: van de anti-detectie-genoemde methoden die bestaan, hebben er maar 2 een docstring in de code zelf. De rest spreekt vooral voor zich via de naam; de per-method documentatie staat op de externe docs-site in plaats van in de geïnstalleerde source. Dat is een opmerking over locatie, geen kwaliteitsoordeel — genoeg goede libraries houden hun uitleg buiten de code — maar als jouw workflow is “lees de source om de methode te begrijpen”, dan vertelt het grootste deel van dit specifieke oppervlak je vooral de naam, niet het gedrag.

Licentie: MIT, helemaal tot aan de driver

Zowel het meta-package als botasaurus-driver verklaren MIT, met de standaard License :: OSI Approved :: MIT License-classifier. MIT is permissief: geen copyleftverplichting, geen noodzaak om je eigen code open te maken, minimale frictie voor commercieel gebruik. Dat is een echt en niet onbelangrijk contrast met nodriver, de nabije anti-detect driver, die onder AGPL-3.0 wordt geleverd — een copyleft-licentie waarvan de network-use clause veel juridische afdelingen nerveus maakt. Als licenties voor jou een hard criterium zijn, is Botasaurus’ MIT-standpunt een reëel pluspunt.

De kanttekening is weer de vorm van het meta-package. Die permissieve MIT geldt voor de first-party wheels van Botasaurus zelf. Ze zegt niet automatisch iets over de ongeveer 40 transitive packages die de installatie meeneemt, elk met zijn eigen licentie. Ik heb de top-level MIT van de packages die Omkar Cloud publiceert bevestigd; ik heb niet elke dependency in de boom op licentie gecontroleerd. Voor een hobbyproject is dat onderscheid zelden van belang. Voor een volledige adoptie binnen een bedrijf dat om zijn software bill of materials geeft, is die 40-packages-boom iets om eerst door je eigen licentiescanner te halen voordat je tekent — niet omdat ik een probleem vond, maar omdat ik er niet naar heb gekeken, en een meta-package precies de plek is waar een onverwachte licentie zich kan verstoppen.

Voor- en nadelen

Voordelen:

• Strak ontwerp met drie decorators (@browser / @request / @task), en alle drie de ingangen zijn aanwezig bevestigd — het framework houdt het gebruikelijke geval kort.
• MIT-licentie op zowel meta-package als driver, een duidelijk contrast met de AGPL-3.0 van een vergelijkbare driver. Permissief, commercieel vriendelijk, geen copyleft.
• Brede driversurface: 99 publieke methoden en een constructor met 18 parameters die de gebruikelijke browserautomatiseringsbehoeften afdekt.
• Geïnstalleerd en import-smoketests doorstaan op Python 3.14.2 en 3.12.13, dus voorbij de versie die de classifiers vermelden (die stoppen bij 3.11); runtime-compatibiliteit is niet vastgesteld.
• De ruimste standaardlees-correctheid van alle stacks die ik heb gemeten: het vangt nog content op die 300 ms na load wordt geïnjecteerd, waar nodriver, Playwright en Puppeteer die al bij 100 ms missen. wait_for_complete_page_load=True doet echt werk.
• Rapporteert navigator.webdriver standaard als false, waar beide stock controls true geven, zonder de property te patchen — de descriptor blijft de native browser-getter.
• Batteries included by design — caching, parallelisme, hergebruik van drivers en uitvoer naar JSON/CSV/Excel/HTML maken deel uit van het framework, niet van losse add-ons.

Nadelen:

• Zwaar op schijf: 122,3 MB over 44 packages, ongeveer 7x een gerichte driver, vooral door dependencies als numpy (30,9 MB) en lxml (19,2 MB) in plaats van door de ~4 MB driver zelf.
• De geruststellende top-level import van 0,08 ms is misleidend; de engine-import waar je echt van afhankelijk bent is ~135 ms, en het geheugen na import zit rond de 29–30 MB nog vóór er een browser draait.
• Die ruimere standaardlees-correctheid is niet gratis: 401–431 ms per navigate-and-read tegenover 119–129 ms voor een lichte driver op dezelfde pagina en dezelfde Chrome.
• Headless runs melden standaard nog steeds HeadlessChrome in de user-agent, net als de stock controls; de constructorparameter user_agent bestaat, maar niemand stelt hem voor je in.
• Voor 122 MB levert het nog steeds geen browser mee — het bestuurt gewoon Chrome dat al op de host staat, dus de browserversie die je prijsgeeft is wat er toevallig al geïnstalleerd is.
• Eerste gebruik van @request veroorzaakte in deze run een eenmalige download van ongeveer 12,8 MB; artefact en bestemming waren niet goed genoeg vastgelegd om dat als stabiele footprint-toevoeging te bestempelen.
• Het top-level package is bijna leeg en exposeert geen __version__; de echte API en de versie zitten op minder voor de hand liggende plekken.
• De meeste methoden met anti-detectie-naam hebben geen docstring in de code, dus de source vertelt je vooral namen, niet gedrag.

Buiten wat deze cijfers dekken, en dus hier niet getest: alles rond echte anti-bot effectiviteit (bewust buiten scope), per-pagina geheugen, proxy- en profielafhandeling, throughput op schaal, en elk platform buiten macOS arm64. De footprint- en importcijfers zijn zonder browser gestart te hebben geproduceerd; de recall- en disclosurecijfers komen van browsers die alleen met een fixture op 127.0.0.1 praatten.

Voor wie het is, en wie het beter overslaat

Botasaurus past als je een framework wilt in plaats van een onderdeel. Begin je een scrapingproject vanaf een leeg bestand en wil je liever een structuur overnemen dan die zelf samenstellen — decorators voor de ingangen, caching en parallelisme geregeld, output writers ingebouwd — dan is dit een samenhangende, MIT-gelicentieerde optie. MIT is permissief, maar je gebruiks- en distributiemodel verdient nog steeds de normale compliance-check. Teams die al in termen van Scrapy of Crawlee denken, zullen de insteek vertrouwd vinden.

Sla het over, of denk ten minste twee keer na, als je deploymenttarget gevoelig is voor grootte. Een installatie van 122 MB met numpy en gevent in de boom is veel om een slanke container in te duwen als je feitelijke behoefte is: “stuur een browser aan en haal wat velden op.” Een gerichte driver geeft je de automatisering voor een fractie van het gewicht, tegen de prijs dat je de omringende plumbing zelf moet bouwen. En sla het helemaal over als je een beslissing zoekt over anti-detectie-effectiviteit, want dat is juist het enige dat ik bewust niet heb getest — je zou dan vertrouwen op een marketingclaim die ik noch bevestigd noch weerlegd heb.

Alternatieven, en waar Thunderbit past

Eerst de eerlijke framing: Botasaurus is gratis, MIT-gelicentieerd en self-hosted. Jij runt de infrastructuur, beheert updates en draagt de hele dependency tree — alle 44 packages ervan — inclusief patching, licentiecompliance en alles wat numpy in een toekomstige release besluit te doen. Voor veel teams is die eigenaarschap precies wat ze willen, en geen managed service verslaat “een framework dat je al hebt” op pure kosten.

Binnen open source is vergelijken vooral een kwestie van vorm. Zit je met Botasaurus aan de framework-kant, dan zijn Scrapy en Crawlee de voor de hand liggende peers om tegen af te wegen — volwassen, uitgesproken en elk met hun eigen conventies. Wil je liever LLM-klaar Markdown uit een pagina halen dan een framework om een crawler te structureren, dan zijn Crawl4AI en het contentgerichte Trafilatura daar specifiek op gericht. Vind je de Python-plus-anti-detectiehoek aantrekkelijk, maar wil je iets lichter dan een meta-package, dan is Scrapling het bekijken waard, en als een gecompileerde taal bespreekbaar is, dan ruilt de Go-bibliotheek Colly JavaScript-rendering in voor snelheid en een kleine footprint. Elke browsersturende optie, Botasaurus incluis, erft het kostenprofiel dat onze Playwright- en Puppeteer-vergelijking schetst — echte browsers zijn niet goedkoop om te draaien, en daarom weegt het framework eromheen wat het weegt.

Waar een managed API in beeld komt, zit je in dezelfde keten op een andere plek. Botasaurus is de self-hosted developer stack; Thunderbit verkoopt de managed variant, gericht op dezelfde developers. De Open API heeft twee endpoints. POST /distill (1 credit) zet een pagina om in schone, LLM-klare Markdown, waarbij rendering en anti-bot server-side worden afgehandeld, zodat je helemaal geen browser of dependency tree hoeft te provisionen. POST /extract (20 credits) levert gestructureerde JSON op basis van een JSON Schema dat je zelf definieert, met renderMode op none, basic of full afhankelijk van hoeveel browser de pagina echt nodig heeft. Beide hebben batchversies voor maximaal honderd URL’s tegelijk. Er is een MCP-server voor agents en coding assistants — thunderbit_suggest_fields is gratis en vertelt je wat een pagina exposeert vóór je iets uitgeeft — en via npx @thunderbit/thunderbit-cli heb je een CLI voor cron en CI. Voor niet-developers die dat liever allemaal niet aanraken, draait de Chrome-extensie dezelfde engine als no-code tool, en de walkthroughs op Thunderbit's YouTube-kanaal behandelen de gebruikelijke workflows.

Het verschil zit in waar het werk leeft, niet in welk hulpmiddel “beter” is. Botasaurus houdt het framework, de browservloot, dependencies, infrastructuur en onderhoud aan jouw kant van de streep, zonder vendor fee per request; compute, bandwidth, proxies en operations kosten nog steeds geld. Een managed API haalt rendering en schema-gestuurde output van je bord en rekent per call — dat kun je afzetten tegen een self-hosted setup op de pricingpagina.

Probeer Thunderbit voor webdata-extractie

Eindoordeel

Botasaurus is een redelijke kandidaat als je een all-in-one Python-framework wilt en de dependency footprint accepteert. Het drie-decorator-ontwerp is strak, de driversurface is breed, en het doorstond install- en import-smoketests op Python-versies die nieuwer zijn dan de classifiers beweren. Op mijn lokale fixture ving de default snapshot bovendien content op die 300 ms na load werd geïnjecteerd, waar de andere geteste stacks die al op 100 ms misten; dat is een fixture-resultaat, geen algemene rangschikking.

Maar laat de claims wel in verhouding staan. Het is een installatie van 122 MB met 44 packages, waarbij de driver ongeveer 4 MB is en de rest numpy, lxml, gevent en aanverwanten — grofweg 7x een gerichte driver, en dat gewicht zie je terug in je containerimage en je cold-deploytijd. De top-level import van 0,08 ms is een holle voordeur, niet een licht framework; de ~135 ms engine-import is de rekening die je betaalt. Die vergevingsgezinde standaardlezing kost ongeveer 250 ms extra bij elke navigatie. En op de vraag naar standaarddisclosures die ik daadwerkelijk kon beantwoorden, is het beeld smaller dan de marketing doet vermoeden: één boolean verschilt van stock Puppeteer, de headless user-agent zegt nog steeds HeadlessChrome, en elke andere property die ik mat was identiek over alle vier stacks. De anti-detectiepropositie die het product verkoopt, is precies het onderdeel dat deze review niet beoordeelt — ik heb bevestigd dat die methoden bestaan, de driver op een pagina op mijn eigen machine losgelaten en daar bewust mee gestopt. Ken de footprint, negeer het flatterende importgetal, en behandel stealth-marketing als een open vraag, en Botasaurus is een degelijk framework dat precies doet wat een framework doet. Verwacht je een featherweight driver, dan verrast docker build je.

Probeer Thunderbit voor webdata-extractie Get Started Free

FAQ’s

Is Botasaurus gratis, en onder welke licentie valt het? Ja, het is gratis en MIT-gelicentieerd — zowel het botasaurus meta-package als de botasaurus-driver engine dragen de OSI-goedgekeurde MIT-classifier. MIT is permissief, dus er is geen copyleftverplichting en het is vriendelijk voor commercieel gebruik, wat een belangrijk contrast is met vergelijkbare anti-detect drivers die onder AGPL-3.0 worden uitgebracht. Eén kanttekening: MIT dekt de eigen packages van Omkar Cloud, maar niet automatisch de ongeveer 40 transitive dependencies die de installatie meeneemt, dus draai je eigen licentiescan vóór een volledige bedrijfsadoptie van de hele tree.

Hoe groot is een Botasaurus-installatie, en waarom lijkt import botasaurus dan toch instant? Een schone pip install botasaurus leverde op mijn machine een site-packages-boom van 122,3 MB op over 44 packages. De browserdriver zelf is maar ongeveer 4 MB — het gewicht komt door het meta-package dat een brede dependency tree meebrengt, aangevoerd door numpy (30,9 MB), lxml (19,2 MB), botasaurus_requests (12,6 MB), gevent (11,3 MB) en pygments (8,4 MB). Dat is ruwweg 7x de footprint van een gerichte driver zoals nodriver op dezelfde machine. Dat is geen defect; het is de prijs van “batteries included”, en het telt vooral voor de grootte van je containerimage. De importtijd is waar die footprint zich verstopt: import botasaurus meet ongeveer 0,08 ms, maar alleen omdat het top-level package bijna leeg is — geen __version__, bijna geen publieke namen, dus het importeren doet nauwelijks iets. De import die je echt betaalt is de engine, from botasaurus_driver import Driver, rond de 135 ms, met ongeveer 29–30 MB resident memory na die import en vóór er een browser start. Een serverless cold start inschatten? Meet de engine-import, niet de holle top-level import.

Wat laat Botasaurus over zichzelf zien, en is het getest tegen echte anti-botsystemen? Het eerste deel is gemeten; het tweede deel is bewust niet getest. Op een pagina die ik vanaf 127.0.0.1 serveerde, met exact dezelfde Chrome-build als de controls, komt navigator.webdriver terug als false, terwijl stock Playwright en stock Puppeteer allebei true rapporteren. Die waarde wordt gezet bij het starten van de browser, niet door de property te patchen — de descriptor is nog steeds Chrome’s eigen native getter. Verder kwam bijna alles overeen met de controls: dezelfde platformstring, vijf plugins, twaalf cores, 16 GB gemeld devicegeheugen, dezelfde window.chrome-vorm, geen Permissions-API-tegenstrijdigheid en geen cdc_-achtige resten op document of window. Headless runs melden nog steeds HeadlessChrome/151.0.0.0 in de user-agent, net als beide controls — de Driver-constructor heeft wel een user_agent-parameter, maar niemand stelt die standaard voor je in. Wat effectiviteit betreft: ik heb de driver nooit op een live site gezet, nooit een anti-botservice benaderd en nooit een CAPTCHA aangeraakt. De driver bevat wel methoden met anti-detectie-naam, waarvan ik het bestaan heb bevestigd, maar ik heb ze niet aangeroepen, hun gedrag niet op een target getest, geen succesratio gemeten en geen mechanisme beschreven. De disclosure-tabel hierboven zegt alleen wat de stack zelf meldt, en niets over wie er luistert of wat die daarmee doen.

Kan Botasaurus JavaScript-gerenderde content goed verwerken? Ja, en de standaardinstelling is vergevingsgezinder dan bij de meeste tools. Op een fixture met drie contentklassen leverde driver.get() + driver.page_html 2 van 3 op bij een injectievertraging van 800 ms — JavaScript wordt dus correct uitgevoerd, maar de read gebeurt vóór de zeer late content landt — en driver.wait_for_element() gaf 3 van 3 terug. Het onderscheidende punt is waar de default read opgeeft: Botasaurus pakt content die 300 ms na load wordt geïnjecteerd nog mee, terwijl nodriver, Playwright en Puppeteer die al bij 100 ms kwijtraken. Dat komt door wait_for_complete_page_load=True in de constructor, en dat kost ongeveer 250 ms per navigatie.

Hoe importeer en gebruik ik Botasaurus eigenlijk na installatie? Niet op de manier die je zou verwachten. De botasaurus-namespace op topniveau is bijna leeg, dus de echte API zit in submodules: from botasaurus.browser import browser, Driver, from botasaurus.request import request en from botasaurus.task import task. Je decoreert een gewone functie met @browser, @request of @task, en het framework regelt de omliggende driver, caching en output. Omdat er geen botasaurus.__version__ is, gebruik je importlib.metadata als je wilt loggen welke build je draait.