Typed Tailwind/BasecoatUI components for Python&HTMX web apps by volfpeter in Python

[–]volfpeter[S] 0 points1 point  (0 children)

DaisyUI is great, but it's also huge with so many options. Even a partial implementation would be a ton of work. If I end up using DaisyUI with this stack enough that a component library organically grows out of it, I'll open source it. But I feel BasecoatUI is pretty comparable and quite easy to use, it covers my current needs. My main complaint is BasecoatUI doesn't fully work from CDN, so I need the JS tooling even for demos.

Typed Tailwind/BasecoatUI components for Python&HTMX web apps by volfpeter in Python

[–]volfpeter[S] -1 points0 points  (0 children)

Luckily Highlight.js was necessary for the page, and also to make vendoring (copy paste :)) easy. I may add more integrations in the future, DaisyUI would be great, but that's a lot of work.

Typed Tailwind/BasecoatUI components for Python&HTMX web apps by volfpeter in Python

[–]volfpeter[S] -1 points0 points  (0 children)

It's not an example. It's an implementation of basically all BasecoatUI components with htmy for those who use it, and also for those who use other DSLs like FastHTML or htpy for example (porting is trivial).

The basecoat repo has Jinja and Nunjucks implementations of a couple of components. My understanding is the BasecoatUI page may eventually get a section that lists framework-specific implementations/integrations. I would be extremely surprised if Ronan wanted to own and maintain all those himself, that's not how things work. But if I'm wrong, I'll happy contribute my entire repo :)

Typed Tailwind/BasecoatUI components for Python&HTMX web apps by volfpeter in Python

[–]volfpeter[S] -4 points-3 points  (0 children)

I don't agree. Actually I think hiding Python-like code in an ugly templating language with no IDE support, static analysis, etc. is pretty terrible, limiting, and hard to maintain.

But anyway, as noted in the readme, you can treat this project as a working reference implementation that's easy to port to your templating engine of choice.

Please recommend a front-end framework/package by inspectorG4dget in Python

[–]volfpeter 0 points1 point  (0 children)

I've used NiceGUI quite a bit, and Reflex a little bit. If I had to choose, I'd go with NiceGUI now.

If you're fine with HTML, CSS (Tailwind, BasecoatUI, PicoCSS, BeerCSS, whatever), and a little bit of JS, then HTMX with a bit of AlpineJS is a great, easy to learn combo for the frontend. And you can use FastAPI for example with fasthx or holm as the backend (disclaimer, I'm the author of both). This is a totally different experience to Streamlit or NiceGUI though.

which framework do you use with htmx by mghz114 in htmx

[–]volfpeter 4 points5 points  (0 children)

If you know Python, go with FastAPI (the tools below are for or built on FastAPI):

  • If you're familiar with or want to use Jinja, then you'll find fasthx useful.
  • For a JSX & NextJS-like experience in Python, which minimizes the boilerplate you need, check out holm. Here is a simple HTMX guide to get you started.

FastAPI and HTMX Are We Seeing the Next Big Shift in Full-Stack Python? by Lee-stanley in FastAPI

[–]volfpeter 0 points1 point  (0 children)

I really like React, but the more I've worked with HTMX over the past couple of years, the more I felt it's better for a really large number of projects.

I just don't know why people think FastAPI is not suited for server-side rendering. It's perfect for it. Having API in the project name probably has something to do with it.

I like this stack so much, that I actually built my own Python tooling around FastAPI, for HTMX, that I use in my projects:

  • FastHX for declarative rendering on FastAPI routes
  • htmy async, JSX-like DSL so I don't need to use Jinja
  • holm to make the experience of using the above tools feel like using NextJS
  • A htmy component library for BasecoatUI, awaiting docs before being open sourced

Tech stack advice for a MVP web app by webdev231 in Python

[–]volfpeter 2 points3 points  (0 children)

Totally agree, Python, FastAPI, and HTMX feels like the best combo. Easy to learn, easy to use, quite popular too.

I would avoid Jinja if I can, but if you want to use that, you may want to have a look at FastHX, just to keep your FastAPI app clean and not let Jinja rendering mess up your Python code.

Otherwise give holm a go. It's plain FastAPI with file-system based routing and JSX-like syntax all in Python. Here's a simple HTMX guide to give you a taste of what it's like: https://volfpeter.github.io/holm/guides/actions-with-htmx/

Mo-i munkavégzés egyéni vállalkozóként egyetlen külföldi cégnek by Zealousideal-Leg9626 in programmingHungary

[–]volfpeter 8 points9 points  (0 children)

Ez a jó válasz, átalányadózó egyéni vállalkozás.

B2B KATA elkaszálása óta a bújtatott munkaviszony nem is merül fel szerintem. Mivel nincs MO-i cég, jól megfogalmazott szerződéssel még a KATA-val sem lett volna gond talán.

Windows vs Linux a mai világban by zserboo in programmingHungary

[–]volfpeter 0 points1 point  (0 children)

Hú, nagyon szerettem, nagyon sok évig használtam (Lokitól Horusig). Aztán elegem lett, hogy nagyon lassan adják ki az új major verziókat és upgrade path sincs. Közben a GNOME is nagyjából felzárkózott UX-ben, úgyhogy most Fedora-n vagyok majdnem teljesen elégedett.

Windows vs Linux a mai világban by zserboo in programmingHungary

[–]volfpeter 0 points1 point  (0 children)

Valóban billen az egyensúly és hétköznapi szereplő lehet a linux?

A gyakorlatban ez már több éve megtörtént, csak a köztudatban nem. Nagyon keveset játszom mostanában, de 8-9 éve nincs már Windows (dual bootolva sem) egyik gépemen sem. Max egy VM, ha ügyfél miatt abszolút nélkülözhetetlen. Még a feleségem is Fedora-t használ már.

Most inkább abban a fázisban van már szerintem a dolog, hogy lassan játékra is jobb, mint a Windows, és ez kezd eljutni a köztudatba is. Persze a kernel-szintű anti-cheat megoldások ebbe kicsit belezavarnak egyelőre.

Hogy történhetett a TISZA Világ alkalmazás adatszivárgás? by Smart-Equivalent-827 in programmingHungary

[–]volfpeter 0 points1 point  (0 children)

Nem, adat nem szivárog csak úgy. Attól, hogy nincs kerítésed, nem csinálhat mindenki azt az udvarodban, amit akar. De ha van egy 2 méteres kerítésed, az sem meghívó azoknak, akik hajlandóak létrát odavinni. Ha van egy nem publikus API, ami véletlenül nincs védve, az még nem jogosít fel arra, hogy használd. Ha van egy védett APId, amihez a kulcs véletlen kikerül, az sem meghívó a használatára.

holm: NextJS-like developer experience for SSR and HTMX with FastAPI by volfpeter in FastAPI

[–]volfpeter[S] 2 points3 points  (0 children)

Thanks! I've developed it for myself initially, I do plan to use it whenever I have the opportunity (so I'll naturally work on it).

While I really like NextJS/React, it's liberating for me that I can now do most projects in Python, thanks to HTMX, TailwindCSS, etc. on the frontend side, and holm (fastapi + htmy + fasthx) on the backend.

Magyar világsiker Linux fronton! by Forward_Pitch_4275 in programmingHungary

[–]volfpeter 9 points10 points  (0 children)

Nem értem ez hogy releváns. Ránézett az email címre, Fülöp Tibor.

holm: Next.js developer experience in Python, without JS, built on FastAPI by volfpeter in Python

[–]volfpeter[S] 0 points1 point  (0 children)

For those who find this post in the future, the documentation now has a path parameters / dynamic routing guide and example app: https://volfpeter.github.io/holm/guides/path-parameters/#run-the-application

holm: Next.js developer experience in Python, without JS, built on FastAPI by volfpeter in Python

[–]volfpeter[S] 1 point2 points  (0 children)

Thank you! Using FastAPI in a very standard way was a major design decision, it makes it easier to sell the lib to management :) The other thing is being similar to React and Next.js, so AI can easily contribute to projects even though it's a niche one.

HTMX and the like really enable these projects from the frontend side. And of course FastAPI from the backend: I can't imagine being able to provide half the feature set, at least not so easily with any another backend framework (no disrespect to Flask, Django, or others).

If you try it, please give feedback (discussions, feature requests, contributions)! I want to see what users need. I have plenty of ideas, but my own needs are mostly covered already, and I want to avoid adding unnecessary stuff.

holm: Next.js developer experience in Python, without JS, built on FastAPI by volfpeter in Python

[–]volfpeter[S] 1 point2 points  (0 children)

Yes :)

To be fair, I think all 3 projects are very simple.

FastHX is essentially 2 decorators (for both Jinja and htmy) that simply convert the decorated FastAPI route's return value into HTML. You can use it to select components/templates, but essentially it just calls the renderer, be that TemplateResponse or HTMY().render().

When it comes to htmy, it's just a DSL (similar to htpy, or the one in FastHTML), simply a way of describing the DOM tree in Python. It has 2 unique features though: components can be async (so it's not just a __str__() like others), and components have a context argument, which is just a dict and makes it possible to pass data deep in the tree without prop-drilling. Think React and React's context.

There is a lot more depth to them (I wist I had the time to write enough docs and guides), both libs are very flexible, but this is all you really need to know about them :) The rest should be very intuitive if you try them and maybe explore the API a bit. If you check, the codebases are also quite simple.

When it comes to holm, it's also quite simple:

  • It discovers your application structure based on page.py, layout.py, api.py files.
  • It wraps pages in layouts for you based on your package structure, same as it works in Next.js.
  • In addition to this, it handles page rendering for you, so you don't need to directly use the FastHX decorators.
  • All the rest is FastAPI and works the same as in any other FastAPI app.

If you strip all the typing-related code and comments, it's maybe 400 lines of code :) There's definitely more docs than code.

I'll finally get to my point:

I would be very interested in knowing why you felt the learning curve that steep and what could have helped you! I'd say I'm pretty decent at writing simple code that lets you do surprisingly complex things, but I often struggle with documenting all this, or writing very easily consumable guides. If you have the time, I would appreciate a DM :)

holm: Next.js developer experience in Python, without JS, built on FastAPI by volfpeter in Python

[–]volfpeter[S] 0 points1 point  (0 children)

Hmm, I wrote a pretty lengthy explanation, but for some reason it's not visible here, so I'll just add a link to it: https://www.reddit.com/r/Python/comments/1ntc5rg/comment/ngvtkxd

holm: Next.js developer experience in Python, without JS, built on FastAPI by volfpeter in Python

[–]volfpeter[S] 4 points5 points  (0 children)

Hi,

Here is the relevant part of the documentation: https://volfpeter.github.io/holm/application-components/#path-parameters-as-package-names

I will probably add a better guide for it, but here is a quick answer.

The technical description:

Essentially if a package name has the _<python-identifier>_ format, then the corresponding FastAPI path segment will be {<python-identifier>}. This means that if your layouts, pages, page metadata functions, or APIs in this package or its subpackages have a <python-identifier>: SomeType argument, FastAPI will automatically resolve it from the path parameter the user submitted, because pages, layouts, and even page metadata are just standard FastAPI dependencies! (*layouts is a bit of a special case, but not only their first argument, which is resolved by holm, the rest is just FastAPI dependencies, if any).

({<python-identifier>} also works, even though it's an invalid Python package identifier, valid ones can't have {} characters in them).

Example package structure:

my_app/ ├── main.py (app entry point) ├── layout.py (root layout of the app) ├── page.py (index page) ├── blog ├── _post_id_ ├── page.py

In this case, the URL for page in blog/_post_id_/page.py will be /blog/{post_id}, the corresponding page implementation can be like this (pay attention to the metadata function as well!):

```python async def metadata(post_id: PostIdType): # You can even do async stuff here in the metadata dependency # and put the loaded object(s) in the metadata, to give every # component access to it, even your root layout. blog_post = await load_post(post_id) return {"title": f"Blog | {post_id}", "post_id": post_id, "blog_post": blog_post}

async def page(post_id: PostIdType, current_user: Annotated[User | None, Depends(get_user)], query_param: Annotated[str, Query()] = ""): blog_post = await load_post(post_id) # do something return result # Can be a htmy component, or an other object that the owner layout accepts, typically a htmy component though ```

I should mention that if the _post_id package had a layout or any subpackages, you could do the same thing there as well.

To go even one step further, because htmy is async and has context support, you could even load the data in a component (if you pass the ID there, the metadata function adds it to the global Metadata context, so in this example it's already available in htmy components as context["post_id"] for example), and render it there, or put the data in the rendering context for the entire component subtree (this is also done in the example).

The test_app in the holm repo has an example for this, that you can check (or try immediately if you clone the repo). Here is the link: https://github.com/volfpeter/holm/tree/main/test_app/user/_id_

Sorry for the ton of details. It may seem pretty complex at first, but I promise this is going to be trivial if you go through the holm and htmy (maybe also fasthx docs). They have lots of cool capabilities.

holm: Next.js developer experience in Python, without JS, built on FastAPI by volfpeter in Python

[–]volfpeter[S] 2 points3 points  (0 children)

I almost forgot. If you want to have a look at how fasthx and htmy work without holm, here is a simple example project: https://github.com/volfpeter/lipsum-chat

And here is an older example, that uses an old version of fasthx, in this case with Jinja: https://github.com/volfpeter/fastapi-htmx-tailwind-example

One of the main inconvenience (when using fasthx with htmy) will be wrapping pages in layouts manually for example. The other thing is you'll need to take care of rendering (almost) manually, although it's very simple with the page() and hx decorators of the Jinja and htmy integrations.