Hyperflask – framework Flask và Htmx full-stack

(hyperflask.dev)

11 điểm bởi GN⁺ 2025-10-17 | 1 bình luận | Chia sẻ qua WhatsApp

Là framework web ưu tiên backend dựa trên Flask, cung cấp quản lý trạng thái nhanh và đơn giản mà không cần quản lý frontend phức tạp
Giới thiệu kiến trúc component kết hợp với HTMX, cho phép xây dựng UI tương tác dựa trên server
Tích hợp stack web hiện đại như định tuyến dựa trên tệp, pipeline tài sản esbuild + TailwindCSS, môi trường triển khai tự động hóa
Tích hợp sẵn nhiều tính năng cơ bản như gửi email (MJML), tác vụ nền, push dựa trên SSE, dịch thuật, xác thực
Chuẩn hóa môi trường phát triển và triển khai dựa trên container cùng tích hợp VS Code, hỗ trợ cấu hình dễ dàng và triển khai lên đám mây

Tổng quan: framework webapp ưu tiên backend dựa trên Flask

Hyperflask là framework web Python chạy trên Flask, theo đuổi thiết kế do backend dẫn dắt
Giảm độ phức tạp trong quản lý trạng thái frontend và cung cấp kiến trúc gọn gàng lấy server làm trung tâm
Tích hợp sẵn các công nghệ web hiện đại như HTMX, TailwindCSS, esbuild
Thông qua tích hợp HTMX, có thể triển khai tương tác thời gian thực mà không cần tải lại toàn bộ trang
Với kiến trúc component, có thể tái sử dụng component backend và frontend
- Đưa cấu trúc lấy component làm trung tâm vào môi trường Flask, cho phép dùng trực tiếp component frontend và backend trong template Jinja
- Có thể tạo component backend phía server kết hợp với HTMX, đồng thời tích hợp tự nhiên với React hoặc web component
- Nâng cao khả năng tái sử dụng mã và khả năng bảo trì, cung cấp cấu trúc phù hợp cả cho phát triển ứng dụng quy mô lớn
Hỗ trợ định tuyến dựa trên tệp và định tuyến dựa trên ứng dụng
- Sử dụng định dạng tệp .jpy mới kết hợp mã Python và template Jinja
- Lấy cảm hứng từ hệ thống trang của Astro, cho phép quản lý định nghĩa route và cấu hình UI tại một nơi
- Nhờ đó việc cấu hình định tuyến được đơn giản hóa và việc thêm trang mới trở nên trực quan
Hệ sinh thái mở
- Hyperflask có codebase riêng nhỏ gọn và được cấu thành bằng cách kết hợp hữu cơ nhiều phần mở rộng của Flask
- Mỗi phần mở rộng được quản lý như dự án độc lập, cho phép tự do lựa chọn và kết hợp
- Tất cả dự án đều được công khai trong tổ chức Hyperflask trên GitHub và khuyến khích xây dựng framework tùy biến theo nhu cầu người dùng
“Batteries Included”
- Gửi email bằng MJML, tác vụ nền với dramatiq, push thời gian thực dựa trên SSE, dịch dựa trên gettext (i18n)
- Xác thực và quản lý phiên, tối ưu hóa và streaming hình ảnh, tạo nội dung tĩnh
- Cung cấp bộ tính năng cấp production có thể dùng ngay mà không cần cấu hình riêng
- ORM thiên về SQL (sqlorm), tối ưu cho SQLite
Thiết lập môi trường và triển khai
- Chuẩn hóa môi trường phát triển/vận hành dựa trên container để giảm thiểu vấn đề cấu hình môi trường
- Tích hợp chặt chẽ với VS Code giúp phát triển và debug cục bộ dễ dàng
- Hỗ trợ triển khai dễ dàng lên VPS hoặc các dịch vụ đám mây lớn

Tóm tắt

Hyperflask là framework thế hệ mới mở rộng hệ sinh thái Flask để mang lại trải nghiệm phát triển web Python full-stack hiện đại
Thông qua HTMX, hệ thống component, định tuyến dựa trên tệp và môi trường phát triển chuẩn hóa bằng container, framework này hiện thực hóa năng suất tối đa với cấu hình tối thiểu

1 bình luận

GN⁺ 2025-10-17

Ý kiến Hacker News

Là tác giả của hyperflask, tôi rất vui vì cuối cùng cũng có thể công bố dự án đã chuẩn bị trong thời gian dài này
Có thể xem bài công bố chi tiết tại đây
Tôi rất muốn nhận được nhiều phản hồi khác nhau
- Sẽ tốt hơn nếu cách này là một thư viện không phụ thuộc vào backend cụ thể
  Dự án Django hiện tại của tôi đã hơn một triệu dòng nên không thể dễ dàng thay đổi, nên tôi muốn biết có cách nào áp dụng nó một cách thuận tiện vào ứng dụng Django hay không
- Với tư cách là một lập trình viên htmx, dự án này trông thực sự rất tuyệt
- Một đồng nghiệp của tôi từng xây một ứng dụng nội bộ bằng tổ hợp flask/htmx/sqlalchemy và đã có kết quả tốt, nhưng không được phê duyệt để mở mã nguồn
  Vì vậy tôi đang kỳ vọng vào hướng đi mới của hyperflask
- Tôi tò mò vì sao lại chọn sqlorm làm ORM
  Tôi đã xa rời phát triển Python khá lâu, nhưng cứ nghĩ mọi người đều dùng SQLAlchemy, còn sqlorm thì tôi thấy khá lạ
- Thật ấn tượng khi thấy một framework mới đón nhận HTMX
  HTMX đang thúc đẩy nhiều xu hướng mới đa dạng nhằm thay thế JS và React
  Chắc chắn cũng sẽ có nhiều người thích tổ hợp Python và Flask, và trong HTMX phía máy chủ thì component là cốt lõi
  Ngoài ra trang chủ của dự án cũng dễ nhìn hơn FastHTML
  Nếu so với harcstack.org thì
```
Language: Python vs. Raku  
Web framework: Flask vs. Cro  
ORM: ?? vs. Red  
Components: cả hai đều có  
HTML: template vs. hàm  
CSS: DaisyUI/Tailwind/Bootstrap vs. Pico  
```
  Những lựa chọn như vậy có vẻ sẽ thu hút được tệp người dùng rộng hơn nhiều
  Còn HARC stack, đối tượng so sánh ở đây, có lẽ sẽ hấp dẫn với một nhóm nhỏ thích xử lý HTML theo kiểu hàm giống như phiên bản server-side của ngôn ngữ Elm, hoặc dị ứng với tính phi chuẩn hóa của Tailwind
Khi phát triển webapp bằng htmx, tôi đã cảm thấy đây là một "ngõ cụt"
Vấn đề chính là trạng thái của ứng dụng frontend phải được lưu trong URL
Với UI hiện đại có nhiều khu vực, widget, popup... mỗi phần đều cần trạng thái cục bộ và điều hướng riêng, việc nhét toàn bộ trạng thái vào một URL toàn cục là cực kỳ khó
Thiết kế theo hướng không đưa trạng thái vào URL khi cần còn khó hơn
Những vấn đề như vậy được giải quyết dễ dàng trong các framework như React hay Vue vốn cung cấp kho lưu trữ trạng thái riêng
Nếu xây kiểu phpBB forum thì có thể ổn, nhưng người dùng ngày nay kỳ vọng trải nghiệm tiến bộ hơn
- Không nhất thiết phải chỉ lưu trạng thái trong URL
  Có nhiều cách như kho lưu trữ phía server, session, localstorage, cookie...
  Ví dụ, việc tùy biến layout ứng dụng của người dùng không cần URL, nhưng với kết quả tìm kiếm cần khả năng chia sẻ thì điều kiện tìm kiếm nhất định phải có trong URL
  Cần suy nghĩ xem mình muốn đạt được điều gì
  Và việc nhồi rất nhiều widget, popup lên cùng một màn hình/một URL dưới danh nghĩa "UI hiện đại" đôi khi lại là độ phức tạp quá mức
  Nhiều khi phần lưu trạng thái mà React/Vue cung cấp chỉ là sự trùng lặp với thứ vốn đã có thể quản lý hoàn toàn ở server
- Cách tiếp cận hypermedia vẫn có thể xử lý UI đủ phức tạp
  Không cần phải khăng khăng đưa mọi thứ vào URL
  Có thể dùng session, cookie, tab ID... để chia sẻ/cô lập trạng thái theo từng tab, rồi tra cứu trạng thái trong DB backend
  Hypermedia còn rất mạnh trong môi trường thời gian thực/nhiều người chơi
  Ngược lại, điểm yếu của HTMX là chưa đặt đủ nhiều trạng thái vào backend, và tôi thậm chí còn muốn nó đi xa hơn theo hướng đó
- Tôi nghĩ đơn giản là nó không hợp với use case của tôi
  Cũng thú vị khi có người cho rằng React/Vue là "dễ"
- Tôi không nghĩ React hay Vue cũng giải quyết được mọi vấn đề mà người dùng kỳ vọng
- Trừ khi độ phức tạp thực sự rất cao, còn không thì trên thực tế tôi vẫn xử lý ổn phần lớn trường hợp bằng htmx (kết hợp unpoly, alpinejs, localstorage)
Tôi thấy vài khái niệm thú vị trong hyperflask
- Cách triển khai component: liên kết
- Cách gộp view và controller vào một file: liên kết
  Nhưng thực ra component về bản chất chỉ là macro thông thường ở bên trong, nên tôi tự hỏi có phải dùng trực tiếp macro sẽ tốt hơn không
  Tôi cũng tò mò vì sao lại chọn Flask
  Trước đây tôi từng thử một cách tiếp cận tương tự với /dev/push rồi chuyển sang tổ hợp FastAPI + Jinja2 + Alpine.js + HTMX
  Tôi nhận ra FastAPI không chỉ dành cho API, và đã chọn nó vì cần hỗ trợ bất đồng bộ
  Tôi cũng thích Flask, nhưng từng cảm thấy nó có giới hạn
- Cách gộp view và controller vào một file làm tôi nhớ đến kiểu phát triển PHP ngày xưa
  Tùy quy mô dự án, nó đúng là có ưu điểm ở chỗ giúp việc phát triển đơn giản hơn rõ rệt
- Tôi cũng nghĩ tổ hợp FastAPI + HTMX rất hiệu quả
Theo kinh nghiệm của tôi với Django, nhờ tính năng admin scaffolding nên gần như không cần tự xây UI cho chẩn đoán và hỗ trợ khách hàng
Ở các dự án dùng framework khác, người ta thường phải tự triển khai chức năng này và kết quả nhiều khi không được thỏa đáng như Django
Có rất nhiều framework trông hấp dẫn như Hyperflask, nhưng từ bỏ framework admin của Django là cái giá rất lớn
Tôi tò mò không biết có ai đã tìm ra phương án thay thế hay mô hình khác cho Django admin hay chưa
- Tôi cũng cảm thấy như vậy
  Khi chuyển sang FastAPI, điều tôi nhớ nhất từ Django là các app khác nhau cấu thành dự án
  Mãi sau này tôi mới nhận ra cấu trúc gom nhóm theo chức năng như migration, static file, template... tiện đến mức nào
- Tôi chủ yếu dùng Supabase
  Tôi cũng huấn luyện quản trị viên dùng UI của Supabase để xử lý các tác vụ quản trị khẩn cấp
  Hoặc nếu có thể thì đôi khi dùng Airtable làm backend
  Nhưng phần lớn thời gian tôi vẫn rất nhớ Django admin, và tổ hợp Django+HTMX lúc nào cũng có sức hút lớn
- Có Flask-Admin, nhưng nó đơn giản hơn Django Admin rất nhiều
  Tôi muốn giải quyết vấn đề này trong tương lai
Sau khi dùng HTMX với nhiều framework khác nhau, tôi thấy tổ hợp Go + Templ + HTMX kết hợp rất tốt giữa tính đa dụng và sự đơn giản
- Theo kinh nghiệm của tôi thì Go quá dài dòng, nên ngược lại tôi đang cân nhắc chuyển từ Go+Templ+HTMX sang Flask + Jinja + HTMX
  Tôi thấy cách định nghĩa template của Go khá phiền
- Lần tới tôi rất muốn thử tổ hợp FastAPI + Jinja2 + HTMX
  Hiện tại tôi đang dùng stack này
Tôi có cảm giác hyperflask đi ngược lại triết lý của Flask và htmx
Có quá nhiều tầng trừu tượng, và cũng không thấy nhiều điểm tích hợp với htmx
Tôi đã kỳ vọng vào kiểu htmx được tích hợp sẵn như FastHTML
- Tôi đang dùng FastHTML và thấy nó thực sự rất thú vị
Cứ mỗi lần thấy demo starfield (hiệu ứng bầu trời sao) trong một dự án, tôi lại luôn mong có tính năng chỉnh tốc độ và hiệu ứng đi theo con trỏ chuột
Hy vọng phiên bản Hyperflask tiếp theo sẽ bổ sung
Bản thân dự án thì rất tuyệt, tôi thích Htmx, nhưng gần đây cũng đang để mắt tới Datastar
- Nếu chạy đoạn mã dưới đây trong console thì có thể tạo nhiều hiệu ứng khác nhau như chỉnh tốc độ
```
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"
});
```
- Bạn có đang nói đến tính năng kiểu này không?
- nova.app là thứ tốt nhất tôi từng thấy cho đến nay
Nếu muốn có trải nghiệm Fullstack Async hoàn chỉnh dựa trên HTMX thì Litestar cũng là một lựa chọn đáng tham khảo
Khi mới nhìn, tôi khó hiểu vì sao lại cần cấu trúc gắn trực tiếp template HTML vào file controller Python
Nó tạo cảm giác phức tạp hơn chỉ để bớt đi một hàm render đơn giản
Tôi muốn biết liệu mình có đang bỏ lỡ điểm nào không
- Cách này khá phù hợp với nguyên tắc Locality of Behavior mà htmx coi trọng
  Nó được lấy cảm hứng từ Astro Pages bên phía JavaScript
  Trải nghiệm của lập trình viên trên thực tế cũng khá tốt
  - Giải thích về Locality of Behaviour
  - Giới thiệu Astro Pages
Nhiều người nói về giới hạn của Flask và hỏi "vì sao không phải FastAPI", nhưng cá nhân tôi cho rằng Litestar mới là phương án thay thế tốt nhất
Litestar cung cấp hỗ trợ htmx ngay từ mặc định
Có thể xem thêm thông tin chi tiết tại đây

Hyperflask – framework Flask và Htmx full-stack

Tổng quan: framework webapp ưu tiên backend dựa trên Flask

Tóm tắt

Bài viết liên quan

1 bình luận

Ý kiến Hacker News