Qualche settimana fa, qualcuno del nostro team mi ha inoltrato un thread su GitHub in cui uno sviluppatore stava facendo il debug del terzo tentativo di retry di PlaywrightCrawler alle 11 di sera di venerdì. Subito sotto, un altro utente ha risposto con un secco "usa semplicemente Thunderbit per questo", e l’autore del post ha ribattuto: "non è questo il punto, mi serve dentro la mia pipeline". Avevano entrambi ragione. In sostanza, tutto il dibattito Thunderbit vs Crawlee è condensato in quel singolo thread di GitHub.
Ho passato abbastanza anni tra SaaS e strumenti di automazione (un saluto ai tempi di Automation Anywhere) per sapere che la domanda "qual è lo scraper migliore" è quasi sempre quella sbagliata. La vera domanda è: chi fa davvero lo scraping e di cosa ha bisogno dopo? Andiamo al sodo.
La vera domanda non è "Quale strumento è migliore" — è "Chi sta facendo lo scraping?"
C’è una cosa che mette sempre in difficoltà quando qualcuno cerca su Google "Crawlee vs [qualsiasi cosa]": ci si aspetta una sfida testa a testa su ogni singola funzione, come se si stessero confrontando due macchine del caffè. Ma Crawlee e Thunderbit non si contendono lo stesso lavoro. Sono pensati per due persone completamente diverse, alle prese con due problemi completamente diversi.
Crawlee è una libreria open-source per il crawling sviluppata dal team di Apify, e dà per scontato che tu sia uno sviluppatore che sa muoversi con JavaScript, TypeScript o Python. La installi, scrivi gli handler delle richieste, definisci i selettori e lanci il codice. Thunderbit parte da un’idea molto diversa: che tu sia una persona di un team sales, marketing o operations che ha bisogno subito di dati strutturati da una pagina web e non ha alcuna voglia di aprire il terminale.
| Fattore | Crawlee | Thunderbit |
|---|---|---|
| A chi è rivolto | Sviluppatori che costruiscono crawler personalizzati | Utenti non tecnici, team operations/sales/marketing |
| Requisiti di setup | Installare Node.js o Python, scrivere codice per lo scraper | Installare l’estensione del browser, cliccare One Click Extract |
| Serve programmare? | Sì (JS/TS o Python) | No |
| Caso d’uso ideale | Pipeline di produzione, logiche personalizzate | Estrazione strutturata occasionale o ricorrente da una pagina |
Lo sottolineo subito perché secondo me molti articoli di confronto ignorano proprio questa biforcazione iniziale, che invece è quella che decide quale strumento abbia senso prendere in considerazione. Se sei uno sviluppatore e ti serve controllo fine su retry, proxy e browser pool, nessuna comodità “one-click” ti basterà davvero. E se non sei uno sviluppatore, tutta la flessibilità di Crawlee non conta: semplicemente non lo userai.
Cos’è Thunderbit?
Thunderbit è quello che definirei un estrattore web agentico: significa che è il livello AI a fare il lavoro interpretativo di capire cosa c’è in una pagina e cosa va estratto, invece di costringerti a scrivere i selettori a mano. Il flusso principale, nell’estensione Chrome di Thunderbit, è questo: apri la pagina da cui vuoi prendere i dati, clicchi One Click Extract, e l’agente legge e analizza la pagina, individua i campi utili e si prepara all’esecuzione. Run Now compare per avviarlo subito, ma è opzionale: se non fai nulla, l’estrazione parte automaticamente.
La configurazione è davvero tutta qui. Niente sessioni di creazione dello schema o mappatura dei campi: l’agente analizza la pagina e l’estrazione parte in automatico.
Oltre all’estensione del browser, Thunderbit offre anche una Web App, una Open API per l’accesso programmatico, un MCP Server per l’uso da parte di agenti AI e una CLI per i flussi da terminale. Quest’ultimo punto conta più di quanto sembri — ci tornerò più avanti, perché è ciò che impedisce a questo articolo di ridursi a un semplice “vince il no-code”.
Sulle pagine compatibili, Thunderbit può anche gestire la paginazione e arricchire le sottopagine, e una volta ottenuti i dati puoi esportarli in fogli di calcolo o in altre destinazioni supportate. Farei però una precisazione, come faccio sempre quando si dice che “l’AI legge la pagina”: funziona bene su pagine compatibili e autorizzate, ma non è una promessa che ogni framework JavaScript o ogni barriera anti-bot del web si piegherà alla tua volontà.
Cos’è Crawlee?
Crawlee è una libreria open-source — non un prodotto hosted — per costruire crawler e scraper web in JavaScript/TypeScript o Python. È mantenuta da Apify, e voglio essere preciso perché molti confondono le due cose: Crawlee è la libreria, Apify è la piattaforma cloud separata, anche se collegata, che può ospitare ed eseguire progetti basati su Crawlee. Sono parenti, non la stessa cosa.
Quello che ottieni davvero con Crawlee è una cassetta degli attrezzi. Ti offre crawler basati su HTTP per scraping leggeri e poco dipendenti da JavaScript, oltre a crawler browser basati su Playwright e Puppeteer per i siti che richiedono rendering reale. Gestisce le code di richieste, così non devi tenere traccia manualmente degli URL già visitati. Si occupa anche dell’archiviazione dei dati estratti. Include autoscaling e session pool già pronti, così se stai eseguendo un crawl su migliaia di pagine non devi reinventarti da zero la logica di concorrenza.
Però niente di tutto questo succede cliccando un pulsante. Devi scrivere codice — definire gli handler delle richieste, impostare l’istanza del crawler, dirgli cosa fare quando arriva su una pagina. Crawlee ti dà l’impalcatura; la casa la costruisci comunque tu.
Differenza chiave: prodotto di estrazione gestito vs libreria di codice
Tempo per arrivare alla prima tabella strutturata
Qui il divario è più evidente. Con Thunderbit, dal momento in cui apri la pagina a quando hai una tabella di dati utilizzabile passano in genere da pochi secondi a un paio di minuti, su una pagina compatibile: clicchi, lasci che l’agente rilevi ed esegua, fatto.
Con Crawlee, anche il primo crawler banale richiede tempo reale di configurazione. Devi avere installato Node.js o Python, aggiungere il pacchetto Crawlee, scrivere un request handler, individuare i selettori (manualmente, ispezionando la pagina) e poi eseguirlo e correggere ciò che si rompe. Per chi è alle prime armi, direi tra 30 e 60 minuti solo per arrivare a una prima estrazione funzionante — e questo dando per scontato di conoscere già un minimo JavaScript o Python.
Controllo sulla logica di browser/crawler
Qui Crawlee vince senza discussioni. Controlli tutto: quale motore browser usare, come gestire le sessioni, come ruotare i proxy, cosa succede a una richiesta fallita, quanto in profondità scendere nella scoperta dei link, come limitare la concorrenza. Se il tuo crawl richiede logiche personalizzate — per esempio un login multi-step o un sito con una paginazione anomala che manda in crisi gli schemi standard — Crawlee ti mette a disposizione i pezzi per costruire esattamente quello che ti serve.
L’approccio agentico di Thunderbit sacrifica questo livello di granularità in nome della velocità e della semplicità d’uso. Non stai scrivendo tu la logica; è l’AI che la deduce da ciò che vede nella pagina. È ottimo quando funziona, molto meno utile quando devi forzare un pattern di estrazione molto specifico e non immediato.
Responsabilità di deploy e manutenzione
Con Crawlee, il deploy è affar tuo. Questo significa che sei responsabile dell’hosting (i tuoi server, oppure la piattaforma di Apify, o qualsiasi altra opzione tu scelga), della gestione delle modifiche al markup del sito che rompono i selettori e dell’aggiornamento delle dipendenze. È un lavoro continuo vero, ma è anche controllo continuo vero.
Thunderbit gira su infrastruttura gestita — l’estensione del browser esegue localmente nella tua sessione oppure nel cloud per i job pianificati, e gli aggiornamenti alla logica di estrazione avvengono dal lato Thunderbit, non dal tuo.
Scenari pratici
Estrazione una tantum da una pagina
Supponiamo che tu debba estrarre la pagina con l’elenco prodotti di un concorrente in un foglio di calcolo prima di una riunione delle 14:00. Thunderbit è pensato esattamente per questo: apri la pagina, clicchi One Click Extract, esporti. Per un’attività davvero una tantum, Crawlee è troppo: passeresti più tempo a scrivere uno script di quanto ne risparmieresti.
Crawl personalizzato con Playwright/Puppeteer
Ora immagina di costruire una pipeline di monitoraggio che deve fare login in una dashboard autenticata, navigare in profondità di tre livelli ed estrarre dati da un sito che renderizza tutto tramite un framework JS con tempi di rendering insoliti nel DOM. Questo è il terreno naturale di Crawlee. PlaywrightCrawler ti dà i mattoni di automazione browser per gestire esattamente questo tipo di logica di navigazione personalizzata.
Crawl su larga scala con coda, retry e storage
Se stai crawlando decine di migliaia di URL e ti servono logiche automatiche di retry, persistenza della coda di richieste e output strutturato dei dati, le astrazioni native di Crawlee per request queue e dataset sono pensate proprio per questa scala. Questo non è davvero il caso d’uso dell’estensione browser di Thunderbit — quello è uno strumento da una pagina alla volta (o, al massimo, con sottopagine compatibili), non un sistema di gestione code.
Chiamare l’estrazione da un agente AI
Questo è lo scenario che spesso viene frainteso in questi confronti. Gli sviluppatori che costruiscono workflow con agenti AI a volte danno per scontato che "l’agente AI ha bisogno di dati" significhi automaticamente "scrivi codice Crawlee personalizzato e incapsulalo come tool". È una strada valida. Ma l’MCP Server di Thunderbit esiste proprio per permettere a un host AI — Claude, Cursor e altri client compatibili — di chiamare la capacità di estrazione di Thunderbit come tool, senza che nessuno debba scrivere un crawler personalizzato. È una superficie d’uso davvero diversa rispetto al flusso one-click nel browser, e richiede configurazione, non è “clicca e basta”. Ma non è nemmeno lo stesso sforzo necessario per costruire da zero un tool basato su Crawlee.
Siti dinamici, scala e affidabilità
Qui voglio essere cauto, perché è il punto in cui spesso il marketing, me compreso in passato, tende a promettere troppo. I crawler browser di Crawlee possono eseguire JavaScript, attendere contenuti dinamici e interagire con le pagine come farebbe un utente reale — davvero utile per i siti molto orientati al rendering. Allo stesso modo, l’estensione browser di Thunderbit gira in un contesto di browser reale e può funzionare con pagine renderizzate in JavaScript che hai aperto.
Ma nessuno dei due strumenti garantisce il successo ovunque. Crawlee dà agli sviluppatori gli strumenti per configurare rotazione dei proxy e session pool da soli — è un controllo manuale e regolabile, non un bypass automatico. Thunderbit applica rendering gestito e gestione anti-bot sulle pagine supportate e autorizzate, che anche in questo caso non significa “funziona su tutto” in senso assoluto. Se stai leggendo un confronto che promette il 100% di successo contro qualsiasi sistema anti-bot su internet, quel confronto ti sta mentendo, senza troppi giri di parole.
Prezzi, licenza e costo totale
Crawlee in sé è gratuito e open-source — la versione Python, per esempio, è distribuita con licenza Apache 2.0. Ma “gratuito” non vuol dire “senza costi”. Paghi in tempo di sviluppo per scrivere e mantenere i crawler, in costi di hosting (i tuoi server o la piattaforma di Apify, che è un prodotto a pagamento separato dalla libreria) e in eventuali servizi proxy se i siti target richiedono la rotazione degli IP per evitare blocchi.
Thunderbit usa un modello in abbonamento/piano con utilizzo basato su crediti — ti rimando direttamente alla pagina Thunderbit Pricing, perché questi valori cambiano e non voglio citare numeri che potrebbero essere già superati quando leggerai questo articolo.
Il confronto onesto sulla manutenzione: i crawler Crawlee si rompono quando il sito target cambia markup, perché i tuoi selettori sono stati scritti per una struttura DOM specifica. Qualcuno deve accorgersi del problema e correggere il codice. L’estrazione agentica di Thunderbit riesamina la pagina a ogni esecuzione, riducendo — non eliminando — questo tipo di rottura: un cambiamento importante nel layout del sito può comunque creare problemi, ma non stai mantenendo selettori hardcoded nello stesso modo.
Chi dovrebbe scegliere Thunderbit?
Se non sei uno sviluppatore e ti servono dati strutturati da pagine web — per liste di lead, prezzi dei concorrenti, ricerche di mercato, qualunque cosa — Thunderbit è costruito proprio per la tua situazione. Lo stesso vale se sei uno sviluppatore che vuole mettere uno strumento di estrazione self-service nelle mani di un team non tecnico, oppure se vuoi accesso programmatico tramite Open API senza scrivere da zero un crawler completo.
Chi dovrebbe scegliere Crawlee?
Se stai costruendo una pipeline dati di produzione che richiede logiche di navigazione personalizzate, controllo granulare su retry e proxy, e vuoi possedere il codice sorgente dall’inizio alla fine, Crawlee è la base giusta. È anche la scelta migliore se il tuo crawl deve davvero operare su larga scala — decine di migliaia di pagine con gestione della request queue — che non è il tipo di problema per cui è stato pensato un workflow da estensione browser.
I team possono usare entrambi?
In pratica, sì, e non credo sia una risposta di comodo. Ho visto questo schema in molte aziende con cui ho lavorato: l’ingegneria gestisce una pipeline basata su Crawlee per i job di crawl ricorrenti, strutturati e su larga scala che alimentano il data warehouse, mentre i team sales, marketing o operations usano l’estensione browser o la Web App di Thunderbit per i task ad hoc del tipo "mi serve subito i dati di questa pagina", che altrimenti finirebbero come ticket nel backlog dell’ingegneria. Non esiste un’integrazione ufficiale che leghi i due strumenti in un unico flusso — non me la inventerò — ma dal punto di vista architetturale risolvono problemi adiacenti abbastanza bene, e quindi molte aziende finiscono per usarli entrambi.
Verdetto
Se sei uno sviluppatore che sta costruendo qualcosa destinato a vivere in una codebase, scalare a migliaia di pagine o gestire logiche di navigazione davvero personalizzate, Crawlee ti dà il controllo per farlo — al prezzo del tuo tempo e della manutenzione continua. Se invece sei chiunque altro e vuoi estrarre dati da una pagina web senza scrivere codice, oppure sei uno sviluppatore che vuole esporre l’estrazione come tool per un agente AI senza costruire un crawler da zero, Thunderbit è la strada più rapida. Nessuno dei due strumenti è "migliore" in assoluto. Risolvono problemi diversi per persone diverse, e scegliere quello sbagliato per il tuo caso è davvero l’unico errore da evitare.
FAQ
Crawlee è la stessa cosa di Apify? No. Crawlee è la libreria open-source per il crawling mantenuta dal team di Apify. Apify è una piattaforma cloud separata che può ospitare ed eseguire progetti basati su Crawlee, insieme ad altri servizi come proxy e scheduling. Sono prodotti correlati ma distinti, con modelli di prezzo diversi.
Crawlee è gratuito? La libreria in sé è gratuita e open-source (la versione Python usa la licenza Apache 2.0). I costi reali arrivano dal tempo degli sviluppatori, dall’infrastruttura di hosting e da eventuali servizi proxy necessari — non da una fee di licenza.
Thunderbit supporta accesso API e MCP per gli sviluppatori? Sì. Oltre all’estensione del browser, Thunderbit offre una Open API per l’accesso programmatico e un MCP Server che consente agli host AI compatibili di chiamare direttamente gli strumenti di estrazione di Thunderbit.
Quale è più facile per chi non sa programmare? Thunderbit, senza alcun dubbio. Il flusso One Click Extract dell’estensione browser non richiede codice, né selettori, né configurazione di uno schema. Crawlee parte invece assumendo familiarità con JavaScript/TypeScript o Python.
Quale strumento dà più controllo su comportamento del crawler come retry e proxy? Crawlee, di gran lunga. Espone session pool, rotazione dei proxy, gestione della request queue e logica di retry come primitive configurabili per gli sviluppatori. Thunderbit gestisce tutto dal proprio lato, scambiando questo controllo manuale con semplicità e velocità.
