- Flask-आधारित बैकएंड-केंद्रित वेब फ्रेमवर्क, जो जटिल फ्रंटएंड प्रबंधन के बिना तेज़ और सरल state management प्रदान करता है
- HTMX के साथ जुड़ी component architecture को अपनाता है, जिससे सर्वर-आधारित interactive UI निर्माण संभव होता है
- file-based routing, esbuild + TailwindCSS asset pipeline, automated deployment environment आदि जैसे आधुनिक वेब स्टैक का एकीकरण
- ईमेल भेजना (MJML), background jobs, SSE-आधारित push, translation, authentication आदि जैसी विविध built-in सुविधाएँ शामिल
- container-आधारित development·deployment environment standardization और VS Code integration के साथ, आसान setup और cloud deployment का समर्थन
अवलोकन: Flask-आधारित बैकएंड-केंद्रित वेबऐप फ्रेमवर्क
- Hyperflask Flask के ऊपर चलने वाला Python web framework है, जो backend-driven design को लक्ष्य बनाता है
- यह frontend state management की जटिलता को कम करता है और server-centric concise architecture प्रदान करता है
- HTMX, TailwindCSS, esbuild जैसी आधुनिक वेब तकनीकें डिफ़ॉल्ट रूप से शामिल हैं
- HTMX integration के ज़रिए पूरे पेज को reload किए बिना real-time interaction लागू किया जा सकता है
- component architecture के कारण backend और frontend components को पुन: उपयोग किया जा सकता है
- Flask environment में component-centric structure लाकर, frontend और backend components को Jinja templates में सीधे इस्तेमाल किया जा सकता है
- HTMX के साथ जुड़े server-backend type components बनाए जा सकते हैं, और React या web components के साथ भी स्वाभाविक रूप से integrate होते हैं
- code reusability और maintainability बढ़ाकर बड़े पैमाने के app development के लिए उपयुक्त संरचना प्रदान करता है
- file-based और app-based routing support
- Python code और Jinja templates को जोड़ने वाला नया
.jpy file format इस्तेमाल करता है
- Astro के page system से प्रेरित होकर, route definition और UI composition को एक ही जगह पर manage किया जा सकता है
- इससे routing configuration सरल हो जाती है, और नए page जोड़ना सहज बनता है
- open ecosystem
- Hyperflask का अपना codebase छोटा है, और यह कई Flask extensions को ऑर्गेनिक तरीके से जोड़कर बनाया गया है
- हर extension को स्वतंत्र project के रूप में manage किया जाता है, जिससे स्वतंत्र चयन और संयोजन संभव है
- सभी projects GitHub के Hyperflask organization में सार्वजनिक हैं, और user-customized framework configuration को प्रोत्साहित करते हैं
- “Batteries Included”
- MJML email sending, dramatiq background jobs, SSE-आधारित real-time push, gettext-आधारित translation(i18n)
- authentication और session management, image optimization और streaming, static content generation आदि
- अलग setup के बिना तुरंत इस्तेमाल की जा सकने वाली production-level feature set प्रदान करता है
- SQL-केंद्रित ORM(sqlorm), SQLite के लिए optimized
- environment setup और deployment
- container-आधारित development/operations environment को standardize करके, environment setup से जुड़ी समस्याओं को न्यूनतम करता है
- VS Code के साथ करीबी integration के कारण local development और debugging आसान होती है
- VPS या प्रमुख cloud services पर आसान deployment का समर्थन
सारांश
- Hyperflask, Flask ecosystem का विस्तार करके आधुनिक full-stack Python web development experience देने वाला अगली पीढ़ी का framework है
- HTMX, component system, file-based routing, और container-standardized development environment के ज़रिए न्यूनतम setup के साथ अधिकतम productivity हासिल करता है
1 टिप्पणियां
Hacker News राय
hyperflask के निर्माता के रूप में, मुझे बहुत खुशी है कि मैं आखिरकार लंबे समय से तैयार किए जा रहे इस प्रोजेक्ट को सार्वजनिक कर पाया हूँ
विस्तृत घोषणा पोस्ट यहाँ देखी जा सकती है
मैं तरह-तरह के फ़ीडबैक सुनना चाहूँगा
अगर यह इस तरह बैकएंड पर निर्भर होने के बजाय एक लाइब्रेरी के रूप में होता, तो शायद और बेहतर होता
मेरा Django प्रोजेक्ट पहले से ही दस लाख लाइनों से बड़ा है, इसलिए इसे आसानी से बदला नहीं जा सकता; मैं जानना चाहता हूँ कि क्या इसे Django ऐप में आसानी से लागू करने का कोई तरीका है
htmx डेवलपर के रूप में, यह प्रोजेक्ट वाकई शानदार लग रहा है
मेरे एक सहकर्मी ने flask/htmx/sqlalchemy संयोजन से एक internal app बनाया था और अच्छे नतीजे मिले थे, लेकिन उसे open source approval नहीं मिल पाई थी
इसलिए मैं hyperflask के इस नए प्रयास को लेकर उत्साहित हूँ
मैं जानना चाहता हूँ कि ORM के लिए sqlorm क्यों चुना गया
मैं काफ़ी समय से Python development से दूर रहा हूँ, लेकिन मुझे लगा था कि सब SQLAlchemy ही इस्तेमाल करते हैं, इसलिए sqlorm मेरे लिए नया है
यह देखना प्रभावशाली है कि एक नया framework HTMX को अपना रहा है
HTMX, JS और React के विकल्प के रूप में कई नए रुझानों को प्रेरित कर रहा है
Python और Flask का संयोजन पसंद करने वाले लोग भी बहुत होंगे, और server-side HTMX में components काफ़ी महत्वपूर्ण हैं
और homepage का FastHTML की तुलना में आँखों पर कम ज़ोर डालना भी एक फ़ायदा है
harcstack.org से तुलना करें तो
ऐसे विकल्पों की वजह से यह कहीं ज़्यादा व्यापक user base को आकर्षित कर सकता है
तुलना के लिए लिया गया HARC stack शायद उन थोड़े लोगों को ज़्यादा आकर्षक लगेगा जो HTML को Elm language के server-side version की तरह functional तरीके से संभालना चाहते हैं, या जिन्हें Tailwind की denormalization से एलर्जी है
htmx से webapp बनाते समय मुझे लगा कि मैं एक 'dead end' पर पहुँच गया हूँ
मुख्य समस्या यह है कि frontend application state को URL में स्टोर करना पड़ता है
आधुनिक UI में, जहाँ कई क्षेत्र, widgets, popups वगैरह होते हैं और सबको अपना local state और navigation चाहिए, वहाँ सारी state को एक global URL में समेटना बहुत मुश्किल हो जाता है
ज़रूरत पड़ने पर state को URL में न डालने वाली डिज़ाइन बनाना भी और कठिन है
React या Vue जैसे frameworks, जो अपना state store देते हैं, उनमें यह समस्या आसानी से हल हो जाती है
अगर phpBB forum जैसी संरचना हो तो ठीक है, लेकिन आज के users इससे ज़्यादा उन्नत अनुभव की उम्मीद करते हैं
state को सिर्फ URL में ही रखना ज़रूरी नहीं है
server storage, session, localstorage, cookies जैसे कई तरीके हैं
उदाहरण के लिए, user app layout customization के लिए URL की ज़रूरत नहीं होती, लेकिन search results जैसी चीज़ों में sharing चाहिए तो search conditions URL में होना ज़रूरी है
पहले यह सोचना चाहिए कि हासिल क्या करना है
और 'modern UI' के नाम पर बहुत सारे widgets और popups को एक ही screen/एक ही URL में ठूँस देना उल्टा अनावश्यक complexity भी हो सकता है
अक्सर React/Vue का state storage भी उस चीज़ की duplication होता है जिसे server पहले से संभाल सकता है
hypermedia approach भी काफ़ी complex UI को संभाल सकती है
हर चीज़ को URL में ठूँसने की ज़िद करने की ज़रूरत नहीं है
session, cookies और tab IDs का इस्तेमाल करके state को tabs के बीच shared या isolated रखा जा सकता है, और backend DB से state पढ़ी जा सकती है
hypermedia real-time/multiplayer environments में भी बहुत अच्छी है
बल्कि HTMX की कमी तो यह है कि वह state को backend में और ज़्यादा नहीं रखता; काश यह और साहसिक तरीके से जाता
मुझे लगता है कि यह बस मेरे use case के लिए सही फिट नहीं है
और React/Vue को 'आसान' मानना भी दिलचस्प है
मुझे नहीं लगता कि React या Vue भी उन सभी समस्याओं को हल कर देते हैं जिनकी users उम्मीद करते हैं
जब तक complexity बहुत ज़्यादा न हो, मैं वास्तव में htmx (unpoly, alpinejs, localstorage के साथ) से ज़्यादातर cases को आराम से संभाल लेता हूँ
hyperflask में मुझे कुछ दिलचस्प concepts दिखे
लेकिन components असल में अंदर से साधारण macros ही लगते हैं, तो क्या सीधे macros का इस्तेमाल करना बेहतर नहीं होगा?
Flask चुनने का कारण भी जानना चाहूँगा
मैंने पहले /dev/push नाम से ऐसा ही एक approach आज़माया था, फिर FastAPI + Jinja2 + Alpine.js + HTMX संयोजन पर चला गया
बाद में समझ आया कि FastAPI सिर्फ API के लिए नहीं है, और मुझे async support चाहिए था इसलिए मैंने उसे चुना
मुझे Flask भी पसंद है, लेकिन कभी-कभी उसकी सीमाएँ महसूस हुई हैं
view और controller को एक ही file में बाँधने का तरीका पुराने PHP development की याद दिलाता है
project के आकार के अनुसार development निश्चित रूप से सरल हो जाता था, इसलिए यह एक फ़ायदा था
मुझे लगता है कि FastAPI + HTMX का संयोजन भी बहुत प्रभावी है
Django में मेरे अनुभव के अनुसार, admin scaffolding की वजह से diagnostics और customer support के लिए अलग UI बनाने की ज़रूरत लगभग नहीं पड़ती थी
दूसरे framework-based projects में यह सुविधा ख़ुद बनानी पड़ती है, और अक्सर नतीजा Django जितना संतोषजनक नहीं होता
Hyperflask जैसे आकर्षक frameworks बहुत हैं, लेकिन Django admin framework को छोड़ना उतनी ही बड़ी कीमत है
मैं जानना चाहता हूँ कि क्या किसी ने Django admin के विकल्प या उसके बदले कोई पैटर्न ढूँढा है
मुझे भी यही बात महसूस हुई
FastAPI पर जाते समय Django की जिस चीज़ की सबसे ज़्यादा कमी लगी, वह project को व्यवस्थित करने वाले उसके अलग-अलग apps थे
migrations, static files, templates जैसी चीज़ों को feature-wise समूहबद्ध करने वाली संरचना कितनी सुविधाजनक थी, यह बाद में समझ आया
मैं ज़्यादातर Supabase इस्तेमाल करता हूँ
कभी-कभी urgent management tasks के लिए मैं admins को Supabase UI इस्तेमाल करना सिखा देता हूँ
या अगर संभव हो तो Airtable को backend की तरह भी इस्तेमाल करता हूँ
लेकिन ज़्यादातर समय Django admin की बहुत याद आती है, और Django+HTMX का संयोजन हमेशा लुभावना लगता है
Flask-Admin भी है, लेकिन वह Django Admin की तुलना में काफ़ी सरल है
मैं आगे चलकर इस समस्या को हल करना चाहता हूँ
कई frameworks के साथ HTMX इस्तेमाल करने के बाद, मुझे लगता है कि Go + Templ + HTMX का संयोजन versatility और simplicity के बीच अच्छा संतुलन बनाता है
मेरे अनुभव में Go बहुत verbose है, इसलिए मैं उल्टा Go+Templ+HTMX से Flask + Jinja + HTMX पर जाने के बारे में सोच रहा हूँ
Go में templates define करने का तरीका मुझे झंझट भरा लगता है
अगली बार मैं FastAPI + Jinja2 + HTMX ज़रूर आज़माना चाहूँगा
अभी मैं यही stack इस्तेमाल कर रहा हूँ
hyperflask मुझे Flask और htmx की philosophy से थोड़ा अलग लगता है
इसमें abstraction layers बहुत ज़्यादा हैं, और htmx के साथ integration points भी खास नज़र नहीं आते
मुझे FastHTML जैसा कुछ उम्मीद था, जहाँ htmx built-in हो
जब भी किसी project में starfield demo आता है, मैं हमेशा speed control और mouse cursor को follow करने वाला effect देखने की उम्मीद करता हूँ
आशा है कि अगली Hyperflask version में यह जोड़ा जाएगा
project खुद शानदार है, और मुझे Htmx पसंद है, लेकिन हाल में मैं Datastar पर भी नज़र रखे हुए हूँ
console में नीचे का code चलाने पर speed control समेत कई तरह के effects दिए जा सकते हैं
क्या आप ऐसी functionality की बात कर रहे हैं?
nova.app अब तक मैंने जो देखा है, उसमें सबसे बेहतरीन है
अगर आप HTMX आधारित पूरी Fullstack Async experience चाहते हैं, तो Litestar भी देखने लायक है
पहली नज़र में मुझे समझना मुश्किल हुआ कि Python controller file में HTML template को सीधे जोड़ने की ज़रूरत क्यों है
लगा जैसे सिर्फ एक simple render function बचाने के लिए complexity बढ़ा दी गई हो
मैं जानना चाहता हूँ कि मैंने कौन-सी बात मिस कर दी
यह JavaScript दुनिया के Astro Pages से प्रेरित है
वास्तव में developer experience भी अच्छा था
बहुत लोग Flask की सीमाओं की बात करते हैं और पूछते हैं 'FastAPI क्यों नहीं', लेकिन व्यक्तिगत रूप से मुझे लगता है कि Litestar सबसे अच्छा विकल्प है
Litestar htmx support डिफ़ॉल्ट रूप से देता है
अधिक जानकारी यहाँ देखी जा सकती है