41 ms·

Show HN: Web Development with Htmx, Type-Guided Components, Pure Python

107 points by paveldedik 2y ago

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/ 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 https://getludic.dev/catalog/layouts Additionally, I've developed a convenient cookiecutter template: * https://github.com/paveldedik/ludic-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

pbronez 2y ago
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 2y ago
  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 2y ago
    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 2y ago
      Thank you very much, really good advice here.
- deleted 2y ago
  [deleted]
leejoramo 2y ago
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 2y ago
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?
- Akronymus 2y ago
  It's instant for me.
- arethuza 2y ago
  Seems instant to me and when I checked in the Firefox debugger the network calls are taking between 30ms to 50ms to respond.
- Difwif 2y ago
  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 2y ago
    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 2y ago
  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.
aitchnyu 2y ago
For those with constraints on framework choice, there is https://htpy.dev https://htpy.dev . IIRC the creator introduced it in HN.
craig 2y ago
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 2y ago
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 2y ago
  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 2y ago
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.
ple13 2y ago
This looks promising. How do you compare with https://github.com/pydantic/FastUI https://github.com/pydantic/FastUI (made by the authors of Pydantic)?
- ofrzeta 2y ago
  There is a comparison table in the Github docs: https://getludic.dev/docs/ https://getludic.dev/docs/
deleted 2y ago
[deleted]
jmull 2y ago
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 2y ago
  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 2y ago
  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.

107 points by paveldedik 2y ago

pbronez 2y ago

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 2y ago
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 2y ago
  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 2y ago
    Thank you very much, really good advice here.
deleted 2y ago
[deleted]

leejoramo 2y ago

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 2y ago

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?

Akronymus 2y ago
It's instant for me.
arethuza 2y ago
Seems instant to me and when I checked in the Firefox debugger the network calls are taking between 30ms to 50ms to respond.
Difwif 2y ago
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 2y ago
  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 2y ago
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.

aitchnyu 2y ago

For those with constraints on framework choice, there is https://htpy.dev https://htpy.dev . IIRC the creator introduced it in HN.

craig 2y ago

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 2y ago

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 2y ago
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 2y ago

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.

ple13 2y ago

This looks promising. How do you compare with https://github.com/pydantic/FastUI https://github.com/pydantic/FastUI (made by the authors of Pydantic)?

ofrzeta 2y ago
There is a comparison table in the Github docs: https://getludic.dev/docs/ https://getludic.dev/docs/

deleted 2y ago

[deleted]

jmull 2y ago

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 2y ago
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 2y ago
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.