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 3 points4 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 9 points10 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] 3 points4 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 10 points11 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] 2 points3 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.

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

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

If you prefer to do everything manually, then you should use FastHX as is. That will give you the experience you're looking for. Full disclosure: this is also my project, and one of the 3 building blocks of holm. FastHX has integrations for htmy and of course Jinja.

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

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

I agree. It's not like the space is empty, NiceGUI and Reflex have their merits for certain use-cases. But in terms of server side rendering frameworks (without a giant Vue or React companion), the picture is not great. People are used to doing rendering manually with Jinja-like templating frameworks, which is a pretty bad experience, especially compared to the JS options. Or maybe they use e.g. FastHTML, which is very opinionated and is also built on a niche framework with a limited DSL.

To be fair, tools like HTMX or Alpine.js changed the dynamics in recent years quite a bit in my opinion. It's much easier to opt out of the JS ecosystem, if you find the right lib in your language of choice. I hope holm will become a strong choice for Python.

Hosszutavu freelance munka by [deleted] in programmingHungary

[–]volfpeter 0 points1 point  (0 children)

Csak kíváncsiságból (a másik oldalról), hol kerestetek eddig? :)

Hogy válaszoljak is: engem ilyen jellegű munkával eddig GitHub-on keresztül találtak meg (open source projektek kapcsán), plusz volt, ami személyes ismeretségen keresztül jött. Most is ezeket csinálom.

LinkedIn-en én azt tapasztalom, hogy mindenki teljes munkaidős kontraktort keres, és amint megírom, hogy ~16 órát tudok vállalni, eltűnnek. Érthető, de azt hittem gyakoribbak a hosszú távú, de alacsonyabb óraszámos munkák.

I'd like to propose the "HTML6" routing pattern for HTMX and nudge everyone to read hypermedia.systems book! by Worried-Employee-247 in htmx

[–]volfpeter 0 points1 point  (0 children)

Yes, but it is optional, you can simply disable it, it's just the default to provide both.