Ho passato abbastanza tempo nei thread Slack dei team di engineering per sapere come nasce di solito questa domanda: qualcuno condivide un link a una classifica dei “migliori web scraper” e tre ingegneri rispondono subito: “nessuno di questi cita Colly”. Non è un caso. Ho analizzato i quattro articoli che oggi si posizionano per “Thunderbit vs Colly” e tutti, senza eccezioni, mettono Thunderbit a confronto con altri tool no-code — Crawl4AI, Browse AI, rtrvr.ai, Chat4Data. Colly non compare nemmeno una volta.
Ed è piuttosto curioso, perché Colly ha davvero una community fedele su r/golang e nelle realtà Go che hanno bisogno di crawler veloci, basati su codice e sotto il proprio controllo. Questo, quindi, è l’articolo che risponde davvero alla domanda — non l’ennesimo confronto tra strumenti AI con il nome di Colly incollato sopra.
Risposta veloce
Se hai poco tempo, ecco la versione breve: Thunderbit è uno scraper web gestito e agentico, pronto all’uso con un clic — niente selector, niente codice, esecuzione nel browser o nel cloud, più una Web App, una Open API, un MCP Server e una CLI per quando gli sviluppatori vogliono un accesso programmatico. Colly invece è un framework Go open source: scrivi tu il crawler, controlli tu la logica, ottimizzi tu la concorrenza.
In realtà non sono veri concorrenti nel senso classico del termine. Uno è un prodotto. L’altro è una libreria. Metterli uno contro l’altro ha senso solo se ti trovi davanti a un bivio e devi capire quale strada si adatta davvero al tuo caso — ed è esattamente quello che voglio aiutarti a fare.
In breve
| Dimensione | Thunderbit | Colly |
|---|---|---|
| Utente principale | Utenti business, team operations, sviluppatori che vogliono velocità | Sviluppatori Go |
| Configurazione | Clicca One Click Extract su una pagina | go get github.com/gocolly/colly + scrivi codice Go |
| Tempo per il primo risultato | Da pochi secondi a pochi minuti, l’agente parte da solo | Dipende da quanto velocemente scrivi i callback |
| Linguaggio | Nessuno richiesto per l’uso da browser | Go |
| Modello di crawling | Analisi agentica della pagina, compatibile con paginazione e sottopagine | Collector manuale + callback OnHTML/OnResponse |
| Rendering | Browser gestito / esecuzione cloud | Principalmente HTTP/HTML; i siti molto basati su JS richiedono strumenti aggiuntivi |
| Regole di estrazione | L’agente propone i campi, l’utente può rifinirli | Lo sviluppatore scrive a mano i selettori CSS |
| Concorrenza | Gestita dalla piattaforma | Controllo manuale completo tramite goroutine |
| Storage/export | Export verso fogli di calcolo, spreadsheet e altre destinazioni supportate | Costruito dallo sviluppatore (file, database, Redis, ecc.) |
| Distribuzione | Estensione browser, Web App, API, MCP, CLI | Binario/script Go self-hosted |
| Manutenzione | Logica di estrazione gestita; resta comunque dipendente dalla compatibilità del sito | Lo sviluppatore aggiorna i selettori quando il sito cambia |
| Licenza/costo | Piani a crediti (verifica i livelli attuali su pricing) | Apache-2.0, gratuito — ma infrastruttura e tempo di sviluppo no |
Cos’è Thunderbit?
Il flusso predefinito di Thunderbit è davvero a un clic. Apri una pagina a cui sei autorizzato ad accedere, premi One Click Extract e l’agente legge la pagina, capisce cosa vale la pena estrarre e propone i campi. C’è un pulsante Run Now, ma a dire il vero serve soprattutto a tranquillizzarti — se non tocchi nulla, l’estrazione parte da sola. Niente definizione di selector, niente configurazione dello schema, nelle pagine supportate dall’agente.
Da lì puoi rifinire i campi se l’agente non li ha centrati al primo colpo e, sui siti compatibili, può seguire la paginazione o scendere nelle sottopagine per arricchire i dati — per esempio recuperando dettagli aggiuntivi da ogni scheda prodotto in un elenco. Una volta ottenuti i dati, l’export va verso le destinazioni più comuni: Excel, Google Sheets e altre destinazioni supportate.
Ma l’estensione browser è solo la porta d’ingresso. Se sei uno sviluppatore, hai la Open API per avviare l’estrazione dal tuo codice, l’MCP Server per integrare l’estrazione in Claude, Cursor o Windsurf come strumento richiamabile, e la CLI per flussi di lavoro da terminale o con coding agent. Lo sottolineo perché spesso il classico schema “no-code vs code” presenta Thunderbit come un giocattolo solo per business user, e ormai non è più una descrizione corretta.
Cos’è Colly?
Colly è una libreria Go, punto. Nessuna dashboard, nessun servizio hosted, nessun livello AI che decide cosa estrarre. Scrivi in Go, crei un Collector e colleghi callback come OnHTML e OnResponse per dirgli esattamente cosa fare quando incontra una pagina.
Più o meno funziona così:
c := colly.NewCollector()
c.OnHTML("a[href]", func(e *colly.HTMLElement) {
link := e.Attr("href")
c.Visit(e.Request.AbsoluteURL(link))
})
c.OnResponse(func(r *colly.Response) {
fmt.Println("Visited", r.Request.URL)
})
c.Visit("https://example.com")
Questo è l’intero modello mentale: definisci cosa cercare, definisci cosa fare quando lo trovi, e lasci che il collector faccia crawling. Sotto il cofano hai crawling sincrono, asincrono e parallelo, rate limiting per dominio, gestione automatica di cookie e sessioni, caching delle richieste, rispetto di robots.txt, rotazione dei proxy e backend di storage plug-in, incluso Redis per setup distribuiti.
Una cosa importante da chiarire subito: Colly è soprattutto un framework HTTP/HTML. Non esegue un browser completo come farebbe Playwright. Se il sito target dipende molto dal rendering JavaScript, devi o trovare l’API JSON sottostante che utilizza, oppure affiancare Colly a uno strumento separato di browser automation. Non è un difetto di Colly — è semplicemente una filosofia di design diversa rispetto a un prodotto completamente agentico e consapevole del browser.
Differenza fondamentale: estrazione agentica gestita vs framework Go basato su codice
Tempo per la prima tabella
Qui la distanza è più evidente. Con Thunderbit, il “tempo per il primo risultato” coincide con il tempo necessario per cliccare un pulsante e aspettare che l’agente finisca di leggere la pagina — da pochi secondi a un paio di minuti, a seconda della complessità. Con Colly, il “tempo per il primo risultato” include scrivere il collector, trovare i selettori giusti (di solito con un po’ di tentativi nei dev tools), gestire tu stesso la logica di paginazione e poi avviare il tutto. Per un’attività one-off, è un costo di tempo reale anche per uno sviluppatore Go competente.
Prestazioni e controllo
Su questo Colly vince, senza discussione, per controllo grezzo. Siccome la logica la scrivi tu, decidi esattamente quante goroutine girano in parallelo, quanto aggressivo è il rate limiting, cosa viene messo in cache e come vengono ritentati gli errori. La documentazione del progetto cita oltre 1.000 richieste al secondo su un singolo core per target statici adatti — è un dato di benchmark di Colly, non un confronto controllato con Thunderbit, e non farò finta che sia altro. Però dice una cosa concreta: sui target HTTP-friendly, la concorrenza Go ottimizzata a mano è molto difficile da battere.
Thunderbit rinuncia a questo livello di controllo granulare in favore di un’esecuzione gestita. Non stai ottimizzando pool di goroutine — stai affidandoti ai percorsi di esecuzione browser e cloud della piattaforma, più l’estrazione pianificata, se il tuo piano la supporta. È il compromesso giusto se non vuoi occuparti delle decisioni infrastrutturali, e quello sbagliato se il tuo lavoro consiste proprio nello spremere il massimo throughput da un crawler.
Distribuzione e responsabilità della manutenzione
Ecco la parte di cui si parla troppo poco. Colly è “gratuito” nel senso che la licenza Apache-2.0 non costa nulla. Ma qualcuno deve comunque scriverlo, ospitarlo, monitorarlo e — soprattutto — correggerlo quando il sito target cambia HTML. I selettori si rompono in silenzio. Nessuno riceve un avviso che dica “ehi, questo sito ha rifatto il product page”. Un developer deve accorgersi che la pipeline è diventata silenziosa o che ha iniziato a restituire dati sbagliati, e poi sistemarla.
Con Thunderbit, la logica di estrazione è gestita dalla piattaforma e la sua analisi agentica delle pagine è pensata per adattarsi alle variazioni di layout sulle pagine supportate e autorizzate. Però qui voglio essere preciso — non è una garanzia assoluta. Pagine fortemente protette anti-bot, contenuti dietro login fuori dall’ambito autorizzato o siti che l’agente semplicemente gestisce male sono limiti reali. Il modo corretto di leggerla è questo: con Colly, il fix è sempre sulle tue spalle. Con Thunderbit il peso è minore, ma “minore” non significa “zero” — il successo dipende comunque dal fatto che la pagina target sia ben supportata.
Scenari pratici
Estrazione one-off di directory o cataloghi prodotti
Supponiamo che tu debba ottenere entro fine giornata una tabella con 200 prodotti dalla pagina catalogo di un concorrente, e non sei uno sviluppatore (oppure lo sei, ma hai cose più importanti da fare). Questo è il terreno naturale di Thunderbit — clicchi, lasci che l’agente proponga i campi, rifinisci se serve, esporti su Sheets. Scrivere uno script Colly per una sola estrazione è tecnicamente possibile, ma è un po’ come usare una motosega per rifilare un bonsai.
Crawler Go personalizzato ad alto throughput
Adesso invertiamo la situazione: stai costruendo una pipeline di monitoraggio che visita migliaia di URL al giorno, hai già uno stack Go e ti serve un controllo preciso sulla logica di retry, sullo storage distribuito tramite Redis e sui limiti per dominio tarati per evitare blocchi. Qui siamo nel territorio di Colly. Non paghi un abbonamento, possiedi ogni riga di logica e puoi ottimizzare per i tuoi pattern di traffico in modi che un prodotto gestito non è pensato per esporre.
Target fortemente basati su JavaScript
Se il tuo target renderizza tutto lato client con pesante uso di JS, Colly da solo probabilmente non è la risposta — dovresti sfruttare le tecniche per scovare l’API JSON sottostante oppure aggiungere un layer di browser automation. I percorsi di esecuzione browser/cloud gestiti di Thunderbit sono progettati proprio per questo tipo di pagina, anche se, di nuovo, conviene testare la compatibilità sul target specifico prima di dare per scontato che funzioni subito.
Integrazione con API o AI agent
Stai costruendo uno strumento interno in cui un agente AI (per esempio in Claude o Cursor) deve recuperare dati strutturati come parte di un flusso più ampio? Qui l’MCP Server di Thunderbit diventa davvero utile — espone l’estrazione come strumento richiamabile dentro i workflow degli agenti, un caso d’uso che Colly semplicemente non copre in modo nativo, perché è una libreria standalone e non qualcosa che un AI agent può invocare come tool già pronto.
Affidabilità, scala e manutenzione
Voglio separare due concetti che spesso vengono confusi: throughput grezzo e tasso di successo complessivo sui siti reali. Colly può essere molto veloce su pagine statiche e amichevoli per HTTP — è proprio il suo scopo. Ma “veloce” non significa automaticamente “funziona ancora tra tre mesi” quando il sito target lancia un redesign. Ogni selettore che hai scritto può diventare obsoleto, e nessuno te lo segnala finché la pipeline non inizia a restituire silenziosamente valori nulli.
L’approccio agentico di Thunderbit significa che non devi mantenere tu i selettori — ma non condivido alcuna narrativa, nemmeno quella di marketing di Thunderbit, che suggerisca affidabilità universale su qualunque sito, soprattutto quelli con misure anti-bot aggressive o contenuti dietro autenticazione a cui non sei autorizzato ad accedere. Se stai valutando uno dei due strumenti, la vera domanda è: “chi lo sistema quando si rompe, e quanto tempo ci mette?” — non semplicemente “quanto è veloce il primo giorno”.
Prezzo, licenza e costo totale
Colly è open source sotto Apache 2.0 — la libreria in sé è gratuita. Ma il costo totale di proprietà include le ore di sviluppo per scrivere e debuggare il crawler, il compute per eseguirlo, il costo dei proxy se ti serve la rotazione degli IP, e il tempo continuo ogni volta che il sito target cambia e rompe i selettori. Per un team già fluente in Go, a scala può essere davvero economico. Per un team senza questa competenza in casa, “gratis” diventa presto “costoso in modi nascosti”.
Thunderbit funziona con piani a crediti — controlla la pagina pricing aggiornata, perché i livelli e le quantità di crediti sono il tipo di cosa che cambia e preferisco rimandarti alla fonte piuttosto che citare un numero che rischia di essere già vecchio quando leggi questo articolo. Il vantaggio è che stai pagando per una manutenzione pratica molto minore sulle pagine supportate, non per manutenzione zero ovunque.
Se vuoi un modello mentale onesto, costruisci una tabella semplice per il tuo caso: tempo di setup, costo di infrastruttura/proxy, tempo di correzione nel tempo e costo dell’abbonamento. Il lato che vince su quella tabella, in base alle competenze e al carico di lavoro reali del tuo team, è la tua risposta — non un generico “l’open source costa meno”.
Chi dovrebbe scegliere Thunderbit?
Se sei un business user, una persona del team operations o del growth e hai bisogno subito di dati strutturati senza toccare codice, l’estensione browser di Thunderbit è la scelta più naturale. Se invece sei uno sviluppatore che vuole usare l’estrazione come blocco di costruzione — via API, CLI o dentro un workflow con AI agent tramite MCP — Thunderbit va benissimo anche per questo, solo attraverso una porta diversa rispetto al classico clicca-e-vai.
Chi dovrebbe scegliere Colly?
Se sei uno sviluppatore Go (o il tuo team è Go-first) e ti serve un crawler personalizzato e ad alto throughput, in cui controlli ogni richiesta, ogni retry, ogni rotazione di proxy — Colly è costruito esattamente per questo lavoro. È anche la scelta giusta se vuoi possedere il codice senza dipendere da un abbonamento e hai la capacità ingegneristica per mantenerlo.
I team possono usare entrambi?
Onestamente sì, e non penso sia una risposta evasiva. È molto comune che un team di engineering gestisca un crawler Colly robusto e ad alta scala per una pipeline dati centrale, mentre altri team — sales, operations, marketing — usino Thunderbit per estrazioni ad hoc che non meritano la scrittura e la manutenzione di uno script. Non sto inventando una finta “integrazione ufficiale” tra i due — non ne conosco una — ma dal punto di vista architetturale nulla impedisce che convivano nella stessa organizzazione per risolvere problemi diversi.
Verdetto
Scegli in base a chi deve fare il lavoro e a cosa sta ottimizzando. Se hai competenze Go, hai bisogno di logica custom e vuoi assumerti la manutenzione in cambio di controllo totale e zero costo di abbonamento, Colly è lo strumento giusto. Se vuoi dati in fretta, non vuoi scrivere né mantenere codice e ti sta bene rinunciare a un po’ di controllo di basso livello in cambio di un’esperienza gestita — inclusa la possibilità di collegare l’estrazione a un’API o a un AI agent — Thunderbit è la scelta migliore. Nessuno dei due è “migliore” in assoluto; sono stati progettati per persone diverse che risolvono problemi diversi.
FAQ
Colly è gratuito? Sì — Colly è open source sotto licenza Apache 2.0, quindi la libreria in sé non costa nulla. I costi reali derivano dal tempo degli sviluppatori, dall’hosting, dai proxy se servono e dalla manutenzione continua quando i siti target cambiano.
Colly esegue il rendering JavaScript? Non nativamente. Colly è soprattutto un framework HTTP/HTML, quindi i siti molto basati su JavaScript richiedono in genere di trovare l’API JSON sottostante chiamata dalla pagina oppure di affiancare Colly a un altro strumento di browser automation.
Thunderbit supporta API e accesso MCP per gli sviluppatori? Sì. Thunderbit offre una Open API per l’estrazione programmatica e un MCP Server che espone l’estrazione come strumento richiamabile all’interno di workflow compatibili con AI agent come Claude, Cursor o Windsurf.
Quale è più veloce da avviare? Thunderbit, per design — il flusso One Click Extract dell’estensione browser ti dà un risultato in pochi secondi o minuti, senza codice. Colly richiede di scrivere e testare codice Go prima di vedere il primo risultato.
Quale offre più controllo di basso livello sul crawling? Colly, senza dubbio. Controlli la concorrenza tramite goroutine, il rate limiting delle richieste, la cache, la rotazione dei proxy e i backend di storage direttamente nel codice — un livello di tuning che un prodotto gestito come Thunderbit, per scelta, non espone.
