Live data from Hacker News

Ludic: New framework for Python with seamless Htmx support

github.com

41–50 of 107 posts

Re: Ludic: New framework for Python with seamless Htmx support

#41

I have been working on a (currently half-baked) similar project: - https://github.com/abilian/webbits > Inspirations for the idea of generating HTML code from Python: - https://www.yattag.org/ > - https://tylerbakke.github.io/MarkupPy/ > - https://github.com/michaeljones/packed > - https://github.com/twidi/mixt/ > - https://github.com/byteface/domonic > - https://pypi.org/project/hyperpython/ > - https://pypi.org/pro…

I can only say that I like fast_html and how simple it is. Very easy source to read and understand. It is based on generators internally.

I started using it for some documentation generation purposes. I'm not a web-dev.

Re: Ludic: New framework for Python with seamless Htmx support

#42
post #13

I wrote a library a little while ago which is intended to be the simplest possible expression of this idea: https://github.com/j4mie/hotmetal/ The core implementation is only 85 lines of Python, and has no imports at all, so works nicely on minimal/alternative Pythons like Micropython. I'm using it on a medium-sized side project and it's shockingly productive compared to string templates. I don't think anyone is usin…

I've been looking for something exactly like this for a while — a small Python library for generating HTML that isn't prescriptive about framework and doesn't introduce any particually weird syntax. Jinja2 macros are... not great when you want to turn your HTML into lots of smaller functions.

Re: Ludic: New framework for Python with seamless Htmx support

#43
post #4

I don't know, every time I see people sneaking html into Python feels weird and wrong to me...

I imagine a lot of this comes down to personal preference. In the early days of Mountaineer [^1] (gee, almost two months ago at this point), I played around with the idea of embedding html into python instead of needing a JS layer. Eventually my consensus was:

- The most flexible shim approaches typically end up wrapping JS/React components anyway (like Reflex/Pinecone)

- We really need better IDE support for html strings that are within python strings. The editing problem is a big setback.

The ergonomics of Python + JS in separate code files won out and the user experience has been better than forcing them both into a common language would be.

This has the benefit of leveraging whatever the two languages are best at, in native code, so you have access to all the native APIs without having to learn a shim on top of it. Way more longevity to that approach too. Context switching between two languages isn't that bad if you minimize the glue layer that you have to write between them.

[^1]: https://github.com/piercefreeman/mountaineer

Re: Ludic: New framework for Python with seamless Htmx support

#44
I wish someone would sponsor development of HTMX support via NginX or Apache2 modules. That way you don't have to go to python, php, java, etc... to get HTMX support. You would just enable the module, configure a few things and let it rip. Kinda like server side includes in Apache2.

Re: Ludic: New framework for Python with seamless Htmx support

#45

Earlier quoted context omitted.

I think those are all good points, but do cringe a little at the idea that "to add your own JavaScript you'll want React". Seems like a lot to bring in if you're really just wanting to add some JavaScript.

Ha, fair point. I don't mean so much that for any JS you'd want to bring in React, but more that something like that will likely be needed to manage a codebase of any scale. My context here is a mostly server-side application using HTMX, where I wanted to add a few small bits of additional client-side code. I tried to do it without any libraries but rapidly realised that Jquery would simplify things a lot, and manage…

Yeah, it is insane how complex and wonky attempting to manage state becomes without a coherent model.

I kind of see HTMX as discouraging the traditional SPA-ish state management approach though. Or, it could be that the idea just gives me peace of mind. But, the idea being that you manage state less on the client because you're updating the UI with DOM content generated on the server versus rendering from local state on the client.

In practice, of course, avoiding client-state can be tough, especially as you go from sprinkling in limited dynamic interaction to a full-on SPA experience. I'm a little different though, in that I'm not sure SPAs were ever a good idea—at least without shifting completely away from building directly on Web idioms like DOM, HTML and CSS.

Re: Ludic: New framework for Python with seamless Htmx support

#46
post #13

I wrote a library a little while ago which is intended to be the simplest possible expression of this idea: https://github.com/j4mie/hotmetal/ The core implementation is only 85 lines of Python, and has no imports at all, so works nicely on minimal/alternative Pythons like Micropython. I'm using it on a medium-sized side project and it's shockingly productive compared to string templates. I don't think anyone is usin…

see also: twisted nevow + stan, which I believe predate the term 'AJAX'.

https://github.com/twisted/nevow/blob/master/examples/simple...

Re: Ludic: New framework for Python with seamless Htmx support

#47

Earlier quoted context omitted.

Ha, fair point. I don't mean so much that for any JS you'd want to bring in React, but more that something like that will likely be needed to manage a codebase of any scale. My context here is a mostly server-side application using HTMX, where I wanted to add a few small bits of additional client-side code. I tried to do it without any libraries but rapidly realised that Jquery would simplify things a lot, and manage…

Yeah, it is insane how complex and wonky attempting to manage state becomes without a coherent model. I kind of see HTMX as discouraging the traditional SPA-ish state management approach though. Or, it could be that the idea just gives me peace of mind. But, the idea being that you manage state less on the client because you're updating the UI with DOM content generated on the server versus rendering from local state…

Yeah this is exactly it, HTMX does discourage this. And this is why my conclusion from my experience was that you either need to only use HTMX, or to do frontend "properly" with some sort of state management, because being somewhere in the middle is a pretty bad experience.

Re: Ludic: New framework for Python with seamless Htmx support

#48
I think these kinds of tools are awesome, although I normally prefer not having to rely on getting the functions/classes/types defined for me, I usually find it easier to just use lxml[0] to build HTML components from composable Python functions[1], similar to React.

[0]: https://lxml.de/lxmlhtml.html#creating-html-with-the-e-facto...

[1]: https://ricardoanderegg.com/posts/python-build-html-componen...

Re: Ludic: New framework for Python with seamless Htmx support

#49
post #13

I wrote a library a little while ago which is intended to be the simplest possible expression of this idea: https://github.com/j4mie/hotmetal/ The core implementation is only 85 lines of Python, and has no imports at all, so works nicely on minimal/alternative Pythons like Micropython. I'm using it on a medium-sized side project and it's shockingly productive compared to string templates. I don't think anyone is usin…

We've come full circle on naming HTML tools! https://en.wikipedia.org/wiki/HoTMetaL

Glad someone got the reference!

Re: Ludic: New framework for Python with seamless Htmx support

#50
post #9

Earlier quoted context omitted.

How have you been burned? What kind of bugs did you have, and in what way was it difficult to debug?

Myself I built an RSS reader using aiohttp and then forked the code to make an image sorter. I had a lot of people tell me I was crazy to write aiohttp servers because of the problems the previous poster mentioned but I had a long run of it working pretty well. On the other hand I’ve frequently had the experience of writing something in Python that falls apart like a tower of Jenga blocks the moment somebody else tou…

> Once I started serving images along with the text and using the app over a 2Mbps link it seemed to me the aiohttp server was getting a little unreliable.

Does that imply that it was due to images being heavier, and thus if you were to stream something like video from aiohttp it would not go so well?

Post reply on HN