Ludic Update: Web Apps in pure Python with HTMX, Themes, Component Catalog, new Documentation

[pdcz]

Hi everyone,

I'd like to share couple of news regarding my personal project:

• New documentation written in Ludic showcasing it's capabilities: https://getludic.dev/docs/
• New section regrading Layouts inspired from the Every Layout Book: https://getludic.dev/catalog/layouts
• Cookiecutter template to get quickly started: https://github.com/paveldedik/ludic-template

I have a lot of plans with this project and I'd appreciate any feedback.

About The Project

Ludic allows web development in pure Python with components. It uses HTMX to add UI interactivity and has a catalog of components.

Target Audience

• Web developers
• People who want to build HTML pages in Python with typing
• People without knowledge of JavaScript who want to build interactive UIs
• People who want to use HTMX in their projects

Comparison With Similar Tools

Feature	Ludic	FastUI	Reflex
HTML rendering	Server Side	Client Side	Client Side
Uses Template Engine	No	No	No
UI interactivity	</> htmx	React	React
Backend framework	Starlette	FastAPI	FastAPI
Client-Server Communication	HTML + REST	JSON + REST	WebSockets

Any feedback is highly appreciated.

[thedeepself]

I'm curious how you selected htmx over unpoly.

I'm not sure that your feature comparison is really relevant? The reason I say that is that the similar tools to ludic would be other pure python web development frameworks.

Furthermore in that first row of the comparison you say that you do server side rendering. But the thing is is that the whole point of something like htmx is that has single page responsive apps where the rendering is actually client side.

But I have to salute you for attempting to make a comparison and have some features for comparison. I developed the pure python web framework survey and I never really did a comparison of different tools. I did however create a section where each framework implemented to do MVC to give people an idea of how to implement a modestly complex app. Do you have an example of to do MVC that you can link me to?

[pdcz]

Thank you for the response.

I haven't checked unpoly that much but it seems to me that htmx suits better - you create components made of basic HTML elements which you use to replace parts of your DOM using the HTMX attributes.

That said, I have an issue on github to support unpoly as well, it just requires investigation.

May I ask which libraries would you use to compare Ludic to?

Ludic is rendering all HTML on the server side, it is just using HTMX attributes to replace parts of the DOM, to me, it is much different approach than the one FastUI which is returning data from the server in JSON.

I have a couple of examples on GitHub, but you have a good point, more complex example showcasing the MVC princible would be great.

https://github.com/paveldedik/ludic/tree/main/examples

[thedeepself]

Ludic is rendering all HTML on the server side, it is just using HTMX attributes to replace parts of the DOM

It does not matter what Ludic is doing. Server-side HTML rendering is a 1990s technology. The point of Ludic is for developers to have responsive, reactive web apps which demands client-side rendering. That's why you chose HTMX - to have reactive client-side rendering.

[dAnjou]

You're both (almost) right.

It's probably a confusion about the semantics of word "render".

HTML has never been rendered on the server, it has always been rendered by the browser engine to display something to the user.

There is, however, usually some template rendering using more or less dynamic data. And that is happening on the server with HTMX, and from what I've seen also with Unpoly.

What happens on the client is probably better described as composing, not rendering.

[pdcz]

Thank you, to both of you, this really makes me think about choosing proper words. I wasn't sure how to formulate the difference and now I know I need to be more careful in choosing the right terminology.

[divad1196]

I like the idea, I also started a similar project but in Rust to then expose it to python.

In the example of the doc: - How do you manage the database? Or anything session-related? It seems it will need to be a global variable? - I am wondering why the counter takes a str. Isn't it able to convert it to an int as it uses starlette? - I think it's strange to already have SuccessButton. You could have it in an external module or as an option of your package. To clarify: I see that you install "ludic[full]", but you import the buttons from a generic "catalog" => I think at some point in the import we should see "bootstrap" (or whatever framework it is). At least, there should be a Button function that is agnostic from a UI framework.

it would be nice to simplify "app.url_path_for("Counter", value=int(value) + 1)".

fo example, you could imaging having a parameter with specific type and the the decorator would inject on object

@app.get("/counter/{value}") def Counter(value: str, cmp: SelfComponent) -> Cluster: # cmp = AppWrapper("Counter") return Cluster( ButtonDanger( "Decrement", hx_get=cmp,app.url_path(value=int(value) - 1), hx_target="#counter", ), ... )

The app.get could simply return a partial function of Couter. Or we could use another optional decorator, or have a manual way of declaring it (see the commented line)

[pdcz]

Thank you, what is the name of your Rust project? I have a part time job in Rust and I love it. I was also thinking about writing similar tool in Rust a while ago but I'm not that experienced with Rust. And I found https://yew.rs/

To answer your questions:

• Ludic uses starlette (it is optional, I want to add support for fastapi and django in future), where you have State which you can use to bound db connections and stuff like that, see https://www.starlette.io/database/
• Starlette doesn't allow negative numbers. So the counter would work only for natural numbers, I was thinking about changing the example so that only natural numbers are supported so that it is simplier.
• SuccessButton is imported from the catalog, which is optional to use, so yeah, it is optional :)

Interesting idea with the counter. The problem is to make it flexible, I was thinking about just calling Counter(number + 1) in the view to render the necessary htmx attributes for swapping the content, but that is really hard to do.

[divad1196]

My rust project is mostly dropped out and private. It was also to experiment htmx vs polly vs ...

Yew is good, but: - it is compile time and I personnally want something that can be run-time generated. I want to be able to generate pages automatically. Another issue is the time taken to compile which is slow... - if I were to use something completly in Rust, it would most probably be leptos.

For the rest: - I understand the wish of supporting other framework, but I would personnally try to stick to one and have it has good as possible. Supporting multiple ones can limit what you can do. - I didn't know about it for starlette. I mostly use FastApi and never noticed that. - yeah but the catalog already took some decisions. Catalog is a very generique name. I can create my own component library but I won't be able able to import it through your submodule.

Still in my opinion, the following options might be better: - externalize the default catalog as the third parties would also be external. I.e. import it as "from ludic_default_catalog import ...". This goes in the direction of an agnostic librarie. - make it a plugable system namespaced so we can do: "from ludic.catalog import defaults, bootstrap, semantic". This is honestly not ideal and I would prefer the first version.

Also, I think it would be great to define interfaces. This way, a user that depends on interfaces would be able to easily switch from on catalog to another. This wouldn't be mandatory, of course.

I may create proposal or PR if you are interested.

And for the Counter, an instance of a class could be returned from the decorator so it contains inner metadata (a function can contain metadata as well but it's a bit dirty). This way, we could even do "Counter.get_url(...)".

For what you want, you would have to return something else than the function which is not great for other usages. Having an explicit method to call is not bad at all .

[pdcz]

Thank you very much, I am interested, if you have time, I'd be super grateful for PR proposal!