Hyperflask – เฟรมเวิร์ก Flask และ Htmx แบบฟูลสแตก

• เว็บเฟรมเวิร์กที่เน้นแบ็กเอนด์บนพื้นฐาน Flask มอบ การจัดการสถานะที่รวดเร็วและเรียบง่าย โดยไม่ต้องจัดการฟรอนต์เอนด์ที่ซับซ้อน
• นำสถาปัตยกรรมแบบ คอมโพเนนต์ ที่ผสานกับ HTMX มาใช้ ทำให้สร้าง UI แบบอินเทอร์แอ็กทีฟที่ขับเคลื่อนโดยเซิร์ฟเวอร์ ได้
• ผสานเว็บสแตกสมัยใหม่ เช่น การทำ routing แบบอิงไฟล์, asset pipeline ของ esbuild + TailwindCSS, และ สภาพแวดล้อม deployment แบบอัตโนมัติ
• มี ฟีเจอร์พื้นฐานที่หลากหลาย ในตัว เช่น การส่งอีเมล (MJML), งานเบื้องหลัง, push แบบอิง SSE, การแปลภาษา และการยืนยันตัวตน
• รองรับการตั้งค่าที่ง่ายและการ deploy ขึ้นคลาวด์ ด้วย การทำให้สภาพแวดล้อมพัฒนาและ deploy เป็นมาตรฐานบนคอนเทนเนอร์ และการผสานกับ VS Code

---

ภาพรวม: เฟรมเวิร์กเว็บแอปที่เน้นแบ็กเอนด์บนพื้นฐาน Flask

• Hyperflask คือ Python เว็บเฟรมเวิร์ก ที่ทำงานบน Flask และมุ่งเน้นการออกแบบที่ขับเคลื่อนด้วยแบ็กเอนด์
• ช่วยลดความซับซ้อนของการจัดการสถานะฝั่งฟรอนต์เอนด์ และมอบ สถาปัตยกรรมที่กระชับแบบยึดเซิร์ฟเวอร์เป็นศูนย์กลาง
• มาพร้อมเทคโนโลยีเว็บสมัยใหม่อย่าง HTMX, TailwindCSS, esbuild เป็นค่าเริ่มต้น
• ด้วยการผสาน HTMX จึงสามารถสร้าง การโต้ตอบแบบเรียลไทม์โดยไม่ต้องรีโหลดทั้งหน้า ได้
• รองรับการนำคอมโพเนนต์ทั้งฝั่งแบ็กเอนด์และฟรอนต์เอนด์กลับมาใช้ซ้ำได้ด้วย สถาปัตยกรรมแบบคอมโพเนนต์
  • นำ โครงสร้างแบบเน้นคอมโพเนนต์ มาใช้ในสภาพแวดล้อม Flask ทำให้สามารถใช้คอมโพเนนต์ฝั่งฟรอนต์เอนด์และแบ็กเอนด์ได้โดยตรงในเทมเพลต Jinja
  • สามารถสร้าง คอมโพเนนต์ฝั่งเซิร์ฟเวอร์แบ็กเอนด์ที่ผสานกับ HTMX ได้ และยังเชื่อมรวมกับ React หรือเว็บคอมโพเนนต์ได้อย่างเป็นธรรมชาติ
  • เพิ่มการใช้โค้ดซ้ำและความสามารถในการบำรุงรักษา พร้อมมอบ โครงสร้างที่เหมาะกับการพัฒนาแอประดับใหญ่
• รองรับทั้ง routing แบบอิงไฟล์และแบบอิงแอป
  • ใช้ รูปแบบไฟล์ .jpy แบบใหม่ ที่รวมโค้ด Python และเทมเพลต Jinja เข้าด้วยกัน
  • ได้แรงบันดาลใจจาก ระบบเพจของ Astro ทำให้จัดการนิยาม route และการประกอบ UI ได้ในที่เดียว
  • ช่วยให้การตั้งค่า routing เรียบง่ายขึ้น และเพิ่มหน้าใหม่ได้อย่างเป็นธรรมชาติ
• ระบบนิเวศแบบเปิด
  • Hyperflask มีโค้ดเบสขนาดเล็ก และสร้างขึ้นจากการ ผสานส่วนขยายต่าง ๆ ของ Flask อย่างเป็นระบบ
  • ส่วนขยายแต่ละตัวถูก ดูแลเป็นโปรเจกต์อิสระ ทำให้เลือกใช้และนำมาประกอบกันได้อย่างอิสระ
  • ทุกโปรเจกต์เปิดเผยบน องค์กร Hyperflask บน GitHub และส่งเสริม การประกอบเฟรมเวิร์กแบบปรับแต่งตามผู้ใช้
• “Batteries Included”
  • มี การส่งอีเมลด้วย MJML, งานเบื้องหลังด้วย dramatiq, real-time push บนพื้นฐาน SSE, การแปลภาษาด้วย gettext (i18n)
  • รวมถึง การยืนยันตัวตนและการจัดการเซสชัน, การปรับแต่งและสตรีมภาพ, การสร้างคอนเทนต์แบบสแตติก เป็นต้น
  • มอบ ชุดฟีเจอร์ระดับ production ที่พร้อมใช้งานได้ทันทีโดยแทบไม่ต้องตั้งค่าเพิ่มเติม
  • มี ORM ที่เน้น SQL (sqlorm) และปรับให้เหมาะกับ SQLite
• การตั้งค่าสภาพแวดล้อมและการ deploy
  • ทำให้ สภาพแวดล้อมพัฒนาและใช้งานจริงบนคอนเทนเนอร์เป็นมาตรฐาน เพื่อลดปัญหาเรื่องการตั้งค่าสภาพแวดล้อม
  • ผสานกับ VS Code อย่างแน่นแฟ้น ทำให้การพัฒนาและดีบักในเครื่องทำได้สะดวก
  • รองรับ การ deploy ไปยัง VPS หรือบริการคลาวด์หลักได้อย่างง่ายดาย

สรุป

• Hyperflask คือเฟรมเวิร์กรุ่นใหม่ที่ขยายระบบนิเวศ Flask เพื่อมอบ ประสบการณ์การพัฒนาเว็บแบบฟูลสแตกด้วย Python ที่ทันสมัย
• ด้วย HTMX, ระบบคอมโพเนนต์, routing แบบอิงไฟล์ และสภาพแวดล้อมพัฒนาที่ทำเป็นมาตรฐานด้วยคอนเทนเนอร์ จึงทำให้เกิด ประสิทธิภาพสูงสุดด้วยการตั้งค่าขั้นต่ำ

[GN⁺]

ความเห็นจาก Hacker News

• ในฐานะผู้สร้าง hyperflask รู้สึกยินดีมากที่ในที่สุดก็ได้เปิดตัวโปรเจ็กต์ที่เตรียมมานาน
  ดูโพสต์ประกาศรายละเอียดได้ที่นี่
  อยากฟังฟีดแบ็กจากทุกคน

  • ถ้าทำออกมาเป็นไลบรารีที่ไม่ผูกติดกับแบ็กเอนด์น่าจะดีกว่านี้
    ตอนนี้โปรเจ็กต์ Django ของฉันมีเกินล้านบรรทัดแล้ว เลยเปลี่ยนง่ายไม่ได้ เลยสงสัยว่ามีวิธีเอาไปใช้กับแอป Django ได้ง่าย ๆ ไหม

  • ในฐานะผู้พัฒนา htmx โปรเจ็กต์นี้ดูเจ๋งมาก

  • เพื่อนร่วมงานเคยทำแอปภายในด้วยชุด flask/htmx/sqlalchemy แล้วได้ผลลัพธ์ที่ดี แต่ตอนนั้นไม่ได้รับอนุมัติให้ออกโอเพนซอร์ส
    เลยกำลังคาดหวังกับแนวทางใหม่ของ hyperflask

  • สงสัยว่าทำไมถึงเลือก sqlorm เป็น ORM
    ฉันห่างจากการพัฒนา Python มานาน แต่เข้าใจมาตลอดว่าทุกคนใช้ SQLAlchemy กันหมด และไม่ค่อยคุ้นกับ sqlorm

  • น่าประทับใจที่มีเฟรมเวิร์กใหม่รับเอา HTMX มาใช้อย่างจริงจัง
    HTMX กำลังกระตุ้นกระแสทางเลือกหลายแบบที่มาแทน JS และ React
    คนที่ชอบ Python กับ Flask ก็น่าจะมีเยอะ และในโลกของ HTMX ฝั่งเซิร์ฟเวอร์นั้นคอมโพเนนต์คือหัวใจสำคัญ
    อีกข้อดีก็คือหน้าเว็บหลักดูสบายตากว่า FastHTML
    ถ้าเทียบกับ harcstack.org แล้ว

    Language: Python vs. Raku  
    Web framework: Flask vs. Cro  
    ORM: ?? vs. Red  
    Components: ทั้งคู่มี  
    HTML: เทมเพลต vs. ฟังก์ชันนัล  
    CSS: DaisyUI/Tailwind/Bootstrap vs. Pico  
    

    ตัวเลือกแบบนี้น่าจะดึงผู้ใช้ได้กว้างกว่ามาก
    ส่วน HARC stack ที่ถูกยกมาเทียบอาจจะดึงดูดคนกลุ่มเล็กที่ชอบจัดการ HTML แบบฟังก์ชันนัลคล้าย Elm ฝั่งเซิร์ฟเวอร์ หรือแพ้ความไม่เป็นระเบียบของ Tailwind

• ตอนพัฒนาเว็บแอปด้วย htmx ฉันเคยรู้สึกว่าเจอ 'ทางตัน'
  ปัญหาหลักคือสถานะของแอปฝั่งฟรอนต์เอนด์ต้องถูกเก็บไว้ใน URL
  สำหรับ UI สมัยใหม่ที่มีหลายพื้นที่ วิดเจ็ต ป๊อปอัป ฯลฯ และแต่ละส่วนก็ต้องมีสถานะภายในกับการนำทางของตัวเอง การยัดทุกสถานะไว้ใน global URL เดียวเป็นเรื่องยากมาก
  และการออกแบบให้บางสถานะไม่ต้องอยู่ใน URL ตามความจำเป็นก็ยิ่งยากกว่า
  ปัญหาแบบนี้แก้ได้ง่ายในเฟรมเวิร์กอย่าง React หรือ Vue ที่มี state store ของตัวเอง
  ถ้าทำแบบฟอรัม phpBB ก็อาจโอเค แต่ผู้ใช้ทุกวันนี้คาดหวังประสบการณ์ที่ล้ำกว่านั้น

  • ไม่จำเป็นต้องเก็บ state ไว้แค่ใน URL เท่านั้น
    จะใช้ server store, session, localstorage, cookie หรือวิธีอื่นก็ได้
    เช่น การปรับแต่งเลย์เอาต์แอปของผู้ใช้ไม่จำเป็นต้องมี URL แต่ถ้าเป็นผลการค้นหาที่ต้องแชร์ได้ เงื่อนไขการค้นหาก็ควรอยู่ใน URL เสมอ
    ต้องคิดก่อนว่าอยากบรรลุอะไร
    และการเอาวิดเจ็ตหรือป๊อปอัปจำนวนมากมาใส่ไว้ในหน้าจอเดียวหรือ URL เดียวภายใต้ชื่อว่าเป็น 'UI สมัยใหม่' ก็อาจกลายเป็นความซับซ้อนเกินจำเป็น
    บ่อยครั้ง state ที่ React/Vue จัดการให้ ก็เป็นสิ่งที่ฝั่งเซิร์ฟเวอร์จัดการได้อยู่แล้วซ้ำอีกชั้น

  • แนวทางไฮเปอร์มีเดียก็รองรับ UI ที่ซับซ้อนมากได้เหมือนกัน
    ไม่จำเป็นต้องยึดติดว่าทุกอย่างต้องอยู่ใน URL
    ใช้ session, cookie, tab id ฯลฯ เพื่อแชร์หรือแยก state รายแท็บได้ และค่อยดึง state จากฐานข้อมูลฝั่งแบ็กเอนด์
    ไฮเปอร์มีเดียยังเก่งมากในงานแบบเรียลไทม์หรือหลายผู้เล่น
    ถ้าจะว่าไป จุดอ่อนของ HTMX คือยังไม่กล้าเอา state ไปไว้ฝั่งแบ็กเอนด์ให้มากพอ และฉันกลับอยากให้มันไปทางนั้นให้สุดกว่านี้

  • ฉันแค่มองว่าสิ่งนี้ไม่ตรงกับ use case ของตัวเอง
    และก็ขำดีที่มีคนมองว่า React/Vue 'ง่าย'

  • ฉันก็ไม่คิดว่า React หรือ Vue จะแก้ทุกปัญหาที่ผู้ใช้คาดหวังได้ทั้งหมด

  • ถ้าไม่ใช่กรณีที่ซับซ้อนมากจริง ๆ ส่วนตัวฉันจัดการเคสส่วนใหญ่ได้สบาย ๆ ด้วย htmx ร่วมกับ unpoly, alpinejs และ localstorage

• ฉันเห็นแนวคิดที่น่าสนใจใน hyperflask

  • การทำคอมโพเนนต์: ลิงก์
  • วิธีรวม view กับ controller ไว้ในไฟล์เดียว: ลิงก์
    แต่คอมโพเนนต์จริง ๆ แล้วภายในก็แทบจะเป็นแค่แมโครธรรมดา เลยรู้สึกว่าสู้ใช้แมโครตรง ๆ ไปเลยไม่ดีกว่าหรือ
    แล้วก็สงสัยว่าทำไมถึงเลือก Flask
    ก่อนหน้านี้ฉันเคยลองแนวทางคล้ายกันใน /dev/push แล้วค่อยย้ายไปใช้ชุด FastAPI + Jinja2 + Alpine.js + HTMX
    พอได้รู้ว่า FastAPI ไม่ได้มีไว้แค่ API อย่างเดียว และฉันต้องการ async support เลยเลือกมัน
    ฉันก็ชอบ Flask แต่เคยรู้สึกว่ามันมีข้อจำกัดอยู่เหมือนกัน

  • วิธีรวม view กับ controller ไว้ในไฟล์เดียวทำให้นึกถึงการพัฒนา PHP สมัยก่อน
    ขึ้นอยู่กับขนาดโปรเจ็กต์ แต่มันก็มีข้อดีตรงที่ทำให้การพัฒนาง่ายขึ้นชัดเจน

  • ฉันคิดว่าชุด FastAPI + HTMX ก็มีประสิทธิภาพมากเหมือนกัน

• จากประสบการณ์กับ Django ฟีเจอร์ admin scaffolding ทำให้แทบไม่ต้องสร้าง UI สำหรับงานวินิจฉัยหรือซัพพอร์ตลูกค้าเองเลย
  แต่ในโปรเจ็กต์ที่ใช้เฟรมเวิร์กอื่น มักต้องทำสิ่งนี้เอง และผลลัพธ์ก็มักไม่น่าพอใจเท่า Django
  ถึงจะมีเฟรมเวิร์กที่ดูน่าสนใจอย่าง Hyperflask เยอะ แต่การยอมทิ้ง admin framework ของ Django ก็เป็นราคาที่แพงมาก
  เลยสงสัยว่ามีใครเจอทางเลือกหรือแพตเทิร์นทดแทน Django admin ได้จริงไหม

  • รู้สึกว่าเป็นเรื่องเดียวกันเลย
    ตอนย้ายไป FastAPI สิ่งที่คิดถึงที่สุดจาก Django คือแอปย่อยต่าง ๆ ที่ประกอบกันเป็นโปรเจ็กต์
    มารู้ทีหลังว่าการแยกเป็นกลุ่มตามหน้าที่อย่าง migration, static file, template ฯลฯ นั้นสะดวกแค่ไหน

  • ฉันใช้ Supabase เป็นส่วนใหญ่
    บางทีก็ฝึกให้แอดมินใช้งานผ่าน Supabase UI เพื่อจัดการเรื่องเร่งด่วน
    หรือถ้าเป็นไปได้ก็ใช้ Airtable เป็นแบ็กเอนด์
    แต่สุดท้ายก็มักจะคิดถึง Django admin มาก และชุด Django+HTMX ก็ดูน่าลองอยู่เสมอ

  • มี Flask-Admin เหมือนกัน แต่ก็เรียบง่ายกว่า Django Admin มาก
    ฉันอยากแก้ปัญหานี้ต่อไปในอนาคต

• หลังจากใช้ HTMX กับหลายเฟรมเวิร์ก ฉันมองว่าชุด Go + Templ + HTMX ผสมความอเนกประสงค์กับความเรียบง่ายได้ดี

  • จากประสบการณ์ของฉัน Go ค่อนข้างเยิ่นเย้อเกินไป เลยกำลังคิดจะย้ายจากชุด Go+Templ+HTMX ไปเป็น Flask + Jinja + HTMX แทน
    วิธีนิยามเทมเพลตของ Go รู้สึกว่ายุ่งยาก

  • ชุดที่ฉันอยากลองต่อไปมาก ๆ คือ FastAPI + Jinja2 + HTMX
    ตอนนี้ฉันกำลังใช้สแต็กนี้อยู่

• hyperflask ให้ความรู้สึกขัดกับปรัชญาของ Flask และ htmx
  มีชั้น abstraction เยอะเกินไป และแทบไม่เห็นจุดที่ผสานกับ htmx ชัด ๆ
  ฉันคาดหวังแนวทางแบบ FastHTML ที่ฝัง htmx มาในตัว

  • ฉันใช้งาน FastHTML อย่างสนุกมากจริง ๆ

• ทุกครั้งที่เห็นเดโม starfield ในแต่ละโปรเจ็กต์ ฉันมักจะคาดหวังว่าจะมีตัวปรับความเร็วและเอฟเฟกต์ให้ดาววิ่งตามเมาส์
  หวังว่า Hyperflask เวอร์ชันหน้าจะเพิ่มเข้ามา
  ตัวโปรเจ็กต์เองยอดเยี่ยมมาก และแม้ฉันจะชอบ Htmx แต่ช่วงนี้ก็กำลังจับตา Datastar อยู่ด้วย

  • ถ้ารันโค้ดข้างล่างในคอนโซล ก็สามารถใส่เอฟเฟกต์ต่าง ๆ รวมถึงปรับความเร็วได้

    new WarpSpeed("warpdrive", {
      "speed": 20,
      "speedAdjFactor": 0.03,
      "density": 2,
      "shape": "circle",
      "warpEffect": true,
      "warpEffectLength": 5,
      "depthFade": true,
      "starSize": 3,
      "backgroundColor": "hsl(224,15%,14%)", 
      "starColor": "#FFFFFF"
    });
    

  • สงสัยว่าหมายถึงฟีเจอร์แบบนี้หรือเปล่า

  • nova.app คือสิ่งที่ดีที่สุดที่ฉันเคยเห็นมาจนถึงตอนนี้

• ถ้าต้องการประสบการณ์ Fullstack Async แบบสมบูรณ์บนฐาน HTMX ก็ลองดู Litestar ได้เหมือนกัน

• ตอนเห็นครั้งแรก ฉันไม่ค่อยเข้าใจว่าทำไมต้องเอา HTML template ไปแปะไว้ในไฟล์ controller ของ Python โดยตรง
  มันดูซับซ้อนขึ้นเพียงเพื่อจะตัดฟังก์ชัน render ออกไปตัวเดียว
  เลยสงสัยว่าฉันพลาดประเด็นอะไรไปหรือเปล่า

  • วิธีนี้สอดคล้องกับหลักการ Locality of Behavior ที่ htmx ให้ความสำคัญ
    และได้แรงบันดาลใจมาจาก Astro Pages ฝั่ง JavaScript
    ในการใช้งานจริง ประสบการณ์นักพัฒนาก็ดีมาก
    • คำอธิบายเกี่ยวกับ Locality of Behaviour
    • คู่มือ Astro Pages

• หลายคนพูดถึงข้อจำกัดของ Flask และถามว่า 'ทำไมไม่ใช้ FastAPI' แต่ส่วนตัวฉันคิดว่า Litestar คือทางเลือกที่ดีที่สุด
  Litestar มี htmx support มาให้ในตัว
  ดูข้อมูลเพิ่มเติมได้ที่นี่