81–90 of 229 posts
FastHTML's concept led me to consider a feature that allows direct deployment of PyQt code as web services, even without HTML knowledge, like "PyQtWeb."
PyQtWeb > FastHTML > [Streamlit, Gradio]
This looks really impressive. What is the idiomatic way to test webapps created with FastHTML?
Python is fast compared to something? Maybe fast enough to generate HTML.
Fast enough for YouTube, Instagram, and Dropbox. If you need to scale up bigger than that then maybe reach for something else I guess. Today's HN launch of FastHTML's home page was running on a $5/month hobbyist account at Railway.app, where it averaged 1% utilization of 1 VCPU. (The trick, as always, is to optimise the inner loops in your app as needed; often that just means using pre-existing fast libs for that bit…
really excited for this project. I hope it catches on. It has some really nice ideas in it, like all the stuff jeremy does!
I am honestly mostly interested in your reason, to mix HTML/CSS generation into the Python code. Disclaimer, I am very biased towards separation of concern and like my backend just returning JSON/XML/whatever data and a templating system. Of course this increases the ramp-up time to learn a framework, but then it is IMHO very powerful, flexible and fast.
Could you perhaps elaborate on your choice for FastHTML and what tradeoffs you see?
Python is fast compared to something? Maybe fast enough to generate HTML.
Back in ancient times, a software project I was working in, failed, precisely because of Python performance with the Zope framework, it was too slow to render a webpage that required more than a few interesting calculations.
Today the language is almost the same, but computers have a thousand times more memory, and the CPUs are similarly faster.
The exact same project would have been successful today, just like neural networks are cornerstones of modern computing, because of the advances in hardware.
Sorry, but I hate server-side "helper" functions that generate HTML. For one thing it's never the same as what eventually gets shown on the page. 99.9% of the time you're missing attributes when needs to be hacked around. Debugging is a nightmare. Refactoring is hell. And css programmers have no clue what to do with this. Maybe I'm missing something here. Why not a templating engine?
I think you are missing how htmx (https://htmx.org/) is intended to be used. You still have your regular HTML page and by interacting with that HTML, you trigger server-side functions that return HTML. That HTML is used to update only a small part of your page. htmx works with HTML fragments while HTML templates work with entire pages.
Python is fast compared to something? Maybe fast enough to generate HTML.
ROI is more important than silly benchmarks. https://www.tiobe.com/tiobe-index/ But, we can play the benchmark game, if that tops your morning cereal. Competes with Go. Blows most popular TS frameworks out of the water. https://www.techempower.com/benchmarks/#section=data-r22&hw=... For you: https://gprivate.com/6chku
The bottom of the benchmark table are all slow Python implementations xD
Oh my goodness. I like to keep things boring where possible and swore I would never stray from Django + HTMX + Django Ninja, but I am exceedingly tempted to use this in an upcoming project. Lovely architectural choices - bravo!
It's a bit of a tangent, but do you have any go-to resources for learning how to use Django-ninja with HTMX? I haven't really put a lot of time into it, but HTMX seemed difficult to use with JSON APIs on first attempt. I'm only really familiar with Django and DRF, but if love to switch at some point.