I would go as far as to say your work is the sole reason we are growing like this! Django-components is simply that much more usable with all your additions. Yay!

Fully agree with docs improvements might be the best next step.

Tracking: unfoldadmin/django-unfold#881

Another thought on the long-term, @EmilStenstrom I'd like to hear what you think.

TL;DR: this could be us 😤

So I saw this news that the team who built Pydantic is building an adjacent commercial product (Logfire). IMO, what's currently django-components (DJC) could in 1-2 years (at current rate of ~30-40 hr/wk) become what Pydantic is today for the Python community. I'm taking purely in technical terms, that this project could become one of the fastest, most reliable, and most comprehensive ways to build UI in Python. Given my excessively high standards in this regard and the audacity to go great lengths to meet them (like with the parsers I've moved to Rust), I think it's achieveable 😄

Vue-like alternative to FastUI, Streamlit, etc..

I have only a light idea what the landscape for Python UI frameworks looks like outside of Django. Tho I just saw that the Pydantic group also has FastUI. And if I look at projects like FastUI, FastHTML or Streamlit, they seem to be built around React-like paradigms. So I think there's still a space for a similar project that would reflect Vue-like paradigm.

By "Vue-like paradigm" I'm thinking WYSIWYG. In other words, the user defines the underlying specs (HTML, CSS, JS) directly, instead of having to define HTML / CSS / JS through intermediate abstractions.

• In Vue, the HTML or CSS that you write looks already very close to how it will look in the browser. And any in-template Vue-specific features are implemented as HTML-compliant (e.g. rendering components as HTML tags like <MyComponent>, or using conditionals and loops are HTML attributes v-if and v-for).
• To contrast, in FastUI, you have to define the template as Python objects. Maybe I'm just built different, but I find this example from FastUI to be harder to interpret:

    return [
        c.Page(  # Page provides a basic container for components
            components=[
                c.Heading(text='Users', level=2),  # renders `<h2>Users</h2>`
                c.Table(
                    data=users,
                    # define two columns for the table
                    columns=[
                        # the first is the users, name rendered as a link to their profile
                        DisplayLookup(field='name', on_click=GoToEvent(url='/user/{id}/')),
                        # the second is the date of birth, rendered as a date
                        DisplayLookup(field='dob', mode=DisplayMode.date),
                    ],
                ),
            ]
        ),
    ]

  than this example from Vue:

    <template>
      <button @click="show = !show">Toggle List</button>
      <button @click="list.push(list.length + 1)">Push Number</button>
      <button @click="list.pop()">Pop Number</button>
      <button @click="list.reverse()">Reverse List</button>
  
      <ul v-if="show && list.length">
        <li v-for="item of list">{{ item }}</li>
      </ul>
      <p v-else-if="list.length">List is not empty, but hidden.</p>
      <p v-else>List is empty.</p>
    </template>

• Plus (and this is just an unverified hunch) I think that in absolute terms, you could get better performance with Vue's approach. Because the parser / renderer can be fully written in low-level language like Rust. Whereas in the FastUI approach, each HTML element needs to have a corresponding Python object created.
  • E.g. that you need to instantiate a Python object like so c.Heading(text='Users', level=2) instead of simply using a string <h2>Users</h2>

It makes sense to go big

The reason why I'm writing this, and why I linked the article about Pydantic is this:

Previously I didn't hear about stories like this from Python ecosystem, unless the solution was focused on data sci / ML / AI.

And django-components is for making web UI, so nothing to do with ML/AI.

So my expectations were that, ok, maybe I could get it to the point that django-components (DJC) would become the default engine for Django, but that was about it. I thought that going beyond this point, with things like django-vue or making DJC into a standalone thing usable outside of Django, that these would plateau. That I'd make these, and they'd slowly ferment and grow, and I'd move onto a new job and do something else and maintain these projects on the side for fun.

Buuut, with that article about Pydantic and Logfire, I get the impression that, if I grow this project to the point that it would be one of the best tools in Python ecosystem, that then it could actually pay the bills somehow (while still keeping it OSS). What's more, it could get to the point where I could build and explore lots of other cool stuff.

I stan people like Stephen Wolfram, because from his livestreams I get the impression that he gets to nerd out af, and yet do it full-time. Whereas I currently sacrifice a lot of time and money to work on this. So if there was a way to work full-time on this, that'd be f'ing awesome.

It would require me to double-down on working with web technologies for the foreseeable future. In 2024 I was thinking that maybe I could wrap up my web dev career and move onto something else, something where I'd be "saving lives" (not literally, but just using my time to work on projects that feel more meaningful than dashboards). But over the last 6 months I started leaning heavily into what I'm good at and worked with that. And the challenges so far were actually quite exciting. And so if there comes along an opportunity that I could do more of this, I'll go for it. Maybe 3-4 years ago I passed up on one project were I could've had a similar level of creative freedom and stimulation, but I was too anxious and insecure back then. So I see now that these don't come around every day.

Implications

1. Marketing the ambitions

So far, whenever I was talking about DJC (as in, the scope of DJC, not individual features), I kept it humble - I didn't want to promise things that we didn't discuss and that you @EmilStenstrom didn't agree to.

But to get more people on board, this project would have to get loud about its ambitions. E.g. presenting DJC as the next Django templating engine, or that people should help us because we want to build the fastest and bestest Python UI web framework.

2. Game plan

I think it still makes sense to continue with what's in work. I'm currently thinking of:

• v1 - django-components (DJC) still as an installed Django app, v1 would be released once DJC has matured enough
• v2 - DJC as a separate Django templating engine, taking ownership of parsing templates, not just the {% component %} template tag
• v3 - Making the core to be independent of Django. django-components as a package would be home only to Django-specific bindings.

For continuity and memories, it'd be great to still use the same org even when reaching v3. Maybe the org name would need updating at that point. But packages like django-components or the django-debug-toolbar integration could remain as they are, so users shouldn't be affected

3. Change in principles?

I think these will become relevant when working towards v3, but:

• As I mentioned earlier, I'd be willing to go great lengths to make this project the speediest boi on the block. So at that point I'd be up for moving more parts to Rust to get that perf bonus. But this may go in conflict in how you @EmilStenstrom wanted to keep the project easy to contribute to.

  • My counter argument to that is that (based on git blame) much of Django's templating logic hasn't been touched in 6-10 years. So IMO if there's someone like me who's willing to get their hands dirty, I should go for it and take it as far as I can.

• Regarding the "Vue-like paradigm" that I mentioned - if we go through the version v1 to v3 as outlined above, then once this project can be used independently of Django, then the Django's curly bracket syntax with {% ... %} doesn't make much sense. Because it's an abstraction over the HTML, and doesn't even play well with HTML spec / linters / etc (basically the whole selling point of django-cotton).

  So, by then, I think it would make sense if the core (Django-independent) package used < ... > instead of {% ... %} to render components, define slots, and insert fills.

  Django-components package (as the Django-specific bindings) could still use {% ... %} to ensure continuity for Django. However, internally, the {% component ... %} would be transpiled into the < ... > syntax before the components would be passed to the core (Django-independent) package.

  So it's the exact opposite of what I had planned for django-vue, where I wanted to transpile Vue syntax into {% ... %}.

@JuroOravec This is awesome, and I really like your ambition.

Full-time

1. I would love to find a way to have you work DJC full time.
2. I think taking outside investment is a lousy idea, because that means you can't no longer work on what you want. You then need growth at all costs. That kind of money always comes with attachments and demands. Taking outside investment should be the last thing you do unless there is no other way.
3. A better way is to get companies to sponsor your time working on this project. If there are many companies chipping in, there are fewer demands, and more time to get things right long-term. I think that would be ideal.
4. I don't think you should do this alone, and instead do this as part of a group of contributors. I would be happy to continue to do this part-time as a bystander, but I'm happy where I am, and my main priority will be elsewhere. So we need more contributors.
5. I think we should think of this as building an ecosystem around us. Of people and companies, all helping out in ways they can.

Django and DJC

1. Thinking about it, I agree that it's more likely that people start to switch to our own template engine, than for Django to include django-components in Django. So I agree, I change my mind, and from now on we're skipped the my goal of getting this library included in Django.
2. I fully support your three step plan. v1: Slightly more of what we already have, v2: Full template engine, v3: Full python web framework.
3. I really think we could build a full web framework experience. I like the model of a "tree structure of components" being the core of it all. Where parts can be dynamically switched out and re-rendered at will via HTTP. I think that would be a delightful way to build rich, performant applications.
4. About curly brackets: Django/Jinja is something that people in the Python world know, so it's a nice cheat code to low mental load. If we get to v3 and start thinking bigger, I totally think we should think hard about what template language we want to support.

Values

1. I think it's about time that we start talking about values and principles for this project. I think this matches well with being better at selling the project to companies and contributors alike. We're going somewhere. Here's our vision of how web development should be.
2. I agree that we should lean into HTML, JS, CSS as core parts of the library at all levels. They shouldn't be abstracted away. People know them, and it makes the library approachable, and existing frameworks possible to integrate with.
3. Simplicity should be core to this library. This is a tough one, especially if you're smart and can handle a lot of complexity. Because that means you don't see when things are hard. But most people, including the smart ones, think this is super important. People want to understand, they want to feel that things are easy, they want to have mental space over for other things. Getting simplicity right is super hard, but very valuable. If people would say "it's a little to simple, but it works" I would be very proud of it. There's so much other stuff going on, in the world and in web development, don't take up people's mental load.
4. Performance is important. You have opened the door to optimizing parts of django-components in Rust. I think that could be a really interesting way forward, and don't oppose it at all. I still think this could be a deterrent to joining as a contributor, but maybe this can be countered with keeping the "coordination parts" in Python, and only doing limited performance-critical things in Rust? "Many small and fast Rust black boxes being controlled from python" sounds good to me.
5. We need to really land the above three (and others) ourselves before starting to marketing them to others. Maybe that should be the next step?

@EmilStenstrom Beautifully said, I agree with most it!

Re: Work

Yeah, VC is not the way here. The only way out then would be to be bought and disintegrated or go bust. And I want to keep my babies 😄 There's also the queston of how much the Pydantic team can truly focus on the existing projects if they have obligations with Logfire.

Though what I found interesting about that article is that it suggests they were able to make waves while building Python libraries. And IMO the same applies here - I think it will be easier to convince people and sponsors when selling the big vision.

Re: Django and DJC

On curly brackets vs < >, that's a tough one, and I'll definitely leave this question until we get around v3.

Because yeah you're right that current Python community is used to {% %}.

On the other hand, the tooling for < > is already out there - when you start up a React of Vue project, you can literally just press one key, <, and you get suggestions of available components, you select one, and boom - in 3 key strokes you have written <MyComponent></MyComponent>. For curly brackets, we'd have to build it up.

But if we consider chatbots, then those 3 key strokes may be totally irrelevant. And maybe chatbots could make it substantially easier to build up a language server to provide a similar level of convenience as Vue/React projects?

So basically what I'm saying is, there's a lot of unknowns.

Re: Values

Yup, agree with those too!

• Agree, simplicity is hard, IMO it's a neverending process as things shift and come and go. Even now there's parts that are more complicated than they should be (e.g. with the "django" vs "isolated" modes, or ComponentRegistry and TagFormatter), but at the time were good enough solutions.

  • Off topic, but I think even TagFormatter could be eventually yeeted out as a plugin. And once django-components becomes a standalone templating engine, then ComponentRegistry could be merged with Django's Library class. So there is some improvement possible.

• On performance, 100% agree. Currently, component.py, slots.py, and dependencies.py are files that are constantly being changed, and I would not want to move those to Rust, because there's just really high change that something needs changing whenever there is a bug or a new feature. But things that are on periphery and have only a single narrow goal, those are good candidates.

We need to really land the above three (and others) ourselves before starting to marketing them to others. Maybe that should be the next step?

What do you mean? "Ourselves", as is you and me as individuals, or as in that the project should reflect those values first?

@JuroOravec I mean you and me, setting up a kind of steering doc for the project, maybe based on those three points?

Btw, slightly different topic, but need a place to info dump, and this is the closest relevent.

Having the case of Pydantic at the back of my head, I realized today that django-components, with all the tooling around it, would make it possible to build an AI assistant for working with Django / Python web projects. Technically a website builder, but with the idea that the assistant would be meant for existing and legacy Django projects.

The reasoning is that I'm building out a nice collection of tools that would provide metadata to guide an LLM with edits.

• The "tag parser" I wrote is just a step from being an AST parser for full django templates. So that would provide enough info to guide LLMs to edit the templates.
• As I'm finishing the benchmarking, I think it would be possible to build integration on top of it - So basically some way how people could easily create benchmarks for individual components. This would provide performance data.
• The storybook integration - something like that could be used to generate visual data.
• The typing for our components means we have statically defined inputs. Again a datapoint that an LLM could use to make better edits when working with Django templates.
• The details trace logs would give the LLM sufficient context to fix bugs.

...But anyway, it feels too early to be thinking more about this, so parking this idea here for the future.