Show HN: Hstream – quick Python web apps – Streamlit alternative using htmx (github.com)
I love Streamlit but have run into many situation where taking it from PoC to MVP state is insurmountable.
With all the recent HN hype around htmx and sematic html / classless css I decided to build a Streamlit alternative using these on top of FastAPI.
This has a couple advantages: 1) easier to extend when you move past PoC since the FastAPI app is exposed (allowing adding more routes) and hstream acts more like a typical web stack 2) with htmx and html (plus MVP.css) doing the heavy lifting the package is alot less complex and easier to reason about - and hopefully more performant eventually 3) html is simple, so using this we can give the user much more control around the look and feel, while falling back onto MVP.css (classless css) sane defaults.
Would love to hear people's thoughts.
18 comments
[ 38.9 ms ] story [ 204 ms ] threadProof of Concept, or initial prototype.
Taking a step back, what would the benefits be compared to Dash?
[1]: https://dash.plotly.com/
When writing a python script you tend to think from top to bottom - as your script runs through. Dash adopts the html approach of defining a document and callbacks. After doing the refactor to this model I found the trade-offs of Dash wasn't worth the time saved of going straight to a more traditional stack, and again you're pretty locked-in to this choice now.
One example was writing a Dash SSO component turned into quite an ordeal (more so than most SSO integrations) - my aim here is to make an extension like this easier because you've got access directly to the FastAPI app with `hs.app`.
HTMX allows you as the developer to fire a server side request from ANY HTML element for all the HTTP METHODS (GET, DELETE, POST, PUT etc.). In addition, you decide and design what HTML fragment you will return from the server and where it should be swapped into in the browser's page. So instead of full page refreshed, you are surgically updating anywhere in the DOM quickly - very quickly.
I want to be clear, you, as a developer, are thinking this model and flow FROM THE SERVER SIDE of things. You are returning fragments or chunks of HTML as the response, NOT JSON. With all things in technology, obviously, there are trade-offs, but eliminating the JSON layer and the client code layer, you are eliminating a massive class of complication.
Also, I would like to stress, that this does sound very similar to jQuery and other things like that, but it is pretty different and better IMO because it is coded as attributes in the element tags. As they say on their site, it truly feels like this is what HTML would have felt like if it was continued and completed, instead of veering off into heavy use JavaScript land like we did as an industry.
There are many nice little features to add to the dynamic feel of your web apps, such as in progress indicators and CSS animations; again all specified as attributes in the tags.
Finally, the development environment is basically a non-existent complication. It is a tiny (~12k) js file and <script> inclusion. You choose any traditional SSR library for your language of choice. HTMX can actually breathe life back into server side languages, where instead of writing monotonous and boring end-points attempting to be some sort of data access layer, you are writing fully robust code, and you have full power and access to your real data layers.
Yikes hope that wasn't too verbose and answered your question ;) But I really love HTMX after so many years of what I have considered toiling with web UIs. Hypermedia is supposed to be the ultimate thin client model as termed by HATEAOS, not insanely rich clients trying to emulate client server interactions through REST API IMHO.
I think it's also worth giving a shoutout to wave in this space; they have quite a few components you can use out-of-the-box https://github.com/h2oai/wave