I’ve been burned by ASGI and asynchronous python so much in the past, I wouldn’t touch it again even if someone paid me for it. It’s prone to bugs, hard to debug and for little benefit.
Ludic: New framework for Python with seamless Htmx support
21–30 of 107 posts
Re: Ludic: New framework for Python with seamless Htmx support
#22I 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…
Re: Ludic: New framework for Python with seamless Htmx support
#23I don't know, every time I see people sneaking html into Python feels weird and wrong to me...
- Type safe HTML: you get an exception instead of malformed HTML
- Truly reusable components: any Python web framework, component packages are truly reusable in any other projects. I never seen this with template engines.
- Huge productivity boost: not even close! No hunting for templates, no jumping between files, everything is in Python functions.
- Composable elements: you can nest things as much as you want, refactor very easily. Doing this with templates is not even possible, or such a pain I never did it.
- Storybook: There are a couple ones for Django, but they are clunky and not reusable at all.
I felt the same for a long time, but started thinking about a nice API. It took me months, but I finally got it: https://github.com/kissgyorgy/compone
Re: Ludic: New framework for Python with seamless Htmx support
#24Re: Ludic: New framework for Python with seamless Htmx support
#25Earlier quoted context omitted.
Do you feel the same about sneaking html into javascript? Just curious if it's a Python-specific objection.
In general, this usually results in front-end logic being very tightly coupled with back-end logic. In some of the examples given, you even have database access in the same line that is generating the HTML document. https://github.com/paveldedik/ludic/blob/main/examples/click... It's the kind of thing that looks very cool and concise in small examples, but tends to become a nightmare when you are working on larger pr…
Python template engines have the exact same problem, just way less obvious.
It doesn't have to be that way. Make all the queries up-front and pass the result the same way as you would pass context to templates. This way, all your components are pure. The difference is explicitness. Much easier to spot where side-effects happen than in templates.
Re: Ludic: New framework for Python with seamless Htmx support
#26I 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…
Re: Ludic: New framework for Python with seamless Htmx support
#27Earlier quoted context omitted.
Do you feel the same about sneaking html into javascript? Just curious if it's a Python-specific objection.
In general, this usually results in front-end logic being very tightly coupled with back-end logic. In some of the examples given, you even have database access in the same line that is generating the HTML document. https://github.com/paveldedik/ludic/blob/main/examples/click... It's the kind of thing that looks very cool and concise in small examples, but tends to become a nightmare when you are working on larger pr…
I don't think the issue is "markup expressed in another language" - I think it's "poor application architecture". I don't dispute there might be a correlation between libraries and frameworks that do poorly on each - but that doesn't mean it's intrinsic.
Re: Ludic: New framework for Python with seamless Htmx support
#28I 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…
Re: Ludic: New framework for Python with seamless Htmx support
#29Thanks for the wave of nostalgia.
Re: Ludic: New framework for Python with seamless Htmx support
#30I’ve been burned by ASGI and asynchronous python so much in the past, I wouldn’t touch it again even if someone paid me for it. It’s prone to bugs, hard to debug and for little benefit.
How have you been burned? What kind of bugs did you have, and in what way was it difficult to debug?
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 touches it. (Quite different from my experience with Java, Javascript, C#, PHP, …)
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.
Most basically, an aiohttp server can only use one CPU thread at a time with the consequences that if one request holds the CPU for 5 seconds the server stops processing requests completely.. Although the aiohttp server could be reliable if you are almost entirely waiting for data to get back from the database, the residual amount of CPU load is going to put an upper bound on what the server can handle in the best case. If a coder is not so careful you get burned. My RSS reader has an AI component which runs completely in batch jobs, I don’t do any inference during requests which limits my flexibility and makes the application less “real-time” than it could be.
You can imagine systems where one aio server hands tasks off the another aio server but the blocking situation doesn’t get any better and if you want to make the system scalable there has to be at least one multiprocess or multithreaded server somewhere. At some point I am like “I have a 16 core machine but I am only using 1 core like my laptop in the 1990s” It didn’t help that my aio database drivers aren’t in conda which is another build hassle.
So last week I tore up the image sorter and rewrote it in Flask (my aio framework looks like Flask so it’s not too hard) and I run it out of gunicorn, I put a reverse proxy in front to deal with some Tailscale problems so I have IIS serving the images.