تقريبًا كل قائمة بعنوان «أفضل أداة كشط مفتوحة المصدر» فيها خلل بسيط لكنه مهم: ولا مرة بتشغّل الأدوات على نفس الصفحات. تلاقي Scrapy متجرب على خبر إخباري، وPlaywright على صفحة تجريبية للتجارة الإلكترونية، وColly على أي صفحة كانت قدّام الكاتب — وبعدين يحطّوهم جنب بعض كأن الأرقام دي بتتكلم عن الشيء نفسه. الحقيقة إن الترتيبات دي بتقولك عن الصفحات، مش عن الأدوات.
عشان كده عملت الشيء الواضح والممل اللي أغلب القوائم بتتجاهله. جهزت مجموعة واحدة من fixtures ومرّرت عليها الأدوات التسع كلها: كتالوج ثابت، وكتالوج بيتعرض عبر JavaScript، ومقال مخبّى وسط زحمة من شريط التنقل والتذييل، وخطأ HTTP 500 متعمد، ورسم بياني صغير لزحف الروابط الداخلية، وكمان موقعين عامّين للتدريب. نفس الحقيقة المرجعية، ونفس القياسات، في كل تشغيل. السكربتات والنتائج الخام موجودة في مستودع benchmark عام واحد بحيث تقدر تعيد تشغيل أي جزء بنفسك. والنتيجة مش لوحة ترتيب شيك زي ما بتوعدك القوائم — مفيش فائز واحد. فيه ثلاث مهام مختلفة، والأدوات التسع بتتوزع عليها تقريبًا بشكل طبيعي.
جرّب Thunderbit لاستخراج بيانات الويب
كيف عملت منصة الاختبار، والحد الوحيد اللي هشدّد عليه
كل أداة واجهت نفس أشكال fixtures: 12 منتج ثابت موزعين على صفحتين، و8 منتجات بيتحقنوا بواسطة JavaScript بعد تأخير، ومقال ملفوف بحشو من شريط التنقل والتذييل حوالين ثلاث فقرات حقيقية، وخطأ 500 متعمد من السيرفر، ورسم بياني للروابط الداخلية. التصميم ده هو اللي بيخلي النتائج قابلة للمقارنة — فعبارة «8/8 منتجات ديناميكية» معناها نفس الشيء تمامًا سواء طلّعتها Puppeteer أو Crawlee.
وهنا الحد اللي أغلب المراجعات بتتجاوزه. كل حزمة خاصة بكل أداة بتعكس نسختها هي من هذه fixtures، فمش ينفع نقارن أعداد المحارف المطلقة بين الأدوات بشكل صارم — اعتبرها إشارات داخل الأداة نفسها، مش درجة مقارنة بين الأدوات. الأرقام اللي ينفع تتقارن هي الاسترجاع (recall) — وتعامل معه كنسبة —، ونجاح/فشل JavaScript، والسلوك البنيوي. وفيه ملاحظة مهمة بنفس الروح: تشغيل Crawl4AI للكتالوج الثابت شمل الصفحة الأولى فقط، لذلك 6/6 عنده استرجاع كامل ضمن نطاق أضيق، بينما الأدوات الأخرى زحفت عبر الصفحتين وحققت 12/12 — نطاق أصغر، مش فقدان جزئي. والشرح الكامل خطوة بخطوة لكل fixture موجود في الشرح المنهجي.
وقبل الأرقام، فيه تحفظ إضافي. كل حزمة كمان فيها درجة بحثية مؤقتة، لكني مش بطبعها عمدًا كجدول ترتيب. كانت مجرد أدوات داخلية لمراجعة كل أداة مقابل أدلتها الخاصة، مش ترتيب دوري — ونشرها بالشكل ده كان هيعيد إنتاج مشكلة الدقة الزائفة نفسها اللي المشروع ده معمول عشان يتجنبها. ده تلخيص للي منصة الاختبار أظهرته، مش لوحة نتائج.
الصورة الكاملة للمجال على منصة اختبار واحدة
اقرأ العمودين الأخيرين في الجدول ده — «هل يعرض JS؟» و«طابور زحف مدمج» — وهتظهر لك المهام الثلاث بوضوح.
| الأداة | اللغة | هل تعرض JS؟ | الاسترجاع الثابت | مخرجات منظمة | طابور زحف مدمج | عبء الإعداد | الترخيص |
|---|---|---|---|---|---|---|---|
| Crawl4AI | Python | نعم (متصفح) | 6/6 (الصفحة 1) | مخطط CSS | BFS/DFS مدمج | ثقيل (حزمتا متصفح) | Apache-2.0 |
| Firecrawl | مستضافة ذاتيًا | نعم (playwright-service) | Markdown كامل | نعم | /v1/crawl | الأثقل (6 حاويات) | AGPL-3.0 |
| trafilatura | Python | لا | 3/3 للمقال | لا (نص فقط) | لا | خفيف | Apache-2.0 |
| Crawlee | Node/TS | اختياري بحسب المحرك | 12/12 | عبر الاستخراج | نعم (RequestQueue) | متوسط (+حوالي 80 MiB) | Apache-2.0 |
| Playwright | Node/متعدد | نعم | 12/12 | يدوي | لا (BFS مكتوب يدويًا) | متوسط (متصفح) | Apache-2.0 |
| Puppeteer | Node | نعم (Chrome) | 12/12 | يدوي | لا (BFS مكتوب يدويًا) | متوسط (Chrome) | Apache-2.0 |
| Scrapy | Python | لا | 12/12 | تصدير Feed (JSON/CSV/XML) | نعم (مدمج) | متوسط (اعتمادًا على Twisted) | BSD-3 |
| Colly | Go | لا | 12/12 | عبر callbacks | التحكم بالعمق | خفيف (ملف ثنائي واحد + Go) | Apache-2.0 |
| Scrapling | Python | لا (جالب HTTP) | 12/12 | نعم | لا | متوسط ([fetchers]) | BSD-3 |
ملاحظة على البيانات الوصفية في الجدول ده وفي كل اللي جاي بعده: أعداد النجوم وأرقام الإصدارات اتسجلت في أوائل يوليو 2026، ودي حاجات بتتغير بسرعة. راجعها في صفحة GitHub وصفحة الحزمة الخاصة بكل مشروع قبل ما تتعامل معاها كأنها الحالية.
فهرس مراجعات الأداة الواحدة
كل مشروع في المقارنة دي له مراجعة معمقة خاصة به:
- مراجعة Crawl4AI
- مراجعة Firecrawl
- مراجعة trafilatura
- مقارنة Playwright vs Puppeteer
- مراجعة Crawlee
- مراجعة Scrapy
- مراجعة Colly
- مراجعة Scrapling
وده أغلفة المراجعات — بالإضافة إلى لقطتين حقيقيتين من اختبار العرض عبر JavaScript، عشان عبارة «8/8 ديناميكية» ما تبقاش مجرد رقم على صفحة.
المهمة الأولى: تحويل صفحة إلى نص جاهز للنماذج اللغوية
لو اللي تحتاجه Markdown نظيف يدخل في خط أنابيب RAG، فهنا فيه ثلاث أدوات بتنافس — ومفيش اثنين شبه بعض خالص.
Crawl4AI هو، بعيدًا عن التسويق، مولّد Markdown معتمد على المتصفح. والأهم هنا إننا نشيل حكاية «الذكاء التكيفي ذاتي التعلم» اللي بتلاحقه في نتائج البحث: مفيش عنده حاجة بالشكل ده — دي حيلة مكتبة تانية مختلفة تمامًا (ورجع لها لما نوصل إلى Scrapling). اللي بيعمله فعليًا، بيعمله كويس. على موقع Books to Scrape التدريبي طلع 13,476 محرفًا من Markdown، وبيتولى الاستخراج عبر مخطط CSS للبيانات المنظمة، وكمان زحفه العميق BFS المدمج عدّى 5 صفحات في fixture الرسم البياني للزحف وهو بيعرض صفحة JavaScript ويلتقط لقطة شاشة. لكن فيه مشكلتين واضحتين. الـ Markdown الخام بيشيل حشو الصفحة إلا لو شغلت فلتر المحتوى، وخطأ 500 المتعمد رجع كـ success=false — مش لأن Crawl4AI التقط خطأ HTTP بشكل أنيق، لكن لأن heuristic المحتوى عنده بصّ على جسم الخطأ الصغير وصنفه minimal_text ... blocked. كمان الإعداد بيحط حزمتين من المتصفح على القرص. الإصدار 0.9.0، Apache-2.0، وحوالي 71 ألف نجمة في أوائل يوليو.
Firecrawl هو الأثقل وزنًا، وتشغيله محليًا/مستضافًا ذاتيًا شغال فعلًا — وبقول «شغال فعلًا» لأن الحزمة المؤلفة من ست حاويات (api وplaywright-service وredis وrabbitmq وnuq-postgres وfoundationdb) أقلعت وطلعت 9,222 محرفًا من Markdown الجاهز للنماذج اللغوية من نفس صفحة Books to Scrape. كمان عرض صفحة JavaScript عبر playwright-service المدمج، وظهر في الناتج اسم أينشتاين بعد تنفيذ السكربت، وده أثبت إن العرض حقيقي. المشكلتين اللي واجهتهما كانتا من البيئة لا من Firecrawl، وعايز أكون دقيق عشان ما حدش ينسخ الحل الغلط: البناء من المصدر اصطدم بخلل عابر في snapshotter داخل containerd تحت colima (فانتقلت للصور المسبقة البناء)، وكمان نطاق DNS الخاص بـ colima 198.18.x.x فعّل حاجز SSRF في Firecrawl، وقدرت أتجاوزه عبر ALLOW_LOCAL_WEBHOOKS=true — وده حل مؤقت للتطوير المحلي، مش حاجة لازم تتشال في أي نشر حقيقي. كمان النواة المستضافة ذاتيًا ما فيهاش Fire-engine، طبقة مكافحة الحظر السحابية، وما اختبرتش واجهة السحابة API. وأهم نقطة هي الترخيص: النواة المستضافة ذاتيًا من Firecrawl مرخصة بـ AGPL-3.0، وده محتاج مراجعة قانونية فعلية قبل أي استخدام تجاري، مش مجرد ملاحظة جانبية. حوالي 148 ألف نجمة في أوائل يوليو.
trafilatura هي الصوت المختلف في المجموعة دي، وهي الأداة اللي القوائم المنبهرة بالـ AI غالبًا بتنسى وجودها. من غير متصفح. من غير صفوف منظمة. بس نص مقالات نظيف وسريع ببايثون خالص. على fixture المقال استخرجت العنوان وكل 3 من 3 فقرات حقيقية، وشالت الحشو كله — من غير أي تسريب لـ «Login» أو «Subscribe» أو «Copyright» — وكمان رجعت الكاتب والتاريخ. وعلى صفحة منتج عامة رجعت 1,324 محرفًا من نص نظيف. وحدّها واضح جدًا زي ما تصميمها بيقول: لو وجّهتها إلى كتالوج، هترجع 12 اسم منتج كنص لكن 0 صفوف منظمة — النص موجود، لكن البنية مش موجودة، وهي أصلًا لا تعرض JavaScript. الإصدار 2.1.0 (الإصدار الحالي)، Apache-2.0، وحوالي 6.2 ألف نجمة. لاستخراج المقالات الصرف، دي أول أداة هفكر فيها.
أعداد المحارف في Markdown — 13,476 من Crawl4AI و9,222 من Firecrawl — خرجوا من نفس الصفحة العامة، لكن ما تقراهمش كفجوة في الجودة. هما بيعكسوا استراتيجيات Markdown مختلفة (قد إيه زخرفة الصفحة كل واحد محتفظ بيها)، مش حكمًا على مين الناتج بتاعه أفضل. دي قاعدة «الإشارة داخل الأداة نفسها» اللي قلتها قبل كده، وظهرت هنا بشكل واضح جدًا.
المهمة الثانية: عرض JavaScript بشكل موثوق
بعض البيانات ما بتكونش موجودة في HTML إلا بعد تنفيذ السكربتات، وساعتها المتصفح الحقيقي يبقى ضرورة مش رفاهية. ثلاث أدوات بتغطي المهمة دي — واثنتين منهم تقريبًا نفس الأداة.
Playwright وPuppeteer اتعادلت في كل اختبار عملته عليهم. الاتنين عرضوا 8/8 منتجات ديناميكية في الـ fixture المحلي و10 على موقع Quotes JS العام، والاتنين حققوا 12/12 استرجاعًا للثابت، والاتنين تعاملوا مع خطأ 500 بسلاسة (Puppeteer بيرجع كائن response بدل ما يرمي استثناء). ولا واحدة فيهم فيها طابور زحف مدمج، فكان لازم BFS مكتوب يدويًا عشان تعدّي رسم الروابط المؤلف من 12 صفحة. الفرق الحقيقي الوحيد هو نطاق الدعم: Playwright بيشغّل Chromium وFirefox وWebKit وبيتكلم Python و.NET، بينما Puppeteer مركز على Chrome وبيشتغل مع Node فقط. وفيه رقمين مهمين هنا لأن الإصدارات بتتحرك بسرعة: اختبرت Playwright 1.56.0 مقابل إصدار حالي 1.61.1 واستخدمت Chromium فقط، وكمان اختبرت Puppeteer 24.16.0 مقابل إصدار حالي 25.3.0 — فإعادة التشغيل أو وضع ده في الاعتبار مهم للمقارنة. الاتنين Apache-2.0؛ وحوالي 92 ألف و95 ألف نجمة على الترتيب.
Crawlee هو الأداة اللي بتحل مشكلة الطابور اللي الاتنين التانيين سايبينها مفتوحة. هو بيغلف محرك Cheerio (HTTP) ومحرك Playwright (متصفح) تحت واجهة واحدة، والاختبار على صفحة واحدة هو جوهر الفكرة: محرك Cheerio شاف 0 عناصر متدخلة بواسطة JavaScript، بينما محرك Playwright شاف 8/8 كاملين محليًا (و10 على الموقع العام)، والتبديل بينهم محتاج سطر واحد بس. وكمان بيديك RequestQueue حقيقي، وده اللي بيكسبه مكانه في المهمة دي مش في المهمة التالتة. لكن فيه تفصيلة مش باينة في العنوان: محرك المتصفح محتاج npx playwright install منفصل، يعني حوالي 80 MiB مش بيجيبهم npm install crawlee تلقائيًا. الإصدار 3.17.0، TypeScript، Apache-2.0، وحوالي 24.6 ألف نجمة.
المهمة الثالثة: زحف سريع من غير متصفح
لما الموقع ما بيستخدمش JavaScript، المتصفح بيبقى عبء مكلف على الفاضي. ثلاث أدوات تعتمد HTTP أولًا بتتنافس هنا، وكل واحدة بتمثل فلسفة لغة مختلفة، وده بيظهر في فروق مثيرة فعلًا.
Scrapy هو إطار العمل الأثقل هندسيًا في المجموعة — spiders، وتصدير feeds إلى JSON/CSV/XML، وAutoThrottle، وكل شيء تقريبًا. حقق 12/12 في الاسترجاع الثابت، واستخرج الفقرات الثلاث/الثلاث من المقال، وعدّى 11 صفحة عبر العمق 0–2 في رسم الزحف، والتقط خطأ 500 عبر handle_httpstatus_list. ونظرته للعالم هي الجزء الأهم: هو ما بيعرضش الصفحة، لكن بيعيد إنتاج الطلب. ولما اتوجّه لصفحة JavaScript رجع 0 عقد — وبعدها الـ REST API الموجود خلف الصفحة نفسها رجّع له 8/8. دي فلسفة Scrapy في نقطة بيانات واحدة: اعرف الطلب اللي الصفحة بتستخدمه وكرره، وما تقدش المتصفح بنفسك. الثمن هو حزمة اعتماد كبيرة نسبيًا (Twisted وlxml وparsel)، وأنا ما اختبرتش غير على fixtures صغيرة. الإصدار 2.17.0، BSD-3-Clause، وحوالي 63 ألف نجمة.
Colly هو جواب Go، وهو صريح بشكل منعش في وصف نفسه: ملف ثنائي واحد، يعتمد على callbacks عبر OnHTML وOnResponse وOnError, مع التحكم بالعمق. حقق 12/12 في الاسترجاع الثابت، واستخرج 8/8 من API الـ JSON عبر OnResponse, والتقط خطأ 500 عبر OnError, ووصل إلى 17 صفحة أثناء زحف بعمق 2 — وهصيغها بالشكل ده تحديدًا، لأن الرقم ده هو عداد harness نفسه، مش ضمان اكتمال التقدم اللي Colly نفسه حققه. اللي ما بيعملوش هو JavaScript: فالـ fixture الديناميكي وموقع Quotes JS رجعوا 0، وده مقصود. هتحتاج toolchain لـ Go عشان تبنيه، وإصدار الوحدة (v2.3.0) متقدم حاليًا على الإصدار المعلَّم (v2.2.0). Apache-2.0، وحوالي 25 ألف نجمة.
Scrapling هي المتخصصة، وهي فعلًا تستحق الوصف ده. محدداتها التكيفية معمولة عشان تلاقي العنصر تاني بعد ما الـ markup يتغير — عشان كده لما غيرت اسم class الهدف من product-name إلى product-title، selector عادي لقى 0، لكن إعادة المطابقة التكيفية رجّعت العنصر المتتبع على أي حال. وفي الاستخراج عبر HTTP الصريح حققت 12/12 في الثابت و8/8 في JSON API. والجزء اللي مش بتخبيه وثائقها: في اختبار اصطناعي متعدد العناصر رجعت 1 من 3 — دي مرونة في تتبع العناصر، مش استعادة كاملة، فماتبالغش في تقييمها. وكمان pip install scrapling الأساسي محتاج الإضافة [fetchers] عشان يبدأ يشتغل، وStealthyFetcher فيها هو تحفّظ امتثال، مش ميزة أحطها على شريحة عرض. الإصدار 0.4.10 (الإصدار الحالي)، BSD-3-Clause، وحوالي 68.7 ألف نجمة.
النمط اللي ورا المهام الثلاث
لو رصّيت الأدوات التسع جنب بعض، هتشوف نمط واضح جدًا. الاسترجاع الثابت الكامل — 12/12 — هو الحد الأدنى لكل أداة تعتمد HTTP أولًا؛ مفيش واحدة منهم تعثرت في الحالة السهلة، فده مش عامل تفاضل. أدوات المتصفح ما بتبررش وزنها الإضافي إلا لما JavaScript يكون موجود بجد، وحتى ساعتها بتدفع تمن ده في الإعداد: حزمة متصفح، أو تثبيت إضافي، أو أسطول كامل من الحاويات. وعمود «طابور زحف مدمج» هو في الحقيقة الخط الفاصل بين إطار عمل ومحرك — Scrapy وCrawlee بيقدّموا orchestration، بينما Playwright وPuppeteer بيخلّوك تكتب BFS بنفسك. دي هي صورة المجال. مفيش فائز عام لأن مفيش حد بيلعب نفس اللعبة.
طيب، تختار أي أداة فعلًا؟
منصة الاختبار بترفض تتويج فائز لأن الإجابة الصح مش أداة، بل سؤال — أيًّا من المهام الثلاث أنت بتقوم بها؟
- عايز Markdown جاهز للنماذج اللغوية؟ اختار trafilatura لما يكون هدفك نص مقال نظيف، وCrawl4AI لما تحتاج كمان استخراج CSS وعرض JavaScript داخل مكتبة واحدة، وFirecrawl لما تحتاج خدمة مستضافة ذاتيًا وتقدر تتعامل مع ترخيص AGPL-3.0 وعبء الحاويات الست.
- عايز عرض JavaScript؟ استخدم Playwright أو Puppeteer للعرض الخام — واختار بينهم حسب المحرك واللغة، لأنهم تقريبًا متعادلين — واختار Crawlee لما تحتاج كمان orchestration للزحف بدل ما تكتبه يدويًا.
- بتزحف صفحات ثابتة أو APIs قابلة لإعادة الإنتاج على نطاق واسع؟ Scrapy لإطار Python كامل، وColly لسرعة Go الخام في ملف ثنائي واحد، وScrapling لما يكون تحمّل تغيّر الـ markup هو ألمك الأساسي المتكرر.
طابق الأداة مع المهمة، وأي واحدة من دول هتبقى اختيار منطقي يمكن الدفاع عنه. لكن لو استخدمت أداة من الفئة الغلط — متصفح لصفحات ثابتة، أو parser HTTP لتطبيق JavaScript — فحتى أعلى مكتبة تقييمًا على الإنترنت هتخذلك.
فين بتيجي واجهة AI المُدارة بدلًا من كده
كل أداة فوق مجانية ومفتوحة المصدر وتقدر تشغّلها بنفسك. لكن دي برضه المقايضة المشتركة اللي منصة الاختبار بتوضحها كل مرة: أنت المسؤول عن بيئة المتصفح، وكود الزحف، ومطاردة البوتات، وكل تفاصيل الصيانة. بالنسبة لفرق كتير، السيطرة دي هي الهدف نفسه، وكمان خريطة التراخيص مهمة جدًا هنا — فمعظم الأدوات مرخصة بشكل متساهل (Apache-2.0 عبر Crawl4AI وCrawlee وPlaywright وPuppeteer وColly؛ وBSD-3 عبر Scrapy وScrapling)، بينما نواة Firecrawl المستضافة ذاتيًا بترخيص AGPL-3.0 هي الوحيدة اللي تحتاج مراجعة حقيقية قبل أي استخدام تجاري.
لكن خليك منتبه لكمان حاجة منصة الاختبار كشفتها: الحاجات اللي الأدوات دي ما بتعملهاش. العرض، والزحف، والبنية، ومقاومة الحظر — نادرًا ما بيجتمعوا كلهم، وأبدًا من غير صيانة منك. واجهة scraping مُدارة بالـ AI بتختصر ده كله في طلب واحد. سطح المطورين عندنا في Thunderbit هو واحد من الخيارات هنا، وبالنسبة للجمهور التقني فـ API وخادم MCP وCLI هم المهمين، مش إضافة المتصفح. POST /distill بيرجع Markdown نظيف، وPOST /extract بيرجع JSON محدد بمخطط schema، مع عرض JavaScript ومكافحة الحظر على جانب الخادم بدل جهازك. وفيه خادم MCP رسمي للوكلاء ومساعدي البرمجة — thunderbit_suggest_fields بيشتغل مجانًا لتخطيط الاستخراج، وبعدها thunderbit_distill (رصيد واحد) وthunderbit_extract (20 رصيدًا) بيتولوا التنفيذ — بالإضافة إلى CLI تقدر تجيبه عبر npx @thunderbit/thunderbit-cli للاستخدام الطرفي ومهام cron. ولغير المطورين في فريقك فيه كمان إضافة Chrome بدون كود، والأسعار بتغطي الناحيتين.
والمقايضة هي نفسها اللي الاختبار كله بيدور حوالينها: يا إما تشغّل وتدير لحد تسع مكتبات بنفسك مقابل تكلفة صفرية لكل طلب، يا إما تسلّم طبقة البنية وتدفع مقابل كل طلب. مفيش اختيار غلط. المسألة كلها بترجع لكم من الستاك أنت عايز تمتلكه فعلًا. ولو حابب تشوف شكل الاستخراج عمليًا، فـ قناة Thunderbit على YouTube بتعرضه.
{{INTERNAL_BLOG_LINKS}}
الحكم النهائي
مفيش أفضل أداة كشط ويب مفتوحة المصدر واحدة، وأي قائمة بتديك إجابة واثقة غالبًا بتخفي السؤال اللي فعلًا بيحدد الاختيار: أيًّا من المهام الثلاث أنت بتعملها؟ حوّل صفحة إلى نص، أو اعرض JavaScript، أو ازحف بسرعة من غير متصفح — المجال متقسم بوضوح لهذه الفئات، وداخل كل فئة الاختيار بيرجع للغة وعبء الإعداد، مش لبطل عالمي.
لو هتاخد عادة واحدة من كل ده، فلتكن دي: جرّب على صفحاتك أنت قبل ما تلتزم بأي أداة. كل رقم هنا قابل لإعادة الإنتاج في مستودع benchmark عشان السبب ده بالذات — لأن الأداة اللي بتتصدر قائمة عامة مش دايمًا هي نفسها اللي بتنجو على أهدافك الحقيقية.
جرّب Thunderbit لاستخراج بيانات الويب Get Started Free
الأسئلة الشائعة
ما أفضل أداة كشط ويب مفتوحة المصدر؟ مفيش أداة واحدة بس — ده بيعتمد على المهمة. للنص الجاهز للنماذج اللغوية، استخدم trafilatura أو Crawl4AI؛ ولعرض JavaScript، استخدم Playwright أو Puppeteer أو Crawlee؛ وللزحف السريع عبر HTTP، استخدم Scrapy أو Colly. على منصة اختبار مشتركة، كل أداة كانت الأقوى في فئتها والأضعف بوضوح خارجها، عشان كده التصنيفات الموحدة مضللة.
أي الأدوات المفتوحة المصدر تعرض JavaScript؟ Crawl4AI وFirecrawl وPlaywright وPuppeteer ومحرك Playwright داخل Crawlee كلهم يعرضوا JavaScript. أما Scrapy وColly وtrafilatura وجالب HTTP الافتراضي في Scrapling فلا — إما تحتاج API قابل لإعادة الإنتاج خلف الصفحة (وده نهج Scrapy، اللي وصل إلى 8/8 عبر نقطة النهاية JSON) أو وضع متصفح منفصل.
هل أحتاج إلى متصفح headless لكشط موقع؟ فقط لو البيانات بتظهر بعد تنفيذ JavaScript. لو طلب HTTP عادي مع parser قادر يوصل للمحتوى، فالمتصفح بيبقى مبالغة مكلفة — وساعتها Scrapy أو Colly أو Scrapling هيكونوا أخف وأسرع بكتير.
أيٌّ من هذه التراخيص هو الأسهل للاستخدام التجاري؟ أغلبها متساهل: Apache-2.0 (Crawl4AI وCrawlee وPlaywright وPuppeteer وColly) أو BSD-3-Clause (Scrapy وScrapling). الاستثناء هو نواة Firecrawl المستضافة ذاتيًا، فهي AGPL-3.0 وتستحق مراجعة ترخيص فعلية قبل بناء منتج تجاري عليها.
هل يمكن إعادة إنتاج أرقام benchmark هذه؟ نعم. كل runner وكل fixture وكل نتيجة خام موجودة في مستودع عام مرخّص بـ MIT. والحد الوحيد اللي لازم تتذكره: الاسترجاع والنتائج البنيوية قابلة للمقارنة بين الأدوات، لكن أعداد المحارف المطلقة هي إشارات داخل الأداة فقط، لأن كل حزمة بتعكس الـ fixtures بدل ما تشترك في نسخة مرجعية واحدة — فاقارن النِّسب ونجاح/فشل الاختبار، مش إجمالي المحارف الخام.
