Comment by kissgyorgy | Hacker News Reader

Comment by kissgyorgy | Hacker News Reader

Parent Full thread

Frameworks like this are really next-gen, but I wish people would think in terms of the bigger Python ecosystem and not just their own framework. This is about the fifth web framework which are not compatible with each other: Streamlit, ReactPy, FastHTML, Dash, Shiny, etc..

I created a truly reusable Python component framework which is just a a string generation library and can be used for ANY existing Python web framework and even more: HTML, XML, RSS, SVG generation, even robots.txt generation as a silly example. I use it with Django and HTMX but it doesn't have an opinion about anything how should you use it. If you pass a Component to Django HttpResponse instead of a string or template, it just works.

I guess I should just write some documentation and release it before the 6th one of these appears :) so we ALL can collaborate with the same API on a bunch of Component sets like Twitter Bootstrap or Material components!

https://github.com/kissgyorgy/compone

This sounds exactly like what I was looking for. I settled on htbuilder[1], but it certainly does not feel right as it requires a fair bit of wrangling in order to fit with Django.

I'd love to help you with documentation and such; hit me up at smart.tent1246@fastmail.com if you'd like a partner(:

[1] https://github.com/tvst/htbuilder

EDIT: Actually, scrolling further in this thread, it looks like https://htpy.dev fits the bill? It has explicit integration with Django, which is what I was looking for.

Looking over your examples makes me think of sxml

https://en.wikipedia.org/wiki/SXML

That looks super interesting, congratulations. I would suggest you do write lots of documentation, a more elaborate readme on github and generally push your approach. As it stands, the repo looks somewhat unfinished and inactive, unlikely to make people spend their time and energy digging into it. I hope you drive it forward!

You are totally right, but I'm not actively working on it, because core (the base library) is basically ready and I'm working on a project in production which is exclusively using it [1]. The site is using htmx, feels snappy overall and I'm even generating static parts with it (e.g. the home page).

[1]: https://findendurancecoach.com/

> Frameworks like this are really next-gen,

How is this next-gen? It looks exactly like all current frameworks in various languages, but with more default functionality thrown in.

Something like Postgrest would, to me, be "next-gen".

I have a private/proprietary backend-based framework that I used for a few clients that has both less "magic" while simultaneously allowing more functionality with even less code than any of the examples in any current framework, including this one.

I find it hard to get impressed these days.

Next gen in Python land. Nobody implemented a component framework properly yet.

Most Python web apps implement WSGI, and so can absolutely be used together. Just mount them on top of each other. Wanna use both Flask 'n Django? Go for it! Unfortunately, that's the backend story.

On the frontend, things are a little less consistent.

This is fantastic and exactly what I wanted! A very neat idea about how you separate attributes and children.

How does the performance side of this thing look like?

I did not measure performance yet, but I definitely will! My hunch is that it's faster than any templating library, because those are compiling from their own DSL, but it's completely ommitted here.

Another Python framework agnostic project is ReactPy. [0]

[0]: https://github.com/reactive-python/reactpy

Thank you for saying this. Having to dabble with streamlit at work, I am very disappointed in those kind of solutions, where the moment you venture off the happy path, you are on your own. Any kind of integration or extension needs you to be aware of streamlit's internals. For example, there is no built-in way to open a folder picker AFAIK.

Streamlit is fine for the first 20 minutes and then it sucks. I switched to NiceGUI and couldn't have been happier for my internal crud app with very specific ui/interactivity requirements.

That's why I like django-ninja: it's django with fastapi like features.

But it's fully django compact.

At the risk of being ignorant/heretical: Why use this over "raw" templating (e.g. jinja2) at this point?

I’ve switched back to writing server-based code from writing React SPA. Text-based templates (I use jinja2) is my least favorite part of that.

It’s modeled after Django templates circa 2005, and that was designed with an idea that designers will write those templates, that they are not code.

I’m doing all this for 18 years, it was always programmers who wrote template code.

Why then we have such things as filters, in addition to functions? Untyped macros. Formatting template code is a struggle. Include tags are the worst.

The only thing I fear with regard to all these component libraries is performance. I actually wrote a PoC myself for such a library, but didn’t bring it to production quality.

My suggestion is to just try writing React for a week or two and experience the component based development. You never want to go back to templates again.

I've been writing react for years, and going back to templates, I wish I could never have to write a react rendering function again.

Components are overrated.

Their best feature is that they help build a fantastic ecosystem, which is the biggest react strength.

But for your own website?

Their cons and pros balance each other out, and all that is left is the terrible API that react exposes.

Eventually, you gain locally some reusability (provided you actually need it in your project, because there are not that many components that need reusability, and even less that couldn't be a template tag in django), but every single dev writes react code differently.

So you get a heterogeneous mess anyway.

My last SPA project (in vue), we had one component that was worth making reusable.

One. For a month and a half of work.

Turns out vanilla functions are quite reusable themselves already.

I love the idea of components. (been doing variations of it since 1999, starting with custom tags in ColdFusion) What I don't love is giving over to "full stack" development to gain the advantage of components (fortunately, there's options like server-side components, even when not using a JS-based framework, as well as partial-stack options like Inertia JS)

But I cant use this instead of jinja?

yes you can

Thank you. Death to jinja!

Reply on news.ycombinator.com