Live data from Hacker News

Show HN: Hstream – quick Python web apps – Streamlit alternative using htmx

github.com

1–10 of 19 posts

Show HN: Hstream – quick Python web apps – Streamlit alternative using htmx

#1
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.

Show HN: Hstream – quick Python web apps – Streamlit alternative using htmx
github.com

Re: Show HN: Hstream – quick Python web apps – Streamlit alternative using htmx

#5
So, I've had a lot of the same issues with Streamlit in terms of going beyond the very raw PoC phase, which is why we often end up using Plotly's Dash[1] framework (React + Flask) at work for this kind of task.

Taking a step back, what would the benefits be compared to Dash?

[1]: https://dash.plotly.com/

Re: Show HN: Hstream – quick Python web apps – Streamlit alternative using htmx

#7
Big fan of HTMX here. We have found it more productive for our team than the more mainstream JavaScript React type libraries for the majority of the dynamic web apps we build. It seems so much easier to grasp the server-side rendering hypermedia model. In addition, the simplicity of the development tools and process is far better. Love the model of HTMX with some _hyperscript sprinkled in. In the rare use cases this model won't suffice, then and only then do we plug in something more JavaScript heavy - not very often!

Re: Show HN: Hstream – quick Python web apps – Streamlit alternative using htmx

#8
This looks fantastic and the streamlit API is lovely to with with so it seems like a nice approach. Like others on this thread I’m a big django developer too; it’d be nice if the backend was swappable so you could run on flask or django as well…

Re: Show HN: Hstream – quick Python web apps – Streamlit alternative using htmx

#9

Big fan of HTMX here. We have found it more productive for our team than the more mainstream JavaScript React type libraries for the majority of the dynamic web apps we build. It seems so much easier to grasp the server-side rendering hypermedia model. In addition, the simplicity of the development tools and process is far better. Love the model of HTMX with some _hyperscript sprinkled in. In the rare use cases this…

could you talk about it a bit more ? especially for a react person. How would you term the developer experience of htmx?

Re: Show HN: Hstream – quick Python web apps – Streamlit alternative using htmx

#10

Big fan of HTMX here. We have found it more productive for our team than the more mainstream JavaScript React type libraries for the majority of the dynamic web apps we build. It seems so much easier to grasp the server-side rendering hypermedia model. In addition, the simplicity of the development tools and process is far better. Love the model of HTMX with some _hyperscript sprinkled in. In the rare use cases this…

could you talk about it a bit more ? especially for a react person. How would you term the developer experience of htmx?

Hi. Sure. The experience is extremely similar to the traditional/original Server Side Rendering model; that is, sending back HTML to the user agent. Where that traditional model was much too limited, by only allowing full page refreshes and only two elements that could do server interaction ( and ), HTMX is completely robust.

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 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.

Post reply on HN