नोड.जेएस एक्सप्रेस बनाम फ्लैटिरॉन

Question

अकीन this question, "मैं प्रत्येक ढांचे के पेशेवरों और विपक्ष की तलाश में हूं और क्यों एक दूसरे पर विशेष रूप से उपयोगी है" (लेकिन तथ्य यह है कि फ्लैटिरॉन को क्या पेशकश करनी है, तथ्य के कारण उस एक्सप्रेस में एक्सप्रेस पहले से ही काफी अच्छी तरह से विस्तृत है)।

मेरे से थोड़ा एक्सप्रेस के साथ अनुभव, ऐसा लगता है कि आपको केवल इतना चाहिए कि आप क्या चाहते हैं और नहीं। Flatiron ऐसा करने लगता है, लेकिन बहुत कम से कम। यदि आप अपने website की जांच करते हैं, तो आप देखते हैं कि वे एक्सप्रेस में शामिल कई अन्य लोगों की तुलना में लगभग 5-7 मुख्य कार्यक्षमताओं की पेशकश करते हैं।

अंत में, जो उच्च स्केलेबल वेब ऐप के लिए सबसे अधिक आशाजनक प्रतीत होता है, और मुझे इस ढांचे का उपयोग क्यों नहीं करना चाहिए,

Answer 1

एक वर्ष के बाद कुछ अद्यतन और एक आधे के बाद यह प्रश्न पूछा गया था:

पहले अंतर यह है कि तुलना करते समय ExpressFlatiron है कि एक्सप्रेस एक सर्वर साइड ढांचा है, जबकि Flatiron isomorphic जा रहा है के रूप में विज्ञापित किया जाता है मन में आता है , दोनों सर्वर साइड और क्लाइंट साइड को कवर करते हैं और इस तरह पारंपरिक सर्वर-साइड अनुप्रयोगों, क्लाइंट-साइड सिंगल-पेज एप्लिकेशन और बीच में सबकुछ विकसित करने के लिए उपयुक्त होना चाहिए (उदाहरण के लिए Derby या Meteor)। हालांकि, मैं फ्लैटिरॉन के क्लाइंट-साइड उपयोग के किसी भी उदाहरण को खोजने में विफल रहा हूं, न कि प्रयास की कमी के लिए।

वहाँ an issue on GitHub है (मैं वहाँ टिप्पणियों को पढ़ने क्या समझ से) एक सरल TODO अनुप्रयोग उदाहरण है कि दो साल और के लिए खुला हो गया है प्रदान करने के लिए आप अकेले Flatiron का उपयोग कर एक क्लाइंट-साइड अनुप्रयोग निर्माण नहीं कर सकते jQuery तरह बातें जोड़ने के बिना, Backbone इत्यादि। क्योंकि फ्लैटिरॉन का क्लाइंट-साइड पहलू अभी तक तैयार नहीं प्रतीत होता है ("हम इस पर काम कर रहे हैं। हमारे पास अभी भी पूरी तरह से आइसोमोर्फिक बनाने के लिए कुछ और कदम हैं।") जो वास्तविक समस्या की तरह दिखता है एक ढांचे के लिए जो शुरुआत से आइसोमोर्फिक होने की कोशिश की। (एक संबंधित TodoMVC समस्या भी देखें: Add FlatIron example)।

निष्कर्ष यह है कि Flatiron अभी तक तैयार नहीं है। जब यह तैयार होता है तो यह एक्सप्रेस की तुलना में वेब विकास के अधिक क्षेत्रों को कवर कर सकता है, लेकिन यह कहना मुश्किल है कि यह कब हो सकता है, यदि एक साधारण TODO app example वर्षों से प्रदान नहीं किया जा सका।

इस बीच बहुत सारे नोड ढांचे हैं और इन्हें ट्रैक रखना वाकई मुश्किल है, इसलिए मैं अब क्या करने की सिफारिश करता हूं और भविष्य में गिटहब पर जॉयेंट/नोड विकी पर the list of Web frameworks देखना होगा और उन्हें तुलना करें TodoMVC प्रोजेक्ट पर क्लाइंट-साइड फ्रेमवर्क - जहां दोनों सूचियों की सूची अलग-अलग होती है, वे सर्वर और क्लाइंट दोनों को कवर करते हैं और उनमें एक साधारण TODO ऐप लिखने में सक्षम होते हैं - जो उम्मीद है कि फ्लैटिरॉन एक दिन शामिल होगा।

Answer 2

मेरी धारणा यह है कि एक्सप्रेस न्यूनतम है, जबकि फ्लैटरॉन अधिक पूर्ण/जटिल प्रतीत होता है। स्केलिंग के लिए सबसे अच्छा एक कठिन सवाल है, क्योंकि दोनों आपके ऐप की स्केल-क्षमता बढ़ाने के लिए कुछ भी नहीं करते हैं। वे मार्ग जोड़ने के लिए आसान तरीके प्रदान करके आसान तरीके प्रदान करके एक ऐप को आसान बनाते हैं (इसके बजाय अपने दोषपूर्ण regexp के साथ पागल हो जाते हैं)।

व्यक्तिगत रूप से, मैं सभी छोटे कनेक्ट और एक्सप्रेस मिडलवेयर, साथ ही गतिशील हेल्पर (टेम्पलेटिंग के लिए) को प्यार करने आया हूं, जो फ्लैटिरॉन द्वारा समर्थित नहीं लगता है (हाँ, उनके पास मिडलवेयर है, लेकिन ऐसा प्रतीत नहीं होता है जैसे कि आप कनेक्ट से कनेक्ट कर सकते हैं। EDIT; जैसा कि यह पता चला है, संघ, जो फ्लैटरॉन मिडलवेयर हैंडलर कनेक्ट करने के लिए संगत है, ताकि आप कनेक्ट के मिडलवेयर का उपयोग कर सकें)।

मैं किसी को फ्लैटरॉन पर एक्सप्रेस का उपयोग करने की सलाह दूंगा, लेकिन फिर फिर से; मैं बेहतर साबित करना चाहता हूं।

Answer 3

मुझे लगता है कि युद्ध एक्सप्रेस बनाम फ्लैटिरॉन स्पष्ट रूप से एक्सप्रेस द्वारा जीता गया है।

फ्लैटिरॉन ढांचे एटीएम के लिए कोई सक्रिय विकास नहीं है।

गिटहब भंडार देखें: https://github.com/flatiron/flatiron। अंतिम रिलीज 16 सितंबर, 2014 से 0.4.2 है।

आधिकारिक फ्लैटरॉन वेबसाइट http://flatironjs.org/ नीचे है।