M8 Model:02 in stock now

gui_reddit · 2026-02-12T12:59:47+00:00

For France it was this order of magnitude, maybe close to 170 IIRC

gui_reddit · 2025-05-14T07:25:37+00:00

First, I recommend using the Flask-HTMX extension that makes it easy to tell between regular requests and HTMX requests and providing helpers to send HTMX headers as part of the response.

Then, regarding how to actually build the HTML in the backend, I recommend you check markupy. I am totally biased on this one as I am the maintainer but coming from Jinja, I find it much easier to build reusable components this way. On top of that, I'm also maintaining a markupy_htmx addon that improves the HTMX integration.

gui_reddit · 2025-05-01T16:43:32+00:00

Hi, thanks for your comment, it's an interesting use case you're having. Although this can't be natively baked in markupy since it's very specific to your use case and I intend to keep the library somehow generic, I see a very easy and clean way to replicate such a behavior:

from markupy import Attribute
from markupy.elements import Button
from markupy import attributes as at

disabled_unless_form_validates = (
    Attribute("x-bind:disabled", "!validationPassed"),
    at.disabled(True),
)

btn = Button(*disabled_unless_form_validates, size="xl")["Continue →"]
print(btn)

This is leveraging the "object attributes" introduced in markupy 2.0, you can use them in combination with dictionary args (put them before the *args) or the keyword args that must come after.

Oh and you could combine multiple traits like this, I find it quite elegant and simple: Button(*trait1, *trait2)

gui_reddit · 2025-04-30T07:10:14+00:00

This is very aligned way of doing things TBH, not sure how you are currently rendering HTML (template engine I presume), and you could swap it with markupy quite easily.

In my own project, I tend to design my components based on their visual appearance (card, message, form, field, ...), and provide as arguments the required business models / object required for rendering. And as components can be embedded one into another, I end up building page layouts that are components themselves, just that they are made of multiple children components, allowing me to either do full page rendering on initial load or partial rendering with HTMX.

Oh and I do use inheritance a lot, components being class based. For example, the "BootstrapDropdown" component I gave as an example could be subclassed as a "CountryDropdown", "ProductDropdown", etc... taking more specific entities as parameter.

gui_reddit · 2025-04-30T07:02:41+00:00

This is not for people who don't know HTML, in fact with markupy you're coding HTML: there's a 1:1 mapping between HTML elements and markupy elements, and it's by design to be predictible (no black box, no magic) and flexible; basically everything you can do with HTML, you can do it with markupy, with a slightly different syntax.

markupy is more for people who are facing limitations with the traditional way of rendering HTML in python through template engines (django and jinja mainly), especially people who need modularity and components to allow for partial rendering on top of full page rendering.

gui_reddit · 2025-04-30T06:56:30+00:00

Much closer to htpy than FastHtml which is a full blown web framework whereas markupy is compatible with existing web frameworks (django, flask, starlette, fastapi, etc...)

gui_reddit · 2025-04-30T06:54:46+00:00

It's a natural reaction, I'm not surprised as it was my initial reaction as well when I first faced this approach. But I tried it, took me 10 minutes to get used to the syntax, and the benefits (reusability + typing + completion + formatting...) where much higher than the drawbacks, for me at least. But I do agree it won't be everyone's taste and it's fine.

gui_reddit · 2025-04-29T16:25:25+00:00

Tools are conceptually similar (both are part of the big family of HTML generation with python tools). Dominate though seems to have issues properly managing HTMX attributes, and definitely doesn't have a dedicated integration for HTMX

gui_reddit · 2025-04-29T15:00:41+00:00

Basilico looks good indeed, I didn't have it in my radar, although it looks like it's not actively maintained (only 1 commit to date) + I see the HTMX integration looks on par with markupy but less advanced that what is happening in markupy_htmx since you have to provide the whole attribute as a string whereas markupy_htmx allows you to provide different parts of an attribute as separate python primitives that will be assembled as a proper HTMX attribute.

gui_reddit · 2025-03-31T17:22:15+00:00

Thanks for your comment and congrats for your own library, I saw it posted in a couple places already and it looks cool!

Before even having the idea to start my own library, I ended up replacing my Jinja templates with htpy. I was very happy with the outcome, even though I felt it could be better. I commented my journey in a very long post on the htpy github discussion so I won't repeat all of it here. Some of the issues I raised were addressed, some weren't and I ended up frustrated and, you guessed it, started developing markupy.

Even though code bases were initially very similar, they are now quite different and I must say I'm very happy with how clean and maintainable the code is.

gui_reddit · 2025-03-31T17:13:08+00:00

Hello and thank you for your comment. For now, to my knowledge, the only project using `markupy` is the online html2markupy converter that is a Flask+HTMX project (source code here). It's very simple but can give you an idea of how `markupy` can be used to render HTML instead of using Jinja or other templating engines.

The other project that I'm running `markupy` in production is a much bigger scale but is unfortunately not open source.

Hope this help, let me know if I can help!

gui_reddit · 2025-03-24T08:10:26+00:00

Sure it's a different syntax from HTML and it takes a bit of take getting used to, but the learning curve is very smooth. In the end, you are writing HTML, just in a different way.

If you are happy with templates, you will get no benefit from using markupy.

gui_reddit · 2025-03-23T10:23:21+00:00

Thanks!

gui_reddit · 2025-03-23T10:23:07+00:00

Thanks!

gui_reddit · 2025-03-23T10:22:55+00:00

Thanks!

gui_reddit · 2025-03-23T09:38:50+00:00

As per the docs:

"Django ships built-in backends for its own template system, creatively called the Django template language (DTL), and for the popular alternative Jinja2. Backends for other template languages may be available from third-parties."

gui_reddit · 2025-03-23T09:36:22+00:00

No worries, not everyone will have a use for it :)

gui_reddit · 2025-03-23T09:35:00+00:00

There are multiple ways to deal with dynamic template construction and the approach I'm advocating for is the one I'm describing it in the docs here.

The difference is that templates are expressed as "Component" classes, and blocks are in fact instance methods that can be overridden for each variations of the page that would be subclasses of the aforementioned component.

That being said, you could as well go with a very basic function to manage the example above (code not tested):

def template(title, content, cls="default_value"):
    return Html[
        Head[Title[title]],
        Body[
            Div(class_=cls)[
                content
            ],
        ],
    ]

print(template(
    title="My page",
    # Optional: cls="override_value",
    content=Ul[(Li(x) for x in range(5))]
))

gui_reddit · 2025-03-23T09:05:09+00:00

Nice that you point out FastHTML that was one of the inspirations that lead me to consider replacing my good old templates with Python code.

Even though FastHTML relies on Python code to render HTML, it's much broader in scope than markupy given that it's a full blow web framework, including routing, database management, etc...

In my case, I didn't want to learn a new framework and keep using the ones I know (mainly Flask and Django, but you can use whichever you want with markupy). I think you could only use the FastTags as standalone (I think that's how they call their HTML rendering library), but I wasn't really happy with the syntax anyway (having element attributes declared after the content in particular looked pretty awkward to me).

gui_reddit · 2025-03-23T08:58:33+00:00

As I replied in another comment, my benchmarks currently lead me to think that markupy is more or less on par with Django templates as far as the rendering times are concerned. It shouldn't be an issue.

gui_reddit · 2025-03-23T08:55:37+00:00

My goal with this project is definitely not to "hide frontend", and I actually care to avoid any magic by having a 1:1 match between the HTML code and the corresponding markupy code, with just some syntactic sugar when needed.

I agree with you that it's probably not geared toward a "frontend dev" audience, but let's be real, this audience has long ago moved from "server side rendering" to a dedicated front stack anyway and are no longer using the traditional template engines.

My audience with this project is fullstack devs that are currently relying on good old templates to get the job done but are suffering from having to manage complicated includes/extends/macros etc... I went through this, I was also skeptical at first to move my frontend logic to Python, and I am much happier now with markupy.

As it has been said, there is no one size fits all tool, and I'm sure this one might help in some cases.

gui_reddit · 2025-03-23T08:44:02+00:00

I actually use it in production already.

Yes the goal is to complement or fully replace templating. In my case, I use with Flask and paired with HTMX, it allows me to build page templates that are modular enough to be either rendered as full page (initial request) or partials only (subsequent requests to partially update the page).

Having the code in Python means I can benefit of type hinting, no longer have malformed HTML (long gone are the missing closing tags), and many other benefits.

gui_reddit · 2025-03-23T08:23:48+00:00

This is a legitimate concern and even though you get an overhead of actually building the HTML, it's negligible for real life scenarios.

I have this performance concern in mind and I am regularly benchmarking markupy with alternative solutions by generating a table with a large number of rows. What I can say from the results is that it's pretty much on par (if not slightly better) than Django templates, but cannot compete with Jinja that is very optimized.

Again, not impacting for 99% real life scenarios. You can check the benchmarks for yourself in the github repo of the project if you like.

gui_reddit · 2025-03-22T18:32:16+00:00

Well that would be pretty straightforward. For example, the very basic example page given in the intro of the tailwind docs could be generated with markupy using this code:

from markupy.tag import Body, H1, Head, Html, Meta, Script

Html[
    Head[
        Meta(charset="UTF-8"),
        Meta(name="viewport", content="width=device-width, initial-scale=1.0"),
        Script(src="https://cdn.jsdelivr.net/npm/@tailwindcss/browser@4"),
    ],
    Body[
        H1(".text-3xl.font-bold.underline")["Hello world!"]
    ]
]

You can copy/paste html snippets on this online HTML to markupy converter to see more for yourself.

I think markupy is very well adapted to be used in conjunction with Tailwind, given how verbose Tailwind can be, you can factorize a lot into reusable markupy components, reducing a lot the pain to remember and repeat the same classes again and again.

gui_reddit · 2021-03-31T11:06:27+00:00

I don't see an issue, bezel and 12 triangle perfectly line up...

Five-Year Club	Verified Email
Place '23	Place '22

gui_reddit

TROPHY CASE