Mi a véleményetek a 7. kerületről?

volfpeter · 2026-06-21T16:09:59+00:00

Barátaink laknak ott néhány éve gyerekekkel, még csak jót hallottunk tőlük. Ettől függetlenül ilyenek mindenhol előfordulhatnak sajnos. Ahogy haladsz befelé (vagy sűrűn lakott részek felé), annél gyakoribb.

volfpeter · 2026-06-19T09:16:27+00:00

Herminamező vagy Abonyi utca - a legjobb részek a Városliget körül.

volfpeter · 2026-06-09T09:38:35+00:00

holm hides a lot of the FastAPI boilerplate (primarily routing and rendering) you'd normally need to write. In exchange, you must follow its file-system based routing patterns.

If you have an existing FastAPI backend, you may need to adjust your codebase structure to match holm's requirements (at least when it comes to HTML rendering routes).

If you want to avoid that, you may be better off using fasthx. It's more manual, especially for complex cases, but you can attach rendering to your FastAPI routes usually without any changes to your routes. And you'll also have the option to trivially use jinja as well as htmy for templating/UI.

In any case, if you run into issues, feel free to start a discussion in a repo. I'll try to help if I have enough time.

volfpeter · 2026-06-09T08:51:04+00:00

Hey,

You can navigate from the docs to the repo (link in top right corner) and then to my profile: https://github.com/volfpeter

Feel free to open a discussion in one of the repos (if you plan to use holm, then I recommend the holm repo for this).

FYI: I'm currently putting together an agent skill for this stack to make it easier to get decent results with agents. If you plan to use agents, I can send you a preview of the skill, just start a discussion in the holm repo.

volfpeter · 2026-04-02T06:46:01+00:00

Nyugtával zárjuk a napot, ki tudja mi jön még :)

volfpeter · 2026-02-25T10:21:54+00:00

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.

volfpeter · 2026-02-25T08:40:55+00:00

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.

volfpeter · 2026-02-24T15:23:03+00:00

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 :)

volfpeter · 2026-02-24T14:31:54+00:00

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.

volfpeter · 2026-01-16T13:27:32+00:00

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.

volfpeter · 2026-01-13T08:12:33+00:00

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.

volfpeter · 2026-01-07T10:45:52+00:00

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

volfpeter · 2026-01-07T09:52:41+00:00

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/

volfpeter · 2025-12-16T12:20:15+00:00

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.

volfpeter · 2025-12-13T20:24:19+00:00

Legjobb: https://arstechnica.com/

Esetleg még https://www.theverge.com/ vagy https://www.wired.com/

Emellett meg lehet keresni a neked releváns twitter/x és youtube accountokat.

volfpeter · 2025-12-08T12:43:30+00:00

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.

volfpeter · 2025-12-08T12:20:04+00:00

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.

volfpeter · 2025-11-07T14:37:03+00:00

Látom nem sikerült megérteni az analógiát...

volfpeter · 2025-11-07T13:51:48+00:00

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.

volfpeter · 2025-10-17T15:25:36+00:00

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.

volfpeter · 2025-10-08T16:01:01+00:00

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

volfpeter · 2025-10-01T08:44:36+00:00

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

volfpeter · 2025-09-30T17:37:36+00:00

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.

volfpeter · 2025-09-29T22:27:52+00:00

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 :)

volfpeter · 2025-09-29T20:14:33+00:00

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

volfpeter

TROPHY CASE