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

[conradbez]

https://github.com/conradbez/hstream

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.

[silver-arrow]

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!

[sandGorgon → silver-arrow]

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

[silver-arrow → sandGorgon]

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 (<a> and <form>), 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 <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.

[mxuribe → silver-arrow]

I've heard of htmx but only from a headline or two, here and there....but hearing your description really interests me a ton to learn about htmx. Thanks for sharing!

[infogulch → mxuribe]

If you like video format the best presentation (imo) by the author, Carson Gross, is this one: https://www.youtube.com/watch?v=LRrrxQXWdhI

[silver-arrow → mxuribe]

No problem. Check out their site for some wonderful examples of what it can do and have fun!

[ZeroCool2u]

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/

[conradbez → ZeroCool2u]

When dash came out I was a massive fan but found the abstraction layer not quite right.

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

[zachwill]

Huge fan of Streamlit — I've used it a ton at work — and HTMX + Django is my preferred method for building larger sites. Cool work!

[boxed]

Writing an API that scales from quick PoC to MVP to serious production is in my opinion a problem space that is mostly not explored. We've tackled this with iommi (https://docs.iommi.rocks) with deep customization while at the same time having super fast PoC. We are not satisfied with the performance yet though, but at this point it's good enough for most uses.

[conradbez → boxed]

Wow this looks awesome! Definitely have a bit of a browse, thanks!

[nvusuvu]

What's PoC mean?

[unoti → nvusuvu]

> What's PoC mean?

Proof of Concept, or initial prototype.

[knowsuchagency]

I think the demo site may have been hugged to death. It's not rendering anything for me.

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

[abraxas]

I'm quite the fan of streamlit but do not love its way of handling state. The only way to have a semblance of state captured between browser refreshes in streamlit is through query params. Have you taken a bite at that problem in your framework?

[shapiromatron]

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…

[conradbez → shapiromatron]

Thanks! Yeah interesting idea on the swappable backend, something I'll consider.

[recursivedoubts]

Very cool!