HN Explorer

Show HN: Web Development with Htmx, Type-Guided Components, Pure Python (getludic.dev)

107 points by paveldedik ↗ HN
Ludic is my personal project I started working on as I saw an opportunity to write websites in Python without the need to use template engines and write complex JavaScript (thanks to htmx.org). Ludic prioritizes simplicity - no convoluted HTML, straightforward and responsive CSS, and minimal JavaScript requirements.

I'm looking for feedback for the documentation I was building:

* https://getludic.dev/docs/

This documentation showcases the range of features the framework offers, providing a comprehensive overview of its capabilities.

I would also appreciate if you checked the layouts section and tell me what you think:

* https://getludic.dev/catalog/layouts

Additionally, I've developed a convenient cookiecutter template:

* https://github.com/paveldedik/ludic-template

I eagerly await your feedback and insights as you explore these resources.

I believe Ludic can be expecialy good for personal blogs, project websites, in-browser slides, while using htmx.org properties to add interactivity.

Since my last update on Ludic, I've concentrated on the following areas:

* Building comprehensive documentation with Ludic to showcase its capabilities * Enhancing the UI components catalog * Crafting Layout Components inspired by the Every Layout Book * Introducing support for Themes

Future plans for Ludic include:

* Enhancing HTMX support with compatibility for HTMX 2.0 * Implementing speed improvements through caching * Expanding the features in the catalog * Improving typing support * Exploring the creation of a cookiecutter template for generating Ludic-powered slides

38 comments

[ 33.6 ms ] story [ 1199 ms ] thread
pbronez
On mobile, when I hit the docs link, the actual content falls below the fold. The search bar and ToC take up the whole screen. Recommend you collapse the ToC to a menu button and shrink the search bar.
pbronez
You might expand on your examples to demonstrate persistence. You mention that the cookie cutter template has “many modules are missing, such as models and database connections.” I think this is a meaningful gap to fill.

The initial button example might be a good one to build on. You could show how to persist the counter value in SQLite.

pbronez
It would be nice to have a “next page” button at the bottom of the documentation pages, so you can read straight through without popping back up to the ToC.
paveldedik
Thank you very much, really good advice here.
[deleted]
(comment deleted)
leejoramo
This looks interesting. After a number of years in in the JavaScript webdev ecosystem, I have been planning to reviews what has been happening in Python since I was last active. This looks like a good place to start.
underdeserver
On a reasonably fast connection, I hit the increment button and it took almost two seconds for the counter to increment. Is it immediate for everyone?
arethuza
Seems instant to me and when I checked in the Firefox debugger the network calls are taking between 30ms to 50ms to respond.
Difwif
Same. I know this is unfair but it made me subconsciously write off the framework. OP, this is purely marketing feedback but try to make the button fast. Love the direction you're taking, good luck!
meiraleal
That's not really unfair. This trend about moving frontend things to be processed in the server is "coincidentally" what the big cloud providers need to keep hitting their quarterly goals.
oefrha
Totally depends on your latency to the server and server response time. Please don’t throw away two decades of client side advancements and do this for state changes that should be entirely local, people with higher latency will hate your guts. Use alpine or something like that if you don’t want to go full react/vue/svelte/solid/etc. It’s utterly terrifying that I now see this pattern evangelized every day.

As an aside, I hate websites/apps sending HTML fragments like it’s 2005 because it’s much harder to pull data or automate things that way. But that’s usually considered an upside for developers who want to combat scraping. In practice it’s hardly a road bump for devoted scrapers, and actually increases server load for the same amount of data pulled, but it’s still considered a win by many.

allknowingfrog
I've been following projects like Hotwire and HTMX for awhile now, and I haven't seen anyone argue that scraping is a major reason to adopt this approach. I also don't see a lot of opposition to the idea of incorporating something like alpine to add some UI niceness.

What you see as a "terrifying" disregard for "two decades of advancements", others see as a liberating departure from two decades of unnecessary bloat. It's healthy to have more than one strategy available for building web applications.

meiraleal
> others see as a liberating departure from two decades of unnecessary bloat

Is moving the bloat to a blackbox in the backend really a better approach? Why not just not create a bloated frontend?

p_l
Because it might be in fact easier and simpler to implement it on backend?
meiraleal
it might, it probably isn't. Unless you only have a hammer.
p_l
What is, and what isn't easier has a big honking "IT DEPENDS" attached.

And I have a strong suspicion for many the beloved hammer is big complex client-side JS framework.

allknowingfrog
Using htmx allows you to completely skip a layer of JSON serialization and parsing. It eliminates the complexity of maintaining a second, frontend application, as well as all of its build tools and dependencies. It even opens up the freedom to work exclusively in your preferred language. All of these are examples of removing elements, not just hiding them somewhere else.
pmarreck
I guess you're not a LiveView fan then?
recursivedoubts
the htmx/hypermedia approach doesn't perclude scripting for client-side interactions:

https://htmx.org/essays/hypermedia-friendly-scripting/

https://hypermedia.systems/client-side-scripting/

oefrha
It does not, and I was specifically talking about local state changes. I’ve seen it misused a fair bit, and these trivial examples that tend to be local in real applications don’t help guiding developers who are not keenly aware of the existence of poor connections.

Additionally, while not htmx, in the adjacent land of LiveView, client side scripting is a bitch. I built a complex application in LiveView two years ago and later regretted it. Hard to resolve client side state and server side state diverging with complex but local state changes, and complex local changes are made more difficult than good old imperative jQuery thanks to a managed DOM. It’s extremely tempting to render local state changes with an HTML patch from the server to avoid all the pain, but like I said, high latency users will hate my guts for it.

midairthief
For me it takes around 200~300ms and occasionally ~800ms, not too long but enough to make it noticeable and feel weird.
khasan222
This is to me a non starter. Why does the server care what that im incrementing the local data? None of that is likely important until I am done.

This is just one more layer on top, and one more possible point of failure/frustration, as illustrated by this parent comment.

p_l
Because you're incrementing server side data, not local.

Which doesn't matter for trivial counter examples but the same technique is something I've used (not with ludic, but with HTMX) to trigger actions in physical space.

itishappy
No. It's fast, but not immediate. It's annoying but not unusable.

Worse though, it starts dropping repeated clicks. Triple click increments counter by 2. Unfortunately, this is unusable.

p_l
It is honestly a bit too limited example. One way to handle it is for example to appropriately "lock" transaction on HTMX side, which is not done here.
aitchnyu
For those with constraints on framework choice, there is https://htpy.dev . IIRC the creator introduced it in HN.
craig
I love that someone is actively working on components in the python space. Coming back to python after years in the js ecosystem I've found templates really cumbersome to work with, especially not having type system support. I know there have been some attempts at JSX in python over the years but those projects all seem dead.

My advice to the OP, is to break out the component piece of the framework into a standalone lib that other frameworks can use. I think it'll be much easier to gain adoption that way.

giancarlostoro
One thing I want to see eventually is Blazor for Python maybe with Django. I am using Blazor at a new job and it is impressive. If I change a type on the backend not only will other classes that rely on it squak if theres mismatches, but my frontend joins in on squaking at me as well! Really nice in all honesty.

The best part is you can use components like you would with React but you write all / most of your logic in C# in the case of something similar for Python I would expect the logic to all be Python even if it affects the DOM.

As an aside thats on topic, I was contenplating HTMX and Django for a project I was working on but I am still overengineering in my head. I have landed on maybe using Astro instead for all the frontend logic.

neonsunset
Wouldn't that be...the worst of both worlds? Django and Python are really slow. Blazor is not a paragon of performance, and this will make it worse by an order of magnitude.
bsima
This looks fantastic! I love htmx, and I'ved used it with Lucid and Clay in Haskell to generate HTML apps entirely server side. I'd really like to use Ludic at some point as well.

The requirement of @override on the render method is a bit unwieldy, have you considered using pedantic's BaseModel instead of TypedDict? I think it would allow you to get rid of @override? Not sure it'd be worth it for the extra dep though.

Something I always look for in a web framework is the ability to run the app from the repl. Is this possible with Ludic? I remember in Clojure, the app was just a function of a hashmap request -> hashmap response, so testing was really easy, you just do something like (app my-request) and inspect the return value, 'my-request' can be a hashmap constructed by hand or generated with a tool like core.spec. Much more convenient than running uvicorn just for a quick test! I recommend adding this use case to Ludic if it's not already there.

[deleted]
(comment deleted)
jmull
I'm just never going to understand why you'd want to write your HTML in something unlike HTML (Python in this case). Then you need to know the thing that isn't like HTML, plus HTML, plus the details of how the other thing is transformed to HTML.

Of course, we often need something dynamic, so we can't just use HTML. But why not something a lot like HTML so those additional pieces are as small and simple as possible... you know... like a template engine.

bsima
Templating engines start out with just variable substitution, but inevitably you want to build logic into your HTML, so it adds if/else statements, then before you know it you are embedding your 'real' programming language into the HTML template itself. Think ERB templates with arbitrary ruby code inside them.

It's more robust to go the other way: start with the full-powered programming language, and emit the static HTML data after doing the complex logic stuff.

PurpleRamen
Because HTML is not a programming language, but you do have problems which demand a programming language, and this "something" is the programming language you know. HTML is just a mean to reach their goal. People are usually not writing json or xml by hand either.