كل بضعة أشهر، يطرح أحد زملائنا السؤال نفسه في Slack: «هل نكتفي ببناء Spider على Scrapy لهذا؟» وفي كل مرة، تكون إجابتي مرتبطة بالكامل بالشخص الذي يسأل وبما يحاول إنجازه. وهذه تقريبًا خلاصة المقال، لكن دعوني أستحق راتبي فعلًا وأوضح لماذا.
قضيت الجزء الأكبر من عشر سنوات في SaaS والأتمتة — بدأت في Automation Anywhere حيث كنت أرى الشركات تؤتمت كل شيء ما عدا الجزء الذي لا يزال فيه شخص ينسخ البيانات يدويًا من موقع ويب، وأعمل الآن على بناء Thunderbit، حيث إن «النسخ من موقع ويب» هو بالضبط المشكلة التي نحاول إنهاءها. أما Scrapy، فقد كان يعمل بهدوء على تشغيل خطوط بيانات الإنترنت منذ زمن بعيد قبل أن يصبح مصطلح «agentic AI» شيئًا يتداوله الناس على العشاء. ومقارنة الاثنين ليست في الحقيقة Thunderbit مقابل Scrapy بمعنى اختيار فائز. الأمر أقرب إلى مقارنة سكين جيب سويسري بورشة آلات متكاملة — كلاهما يوصلك إلى قطعة معدن مقصوصة، لكن الطريقة، والمهارة المطلوبة، والفوضى التي ستنظفها بعد ذلك تختلف تمامًا.
الإجابة السريعة
إذا أردت الزبدة قبل الغوص في التفاصيل: Thunderbit هو Web Scraper مُدار وذكي — تفتح الصفحة، تنقر مرة واحدة، وهو يتولى فهم البنية بدلًا منك، سواء كنت تعمل عبر المتصفح أو Web App أو Open API أو MCP Server أو سطر الأوامر CLI. أما Scrapy فهو إطار Python ناضج ومفتوح المصدر — أنت تكتب الـ spider، وتحدد الـ selectors، وتبني الـ pipeline، وتتحمل كل سطر كود يتعامل مع بياناتك.
ولا واحد منهما «أفضل» بشكل مطلق. كل واحد مصمم لأشخاص مختلفين يحلون مشكلات مختلفة، وبصراحة، السبب الذي جعلني أكتب هذا المقال بشكل كامل هو أن المقالات المقارنة غالبًا تختصر كل شيء إلى حكم سطحي واحد.
نظرة سريعة
هذا هو الجدول الذي كنت أتمنى أن أجده أول مرة بحثت فيها عن مقارنة مثل هذه. كل مقال من نوع «Thunderbit vs Scrapy» وجدته إما يدفن الأداتين داخل مقارنة أوسع بين Scrapy وBeautifulSoup أو يقدّم لك بطاقة تعريفية سطحية بلا تقييم حقيقي. لذلك بنينا النسخة الفعلية.
| البعد | Scrapy | Thunderbit |
|---|---|---|
| ما هو | إطار Python مفتوح المصدر (spiders، pipelines، middleware، محرك غير متزامن) | Web Scraper ذكي بلا كود — إضافة متصفح، Web App، Open API، MCP Server، CLI |
| الإعداد | تثبيت بيئة Python، كتابة spider، تحديد selectors، إعداد pipeline | افتح الصفحة المستهدفة، وانقر One Click Extract — يبدأ الاستخراج تلقائيًا على الصفحات المتوافقة والمصرح بها (مع خيار Run Now) |
| المهارة المطلوبة | Python، وXPath/CSS selectors، ومفاهيم async | لا حاجة لكتابة كود في مسار المتصفح؛ أما API/CLI/MCP فتحتاج إعدادًا تقنيًا معتادًا |
| محتوى JavaScript/الديناميكي | يحتاج إلى scrapy-playwright أو تكامل بنمط Selenium | يعمل من الصفحة المعروضة أصلًا في المتصفح، بما في ذلك بعض الجلسات المسجّل الدخول بها والمدعومة — لكنه ليس مضمونًا في كل موقع |
| التعامل مع مضادات الحظر | middleware يدوي (تبديل proxies، كشف الحظر)، ولا يوجد تجاوز مضمون | عرض مُدار على الصفحات المصرح بها والمدعومة، ولا يوجد أيضًا تجاوز مضمون |
| التوسع/المهام المتكررة | مصمم لعمليات زحف كبيرة وقابلة للبرمجة والجدولة | تتوفر الجدولة حيث تدعمها الخطة/الواجهة؛ وهو أنسب للمهام المستهدفة أو متوسطة الحجم |
| التصدير | مخصص بالكود (JSON، CSV، قاعدة بيانات، pipelines) | تصدير إلى وجهات مدعومة مثل Excel وGoogle Sheets وAirtable وNotion، بالإضافة إلى صيغ تنزيل |
| الصيانة | الـ spiders تتعطل عند تغيّر التصميم؛ وتحتاج وقتًا من المطور لإصلاحها | الاستخراج المدعوم بالذكاء الاصطناعي يتكيّف مع بعض تغيّرات التخطيط، لكنه ليس محصنًا من الانكسار البنيوي |
| نموذج التكلفة | مجاني/مفتوح المصدر + وقت تطوير + استضافة + تكاليف proxy | اشتراك/نظام أرصدة — راجع صفحة الأسعار قبل ذكر أي أرقام |
ما هو Thunderbit؟
بدأ Thunderbit من ملاحظة مزعجة جدًا: أغلب الناس الذين يحتاجون بيانات من الويب ليسوا مطورين، ومعظم الأدوات التي تجمع البيانات من الويب تفترض أنك مطور. هذه الفجوة هي تقريبًا سبب وجودنا كله.
مسار المتصفح الأساسي مصمم ليكون بسيطًا إلى حد مريح. تفتح الصفحة التي تريد البيانات منها، تنقر One Click Extract، ويتولى الوكيل الباقي — يقرأ الصفحة، ويفهم ما يمكن استخراجه (قوائم منتجات، إعلانات وظائف، معلومات تواصل، أي شيء ظاهر على الشاشة)، ويجهز الحقول تلقائيًا. يوجد زر Run Now إذا أردت البدء فورًا، لكن إن جلست فقط تشرب قهوتك فسيبدأ الاستخراج من تلقاء نفسه. لا selectors، ولا كتابة schema، ولا رحلة أثرية في "inspect element".
وبجانب مسار المتصفح بنقرة واحدة، يمتد Thunderbit عبر واجهات أخرى بحسب ما تبنيه:
- Chrome Extension مناسبة لحالة: «أنا أنظر الآن إلى هذه الصفحة وأريد هذه البيانات».
- Web App تغطي الجمع السحابي والمهام المتكررة لمستخدمي الأعمال الذين لا يريدون لمس الكود.
- Open API يوفّر نقاط نهاية Distill وExtract المهيكلة لسير العمل الخلفي وتطبيقات البرمجة.
- MCP Server يسمح لوكلاء الذكاء الاصطناعي في Claude أو Cursor أو Windsurf باستدعاء Thunderbit مباشرة كأداة.
- CLI مخصص للمطورين ووكلاء البرمجة الذين يعيشون داخل الطرفية.
كما يتعامل مع التصفح الصفحي pagination وإثراء الصفحات الفرعية subpage enrichment في المواقع المتوافقة، ويمكنك تحسين الحقول بتعليمات بلغة طبيعية بدل regex. ولا شيء من هذا يضمن النجاح المثالي على كل موقع في العالم — سأكون صريحًا بشأن ذلك لاحقًا — لكنه مصمم بحيث لا يضطر موظف عمليات المبيعات أو محلل العقارات إلى فتح محرر أكواد.
ما هو Scrapy في 2026؟
Scrapy ليس أداة قديمة منسية. فالموقع الرسمي لـScrapy يعرض الإصدار 2.17.0 كإصدار مستقر حالي، والمشروع ما زال يصدر تحديثات — وآخر إصدار أضاف حتى دعم HTTP/2 وSOCKS proxy في مسار download handler. هذه ليست قصة «الذكاء الاصطناعي قتل الإطار القديم». Scrapy لا يزال حيًا جدًا، وبصراحة، ما زال ممتازًا فيما يفعل.
في جوهره، Scrapy إطار Python مبني حول محرك زحف غير متزامن. أنت تكتب صنف Spider، تحدد روابط البداية (أو دالة start)، ثم يطلق Scrapy Requests مع دوال callback تعالج الاستجابة. بعد ذلك تختار البيانات باستخدام CSS أو XPath selectors (أو regex إذا كنت من محبي الطرق القديمة)، وتعبئها داخل Items، ثم تمررها عبر pipelines للتنظيف والتحقق والتخزين. وتشرح وثائق النظرة العامة الرسمية هذه الدورة كاملة، وهي فعلًا نظام أنيق عندما تتقنه.
وما تحصل عليه مقابل هذا الاستثمار في التعلم هو تحكم حقيقي: cookies والجلسات، مسارات المصادقة، التخزين المؤقت، احترام robots.txt، حدود عمق الزحف، وAutoThrottle حتى لا ينتهي بك الأمر محظور IP بسبب مسؤول خادم غاضب. وهناك أيضًا منظومة واسعة من middleware والامتدادات — تدوير proxy، download handlers مخصصة، أدوات مراقبة، ومؤخرًا إضافات للرندر المبني على Playwright وحتى أدوات مساعدة لوكلاء البرمجة بالذكاء الاصطناعي التي تولد لك هيكل spider الأولي.
وهنا نقطة مهمة بالدقة: محرك Scrapy الأساسي هو زاحف HTTP، وليس متصفحًا. فهو لا يعرض JavaScript بنفسه. إذا احتجت ذلك، ستلجأ إلى scrapy-playwright أو middleware على نمط Selenium أو خدمة رندر خارجية. هذا ليس عيبًا بحد ذاته — بل قرار تصميمي متعمد يجعل الإطار خفيفًا وسريعًا — لكنه يعني أن «التعامل مع موقع يعتمد على JS بشكل كبير» هو قرار مشروع، لا سلوكًا افتراضيًا.
الفرق الجوهري: سير عمل مُدار ذكي مقابل إطار تملكه أنت بالكود
الوقت حتى أول مجموعة بيانات
لن أخترع أرقامًا من عندي — رأيت كثيرًا من المقالات تزعم أن لدى Scrapy "منحنى تعلم حاد" من دون أن تعرض أي دليل. بدلًا من ذلك، دعونا نعدّ الخطوات الفعلية فقط.
مسار Scrapy، مثلًا لجمع بيانات صفحة قوائم منتجات:
- إعداد بيئة Python افتراضية وتثبيت Scrapy.
- توليد spider من قالب.
- فحص HTML للصفحة وكتابة XPath/CSS selectors لكل حقل.
- إعداد item pipeline للتنظيف والتصدير.
- تشغيل الـ spider، ثم تصحيح أخطاء عدم تطابق selectors، ثم إعادة التشغيل.
مسار Thunderbit لنفس المهمة:
- افتح الصفحة في المتصفح.
- انقر One Click Extract.
- يتعرف الوكيل على الحقول القابلة للاستخراج ويبدأ التشغيل تلقائيًا (أو تضغط Run Now).
هذه خمس خطوات مع بيئة Python مقابل ثلاث خطوات بلا أي إعداد بيئة. لا أقول إن عدد الخطوات هو المعيار الوحيد — فخطوات Scrapy الخمس تمنحك تحكمًا أكبر بكثير في كل ما يحدث — لكن إذا كان هدفك حرفيًا «أريد هذا الجدول في Spreadsheet اليوم»، ففرق الخطوات هو القصة كلها.
التحكم وقابلية التوسعة
هنا يتقدم Scrapy، وسيكون من الظلم أن أتصرف وكأنه لا يتقدم. لأنك تملك الكود المصدري، يمكنك بناء أي شيء تقريبًا: منطق إعادة المحاولة المخصص، أنماط التصفح الصفحي الغريبة، مصادقة متعددة الخطوات، التكامل مع مستودع البيانات الحالي لديك، أيًا كان ما تتطلبه بنيتك. أما Thunderbit فنهجه الذكي يركز على «الحصول على بيانات مهيكلة بسرعة دون كتابة كود»، وهذا يعني بحكم التعريف أنه يتخذ قرارات نيابةً عنك بدل أن يفتح لك كل المقابض. بالنسبة لـ80% من مهام استخراج البيانات في الأعمال، هذه صفقة ممتازة. أما الـ20% المتبقية — منطق الزحف المخصص والغريب فعلًا — فأنت تريد إطارًا يمكنك تشكيله كما تشاء.
الصيانة وملكية التشغيل
الـ spiders تتعطل. وهذا ليس تقليلًا من Scrapy — فكل أداة استخراج، سواء كانت ذكية أو مكتوبة يدويًا، خاضعة للموقع الذي تستهدفه. لكن عندما يتعطل spider في Scrapy لأن الموقع أعاد تصميم HTML، يجب على أحد أفراد فريقك أن يلاحظ المشكلة ويشخّصها ويصلحها. وهذا وقت تطوير حقيقي، في كل مرة.
يمكن لاستخراج Thunderbit المدعوم بالذكاء الاصطناعي أن يتكيف مع بعض تغييرات التخطيط تلقائيًا لأنه يستنتج بنية الصفحة بدل مطابقة مسار selector ثابت. ومع ذلك، أريد أن أكون مباشرًا معك: هذا ليس حصانة. فالتغييرات البنيوية الكبيرة جدًا قد تربكه أيضًا. الفرق هنا يتعلق أكثر بمن يقوم بعملية التكيّف — خوارزمية تحاول التخمين بأفضل شكل، أم مطور يعيد كتابة XPath يدويًا الساعة 11 ليلًا.
سيناريوهات عملية
دليل أو جدول منتجات لمرة واحدة
إذا كنت تحتاج إلى جدول بقوائم مطاعم أو أسعار منتجات أو تفاصيل فعاليات من صفحة واحدة أو قائمة قصيرة من الصفحات، فإن إنشاء مشروع Scrapy يكون مبالغة حقيقية — ستكتب spider ستستخدمه مرة واحدة ثم لن تلمسه مجددًا. هذه مساحة Thunderbit بامتياز: افتح، انقر، استخرج، صدّر إلى Google Sheets، وانتهى الأمر.
زحف مخصص واسع مع قواعد عمل
الآن تخيل أنك تحتاج إلى الزحف عبر 50,000 صفحة منتج عبر اثني عشر نطاقًا، وتطبيق منطق إزالة التكرار المخصص، ثم دفع كل شيء إلى نموذج تسعير خاص. هذا هو ملعب Scrapy الطبيعي. بنية الـ pipeline، وأدوات التحكم بالتوازي، ونظام middleware — كل ذلك موجود تحديدًا لمهام بهذا الحجم وبهذا القدر من المنطق المخصص.
موقع ديناميكي يعتمد على JavaScript
كلا الأداتين تحتاجان إلى مساعدة هنا، لكن من نوع مختلف. Scrapy يحتاج إلى تكامل رندر صريح مثل scrapy-playwright مضافًا يدويًا، وهذا يعني اعتمادًا إضافيًا ومساحة صيانة مستمرة. أما إضافة Thunderbit للمتصفح فتعمل على الصفحة كما هي معروضة بالفعل داخل متصفحك — بما في ذلك بعض الجلسات المسجّل الدخول بها والمدعومة — وهذا يتجاوز كثيرًا من ذلك الإعداد. لكنني أريد أن أوضح: لا يوجد أي من النهجين ضمان للفوز أمام أنظمة مكافحة الروبوت العدوانية أو أنماط المحتوى الديناميكي غير المعتادة. من يقول لك غير ذلك فهو يبيع شيئًا.
تكامل مع وكيل ذكاء اصطناعي أو تطبيق
إذا كنت تبني سير عمل لوكيل AI في Claude أو Cursor وتريد منه جلب بيانات ويب حيّة كجزء من حلقة التفكير، فإن كتابة تكامل مخصص مع Scrapy يتطلب جهدًا كبيرًا. أما MCP Server في Thunderbit فمبني لهذا الغرض تحديدًا — إذ يعرّض الاستخراج كأداة يمكن للوكيل استدعاؤها مباشرة.
الدقة، والتوسع، والصيانة
دقة Scrapy حتمية بأفضل معنى للكلمة — selector مكتوب جيدًا يسحب بالضبط الحقل الذي طلبته، في كل مرة، إلى أن يتغير HTML الأساسي. هذا التنبؤ مفيد جدًا لخطوط الإنتاج التي تحتاج إلى معرفة دقيقة لسبب الفشل.
أما اكتشاف Thunderbit الذكي فيعمل بطريقة مختلفة. فهو يفسر الصفحة كما ينظر إليها الإنسان ويقرر ما الذي يبدو على الأرجح أنه السعر أو العنوان أو الوصف. وهذا مفيد جدًا للسرعة والمرونة، لكنه نموذج دقة مختلف — أقرب إلى «صحيح غالبًا، ويحتاج أحيانًا إلى دفعة صغيرة» بدل «يطابق دائمًا ما يقوله selector حرفيًا». وأفضّل أن أكون صريحًا بشأن هذه المقايضة بدل الادعاء بأن الاستخراج المعتمد على الذكاء الاصطناعي بلا عيوب.
من ناحية الإنتاجية الخام، تم تصميم المحرك غير المتزامن في Scrapy ليمر عبر أحجام ضخمة من الطلبات بكفاءة — وهذا فعلًا جزء من حمضه النووي التصميمي. أما Thunderbit فهو مضبوط أكثر للمهام المستهدفة متوسطة الحجم حيث يكون الحصول على نتيجة مهيكلة ونظيفة بسرعة أهم من الزحف عبر مليون صفحة خلال الليل. إذا كنت تخطط لزحف ضخم جدًا، فتحقق من حدود الخطة الحالية قبل أن تفترض أن أي أداة ستتوسع بالطريقة التي تحتاجها.
ونقطة أخيرة تنطبق على الاثنين: الاستخدام المصرح به مهم. أيًا كانت الأداة التي تختارها، فإن احترام robots.txt وشروط الموقع والقانون المطبق ليس اختياريًا — بل جزء من العمل المسؤول.
التسعير، والترخيص، والتكلفة الحقيقية
هناك فخ أراه يتكرر باستمرار: معاملة «مجاني» و«بدون تكلفة» وكأنهما الشيء نفسه. Scrapy لا يفرض رسوم ترخيص — فهو مفتوح المصدر، نقطة انتهى. لكن البرامج «المجانية» ما زالت تحتاج إلى مكان لتعمل فيه، وذلك المكان يكلف مالًا: استضافة، خدمات proxy إذا كنت تعمل بحجم جاد، أدوات أتمتة متصفح إذا كنت تحتاج رندر JavaScript، مراقبة حتى تعرف متى يموت spider بصمت، والأهم من ذلك كله — وقت المطور لبنائه واختباره وإصلاحه عندما يتعطل.
أما Thunderbit فيعمل بنموذج اشتراك/أرصدة، وأفضّل أن أشير إلى صفحة الأسعار الرسمية بدلًا من الاعتماد على أي رقم أذكره هنا، لأن هياكل الأسعار تتغير، وأود أن ترى الشروط الحالية مباشرة. ما الذي يشتريه لك هذا الاشتراك؟ إنه يزيل معظم عبء الإعداد والصيانة — على الأقل في تدفقات العمل المدعومة.
السؤال الحقيقي ليس: «أيّهما أرخص على الورق؟» بل: «ما العملة التي يملكها فريقك أكثر — ساعات المطورين أم ميزانية الاشتراك؟» فريق هندسة بيانات من خمسة أشخاص لديه وقت فائض قد يجد أن التكلفة الإجمالية لـScrapy أقل عندما تضع في الحسبان مهاراتهم الحالية. أما فريق عمليات من ثلاثة أشخاص بلا مهندسين داخليين فسيجد أن إطارًا «مجانيًا» يكلفه فاتورة متعاقد وثلاثة أسابيع من التأخير قبل رؤية أول صف بيانات.
من ينبغي أن يختار Thunderbit؟
يكون Thunderbit الأكثر منطقية إذا كنت مشغلًا غير تقني — في المبيعات أو التسويق أو التجارة الإلكترونية أو العقارات أو التوظيف — وتحتاج إلى بيانات مهيكلة الآن، ولا تريد فتح تذكرة هندسية للحصول عليها. كما أنه خيار جيد للمطورين الذين يريدون وصولًا برمجيًا دون بناء منطق الاستخراج من الصفر، لأن Open API وCLI يتوليان هذه الطبقة بدلًا منك. إذا كانت سير العمل لديك تشمل توليد العملاء المحتملين أو مراقبة التجارة الإلكترونية أو استخراج بيانات LinkedIn لأغراض التوظيف، فهذا عادةً هو الطريق الأسرع.
من ينبغي أن يختار Scrapy؟
Scrapy هو الاختيار الصحيح إذا كان لديك مطورو Python ضمن الفريق، وتبني بنية زحف يجب أن تعيش لسنوات، وتحتاج إلى تحكم كامل في منطق الطلبات وسلوك إعادة المحاولة وخطوط البيانات. كما أنه الأنسب إذا كانت متطلبات الامتثال أو المعمارية تعني أن الكود يجب أن يكون ملكك بالكامل — قابلًا للتدقيق، ومستضافًا ذاتيًا، ومن دون اعتماد خارجي.
هل يمكن للفرق استخدام الاثنين معًا؟
كثير من الفرق يفعل ذلك، ولا أعتبر هذا جوابًا مراوغًا. يمكن للمطورين تشغيل spiders Scrapy قوية ودائمة لبنية الزحف التي يجب أن تبقى موجودة دائمًا، بينما يستخدم باقي الفريق Thunderbit للبحث العارض، وسحب البيانات لمرة واحدة، والعمل الاستكشافي الذي لا يستحق Sprint هندسيًا كاملًا. لا يوجد تكامل رسمي بين الأداتين — وأريد أن أكون واضحًا بشأن ذلك — لكن عمليًا لا شيء يمنعك من تشغيلهما جنبًا إلى جنب بحسب ما يناسب كل مهمة.
الحكم النهائي
إذا اضطررت لتلخيص الأمر في سؤال واحد مباشر: هل أنت تحسن الكفاءة من أجل التحكم أم من أجل السرعة؟ Scrapy يمنحك تحكمًا كاملًا مقابل وقت إعداد وصيانة مستمر. Thunderbit يمنحك سرعة وسهولة وصول مقابل قدر أقل من المرونة. ولا واحد منهما هو الجواب الصحيح بشكل مطلق — الأمر يعتمد على ما إذا كان الشخص الذي يجمع البيانات يعرف Python أم يعرف مسار المبيعات لديه. ولمزيد من التفاصيل حول كيفية مقارنة الاستخراج المعتمد على الذكاء الاصطناعي بالطرق التقليدية عمومًا، تغطي مقالاتنا عن AI web scraping وweb scraping without coding المشهد الأوسع beyond هذه المقارنة فقط.
الأسئلة الشائعة
هل Scrapy مجاني؟ إطار Scrapy نفسه مفتوح المصدر ولا يفرض رسوم ترخيص، وفقًا للموقع الرسمي لـScrapy. التكاليف الفعلية تأتي من الاستضافة، وproxies، وأدوات الرندر إذا كنت تحتاج دعم JavaScript، ووقت المطور لبناء الـ spiders وصيانتها.
هل يعرض Scrapy JavaScript من تلقاء نفسه؟ لا. جوهر Scrapy هو زاحف HTTP وليس متصفحًا، لذلك لا ينفذ JavaScript تلقائيًا. عادةً ما تضيف الفرق scrapy-playwright أو middleware بأسلوب Selenium عندما تحتاج إلى استخراج مواقع تعتمد على JS بكثافة، وفقًا لـوثائق Scrapy الرسمية.
هل يدعم Thunderbit الوصول عبر API وMCP؟ نعم. يوفّر Thunderbit Open API مع نقاط نهاية Distill وExtract المهيكلة للاستخدام البرمجي، ومخدم MCP يتيح لوكلاء الذكاء الاصطناعي في أدوات مثل Claude وCursor استدعاء Thunderbit مباشرة.
أيّهما أسرع لمستخدمي الأعمال؟ Thunderbit، بطبيعته. مسار One Click Extract في إضافة المتصفح يبدأ الاستخراج تلقائيًا بعد تحليل الصفحة، من دون selectors أو إعداد schema — وهو طريق أقصر بكثير من تثبيت Python وكتابة spider.
أيّهما أفضل للزحف شديد التخصيص؟ Scrapy. فـmiddleware، وبنية pipeline، والوصول الكامل إلى الكود المصدري تمنح المطورين التحكم اللازم لمنطق زحف شديد الخصوصية، ومهام مجدولة واسعة النطاق، وخطوط بيانات مخصصة لا صُمم الوكيل الذكي ليحل محلها.
