[HN Gopher] Show HN: Hstream - quick Python web apps - Streamlit...
       ___________________________________________________________________
        
       Show HN: Hstream - quick Python web apps - Streamlit alternative
       using htmx
        
       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.
        
       Author : conradbez
       Score  : 75 points
       Date   : 2022-11-10 15:25 UTC (7 hours ago)
        
 (HTM) web link (github.com)
 (TXT) w3m dump (github.com)
        
       | ZeroCool2u wrote:
       | 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/
        
       | shapiromatron wrote:
       | 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...
        
       | abraxas wrote:
       | 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?
        
       | boxed wrote:
       | 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.
        
       | recursivedoubts wrote:
       | Very cool!
        
       | zachwill wrote:
       | 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!
        
       | nvusuvu wrote:
       | What's PoC mean?
        
         | unoti wrote:
         | > What's PoC mean?
         | 
         | Proof of Concept, or initial prototype.
        
       | silver-arrow wrote:
       | 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 wrote:
         | could you talk about it a bit more ? especially for a react
         | person. How would you term the developer experience of htmx?
        
           | silver-arrow wrote:
           | 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 wrote:
             | 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!
        
               | silver-arrow wrote:
               | No problem. Check out their site for some wonderful
               | examples of what it can do and have fun!
        
               | infogulch wrote:
               | If you like video format the best presentation (imo) by
               | the author, Carson Gross, is this one:
               | https://www.youtube.com/watch?v=LRrrxQXWdhI
        
       ___________________________________________________________________
       (page generated 2022-11-10 23:01 UTC)