Comments 11
Прежде всего, Спасибо за статью. Добавил в избранное и посмотрю.
ИМХО: Главный вопрос с которого надо начинать подобную статью, не ПОЧЕМУ, а КОГДА.
Т.е. не с перечисления преимуществ, а с того, чтобы очертить границы применимости фреймворка. Тогда станет и понятно, пожертвовав чем добились этих преимуществ.
Еще бы скриншоты добавить. Например, тот же streamlit выглядит симпатично. Насколько я понимаю, это аналог
streamlit по функциональности больше похож на jypiter инструменты, визуализация диаграм.
Он поддерживает базовый UI из коробки. Но когда надо больше, то начинаются проблемы.
И еще streamlit интерактивный. Что с этим у fasthtml я не понял.
Я не большой эксперт в streamlit, так побаловаться.
Да скришотов явно не хватает, я это понял уже когда статью выставил)
Как по мне велосипед, который однажды вставит палки в колёса
А зачем сравнивать библиотеку для генерации кода с фреймворками? Это как слона и ежа сравнивать - абсолютно разные вещи.
Но перспектива есть значительная, например при написании модулей, сторонних интеграциях, а так же для создания nocode интерфейсов. Интересно как обстоят дела у fasthtml с интеграцией собственных паттернов. Объединив с интерфейсом на основе bootstrap может получится отличный продукт.
Лет 10-15 назад такого очень много было, потом шаблонизаторы победили, потом настала эпоха SPA over API. Наблюдаю новый виток, только прикручены модные завитушки.
Полагаю, проблемы будут те же — медленно это всё и не гибко. Но на маленьких проектах, на всяких интранетах и proof-of-concepts это, наверное, покатит. Смешно, если дальше начнут переизобретать шаблонизаторы.
Очень людям хочется совместить фронт и бэк, но пока так и не удаётся.
Хотелось бы ещё видеть ссылку на github проекта.
Ещё один момент. У вас указано, что установка производится pip install fasthtml, но на github (если это тот самый проект) указано pip install python-fasthtml
Глубокий Анализ FastHTML