I wrote my first web app ~30 years ago, and have built some pretty big projects, including founding fastmail (written in Perl) and leading the first major production version of Kaggle (written in C#). Frankly, I've enjoyed creating web apps less and less over the last few years. So I decided to try to create something that I'd personally enjoy using. I like coding with Python, it's got a great ecosystem, and deployments like Dropbox and Instagram show that it can scale right up.

FastHTML brings together Python, hypermedia based apps with HTMX, the powerful and flexible ASGI/Uvicorn/Starlette trio, a new Python component system called FastTag (FT -- based on many similar projects from the functional programming world), an API design inspired by FastAPI, and a few more bits and pieces into something I've now written around a dozen apps with. I'm really loving it!

I hope some of you get a chance to try it out -- let me know what you think.

- Incremental complexity - starts super simple and I can add stuff as I need it. I don't like frameworks where step 1 already leaves you with lots of files and a bunch of things you need to know.

- Easy escape hatches. I like some of the simpler demo/dashboard things but inevitably hit a ceiling that suddenly requires a lot of hacking to get past. Since FastHTML is a lot more transparent it's very easy to go right in and do something with JS or mess with the request or make something custom. So you're not stuck with only the widgets a framework gives you or anything like that.

I have a few questions for you.

1. Why do you recommend conda or pip and not uv? Is this because the plug and play deployment platforms are configured to use pip?

2. Do you plan to make this “batteries included” like Django? E.g. it looks like currently you have to manage database schema and migrations outside of FastHTML.

3. Perhaps not in scope for this, but it seems to me making LLM API requests in the FastHTML backend could cause some scaling problems since these i/o operations can take a really long time and tie up the same threads required to render web pages. Any thoughts on that?

EDIT: Added third question.

2. We plan to include batteries in situations where it results in something better than just using some pre-existing project. So for DBs for instance we created Fastlite (a thin wrapper around sqlite-utils) since that particular API works best with FastHTML projects. You can use `transform` for simple migrations BTW. For more complex ones, we're planning to add support for sqlalchemy/alembic and other systems

3. We recommend using async for LLM API requests (which is supported by FastHTML, thanks to ASGI/Uvicorn/Starlette), although you can also use threads. uvicorn supports running multiple workers too. So there's lots of scaling options

> A Python package manager: we recommend conda or pip

2. Makes sense! Something like sqlalchemy/alembic would be cool for PostgreSQL support.

3. Ah, this is interesting. Will read up on the different ASGI implementations. I had just assumed that having LLM workloads, async or not, on your main web server would be a problem (memory and/or i/o), but maybe not. To do date I’ve been moving LLM i/o workloads to background jobs on different machines with Celery, but it’s a bit more work and also makes streaming impossible. I recently did a Qwik + Celery stack for heavy LLM use, but have wanted a pure Python solution.

Thank you!

You shouldn't generally run your AI model directly on your web server, but instead run it on a dedicated server. Or just use an inference service like Together, Fireworks, Lepton, etc (or use OpenAI/Anthropic etc). Then use async on the web server to talk to it.

Thanks for pointing our the JS app walkthru mention - I'll update that to remove conda; we don't have have FastHTML up as a conda lib yet! I also updated it to clarify we're not actually recommending any particular package manager.

I am honestly mostly interested in your reason, to mix HTML/CSS generation into the Python code. Disclaimer, I am very biased towards separation of concern and like my backend just returning JSON/XML/whatever data and a templating system. Of course this increases the ramp-up time to learn a framework, but then it is IMHO very powerful, flexible and fast.

Could you perhaps elaborate on your choice for FastHTML and what tradeoffs you see?

(I think HTML templating is a historical accident for what it's worth, and I hope it dies.)

HTML templating does have one very nice benefit though: there’s a seamless path between designing and iterating on a static HTML template (which renders in the browser) and then sprinkling in the dynamic bits on top of that.

If you start with fairly complex markup in the initial design, I’m imagining it could be tedious to rewrite the whole thing in Python. Or is there some tooling that can help with this?

It might be worth writing a blog post about that. It sounds like you have some more interesting things to say about the topic.

I am not too very happy that we need at least CSS/HTML/Javascript (ok, HTMX...) for web applications and would love to have a simpler tech stack.

For me, the biggest concern is CSS/HTML/JavaScript do not go away and it seems to me, when I choose FastHTML I still need a descent understanding of these AND need to understand how FastHTML transforms Python code on top of it. Templates show me mostly what I will get once they are rendered, which means less mental work for me.

Templating w/o embedded logic like Mustache are acceptable for me and I found good use cases for them. Once templating systems become obviously Turing Complete I see a problem. ;-)

I understand your reticence, because there have been a great many similar-looking projects over the years that create abstractions over the foundations. This isn't one of them -- it's a direct simple mapping.

So far, there are ways in which it's definitely nicer to build things with an actual programming language, to have proper function signatures and types, to be able to easily break things down into composable bits.

But it also certainly seems to me at least to obscure the overall HTML code structure, compared to what I had in the templates. Maybe that will change somewhat as I get used to "reading" the new system, but the very fact that it's now much easier to compose things means that the overall structure won't be in one place any more. Just one of the trade-offs of a system like this.

Often we see "components.py" for presentation and "content|logic|models.py" broken out for business logic. You can see this pattern done in my as-yet-DNS-switched blog here: https://github.com/pydanny/daniel-blog-fasthtml

Of course, it's still early in the project, it's going to be interesting to see what patterns emerge over time. :-)

I'm really excited to give this a try seeing as this should just run on our cloud with minimal to no changes given the premise.

I know of one or two other projects like this in the ecosystem, but this approach seems the most promising so far.

Also I'm not sure when Jeremy finds time to sleep given all the other exciting work from Answer.AI. and his various courses :P

I recently implemented deepspeed + qlora in a finetuning library and that was also entirely based on the fsdp implementation him and his various associates wrote.

So he really is just making great contributions all over the place.

Also, because FastHTML is powered by starlette, it handles async really well. That means web sockets have been a trivial implementation.

One pattern I use is putting all the functions that generate HTML inside their own class. That way, I can more easily create and reuse components like:

  class Views:
      ...

  def comp1(self):
      return Div(self.header(), P("too"))

[0]: https://htpy.dev/

I've wondered about a class-based approach like that -- interesting to hear it's worked for you. I should try it! I'm using a purely functional approach for re-use, as you see in this example of the code for about.fastht.ml:

https://github.com/AnswerDotAI/fh-about/blob/main/overview.p...

What made you build FastTag instead of going with htpy? I am the author of htpy and any feedback would be very welcome!

Having child elements as a list (i.e: the __getitem__ override) makes it convenient to build elements based on simple conditions + list comprehensions. This can be done with other frameworks, but it seems more natural to me when using `htpy`.

I also like that you can just `print()` elements and get the final HTML without having to pass it through a different function. This is not something specific about FastHTML, but rather something I've found I also had to do when using `lxml` or similar tools (I wrote about my experiments here[0])

[0]: https://ricardoanderegg.com/posts/python-build-html-componen...

Also, I was able to implement FT using just 2 lines of code -- it felt like a very natural data structure that was a good fit with Python.

Having said all that, I think htpy is really nifty and elegant. :D

I actually hate working in HTML with all those closing tags etc so I nearly always set up a build/make process to edit my templates in PUG format. When I paste my PUG->html output into https://h2x.answer.ai/, or run html2htpy over them, I get python code that basically looks the same as those PUG templates. What a realization that is! So I may as well create and edit them in python rather than PUG and exploit the power of my beloved python dev environment and tools (as nicely stated in that "Throw out your templates" essay https://github.com/tavisrudd/throw_out_your_templates reference from the htpy docs). Thanks very much Jeremy and Andreas for this fantastic insight :)

I have always been reluctant to accept any boilerplate code (esp. such that one cannot fully understand) in my codebase, and this does not have ANY! All the sample code looks absolutely beautiful, so I will give this a try for my next Web app projects.

FastHTML's concept led me to consider a feature that allows direct deployment of PyQt code as web services, even without HTML knowledge, like "PyQtWeb."

PyQtWeb > FastHTML > [Streamlit, Gradio]

I'm only really familiar with Django and DRF, but if love to switch at some point.

Starting with more flexible initial components (e.g. Starlette) and adding batteries (SQLAlchemy, Jinja2, HTMX...) as needed allows for a sensible evolutionary approach and prevents painting yourself into a corner with early decisions.

And with enough time you come to realize there are certain things that are out of scope for the current codebase. Just as there are things that are out of scope for the current marriage.

hahaha - I dont know...I should stop here. This metaphor is stretching thin

Maybe I'm not the ideal user, but would like to know from you who do you think this is for.

Having said that, the people that will get the most out of it and folks that haven't got much prior web dev experience -- e.g. people who have just done some streamlit/gradio/etc apps, or maybe Python programmers that haven't written web apps at all. I mention this briefly on https://about.fastht.ml in the section "A new generation of coders":

> "Coding is the key to turning the ideas in your head into products and services that can help people. AI has recently made it easier to get started with coding, which means there are more people than ever before who can create useful stuff. But this new generation of coders do not generally have the same background as full-time software engineers. They may have been trained in a different field, or they may have learned to code on their own. We hope that FastHTML will make it easier for this new generation of coders to turn their ideas into reality. To create maintainable and scalable solutions."

Then I realized that part of the Python code in the repo is generated from notebooks...

I'm not a Web programmer, so just took a peak out of curiosity. I'm just a little bit happier now that I'm not a Web programmer.

1. It silos front end development in Python world. It might be great if your entire team are and always will be Python devs, but what happens when you want dedicated from end developers? What happens when you need to deviate out of what the framework gives you in a front-end context? What happens when you need to eject from "python" into a dedicated front end environment? All your front end code is now written in Python. Worst, you now might even have JavaScript code embedded inside Python code. I keep hearing "CoffeeScript" in the back of my mind...

2. Any python project using FastAPI (which is fantastic), flask, etc. and is growing in scope, will ultimately build Django. For example, FastAPI (which is great), has SqlModel (which is awesome) which makes SqlAlchemy less sucky and more like Django. Start to factor in all the other batteries we got used to getting with Django, and it starts adding up. If the project is smallish in scope and well defined to know it will stay such, sure it's a valid and excellent choice. The same applies here - unless batteries are included, or this is (as suggested in a comment) available as a Django app, you'll end up building Django.

For instance, I wrote a little app (https://word2md.answer.ai/ ) which lets you copy/paste from MS word, and converts it to Markdown. I found that there's some nice existing JS code for cleaning up MS Word markup, so I used that on the client side, and used server-side python code for converting that to markdown. Here's the Python code, which is just plain python in a regular python file:

https://github.com/AnswerDotAI/word2md/blob/main/main.py

And here the JS code, which is just plain JS in a regular JS file:

https://github.com/AnswerDotAI/word2md/blob/main/wordpaste.j...

Regarding (2), I've heard the same basic argument nearly every time I've tried to create anything new, and I've heard it apply to lots of other people's projects too. Yes, if there's an existing product that's pretty good already, then it's likely the new thing won't be as good in every way. I don't think that's a reason to not try to make something better, however. I like Django a lot, have used it since its very early days, and I'm friends with one of the founders of it -- it's an amazing project. But it's not perfect, and hopefully it's OK if some people want to try different things too.

Regarding 1, I get it, although I do like my ends to be separate. Maybe it's a question of aesthetics and therefore completely subjective.

Linted, formatted, optionally typed Python is likely going to be more maintainable than html templates in the long run and is one of the easier langs to pick up. css/js can be linked separately.

I don’t see any limitations that would prevent one from using a template on a new page.

I recently looked into these kind of html builder libs, pioneered by dominate. “htpy” was the only one where I was impressed with the source code.

As an aside, HTML is formatted in a very visual way in my opinion. The tag syntax makes it clear to visually identify blocks and layout elements. You lose this when you describe the layout in Python.

I think this has been a major failing/pain point of web-dev that this MUST be the case. However, I think fastHTML for me is going to fix that. Naturally there is no approach that is ideal in every case, but for a ton of them fastHTML I think works. I've built several things with fastHTML and am very optimistic.

As far as the visual identification, I think python is just as clear to see visual blocks as HTML, but comes with many additional refactoring options (that you can choose when it makes sense to use for your use-case).

Try playing with https://h2x.answer.ai/ and putting in some HTML code and see how it looks in python. Maybe you'll disagree, but I find it quite refreshing.

Take a strong tag:

    Div(
        "If you click '",
        Strong('Accept all'),
        "', we and",
        A('our partners', href='/v2/partners', target='_blank'),
        ... 

I do prefer lower case callables but that’s a minor nitpick, and “htpy” and other libs can do that.

Please don't get my comments as criticism of the project itself, I think it's lovely and has a lot of merit. I've had to deal with the aftermath of these kind of things before, which makes me very aware of where it usually ends up at: Devs in language X don't like Html/JavaScript/Y/Z, so they wrap it with language X until X is all there is. Then one day, the business realises they have a codebase nobody other than it's original creators can or want to deal with, and any change becomes a behemoth of a project. It always starts with the best of intentions.

Python is one of the most popular languages and easy to read. People are more resilient than given credit.

I tend to agree with your closing comment about over abstraction in general, however you may have forgotten that a Jinja/html template is an abomination of conflicting concepts.

I’m more worried about the rest of this framework to be honest. :-D

I agree about that HTML looks better with tags and it takes a bit of getting used to the python syntax. If something like JSX was possible in Python with all the tooling working, that would be great.

The main way around that is the SPA/API architecture, but that comes with huge complexity drawbacks as well.

Nothing special about html, at least as a Python string builder you can factor it and use tools. It can also be put into separate files. So many upsides and little to no downside besides initial surprise.

Still, for projects that are only likely to stay small it might be fun. But then you'll have to remember how it works after coming back from your day job that uses a more mainstream framework.

I started to couple my FastAPI backend with native Jinja2 templates and noticed that I hate Jinja2 with passion (no disrespect). I tried HTPY which seemed great but this Python abstraction of HTML just felt weird and I found myself converting HTML to HTPY all the time. I even created a GPT for it. Then I found JinjaX and noticed that this hits the nail on the head for me. It's a Jinja2 preprocessor that allows the usage of components instead of the weird extends and macro syntax.

I'm happy to look at FastHTML but I'm not sure what type of benefit I can expect.

The .ml domain extension may be exactly the placeholder needed :-)

The first demo Jeremy put out was called "Build Applications For LLMs in Python",¹ as part of the "Mastering LLMs" conference by Hamel Husain and Dan Becker.² (You can see a few PoC demos by the end of that video when Johno takes over, it looks a lot like what Gradio or Streamlit can do).

So I think your .ml angle is definitely part of the original ethos of FastHTML (which isn't surprising coming from the founder of fast.ai & answer.ai, among other things).

The FastHTML team explicitly recommends would-be contributors to consider making reusable components, the likes of Gradio's, to facilitate all the things notably relating to AI workflows.

----

About WordPress & CMS

That part is admittedly much larger in scope. I'd expect it to rise in correlation with the success of FastHTML itself in the Python web ecosystem writ large (beyond data / AI) but no sooner—unless someone makes a killer case for a FastHTML-based Python CMS that becomes a driver of popularity, but that's admittedly a much taller and wider order than 'simply' becoming the go-to #1 Python/ML prototype-to-market-at-scale one-stop shop. I mean, just that is huge, and yet nowhere near WordPress.

But tbh, I really like your idea, and I think it may eventually prove true, having used FastHTML first-hand for a few weeks now (and web dev being far from my turf). The fact is can ship with FastHTML, fast & well-behaved web apps, more than I ever could. If I ever get the time I'll play a bit to see what a legacy-free FastHTML CMS could look like. But no matter how good the engine, the plugin ecosystem is what makes WP, and no single dev or company can replicate that alone. It's an alchemy with the times, there are windows. Not sure one is open now.

----

¹ https://youtu.be/ptRaku0zyeA

² https://hamel.dev/blog/posts/course/

I just might have to research.

Is it possible to mix it with gradio? E.g. Make most of layout and UI in fastHTML but reuse some complex high level components from gradio?

I'd love to see gradio-style components written in FastHTML -- I actually raised this idea with the founder of gradio today. It would be a great combo IMO.

Maybe I'm missing something here. Why not a templating engine?

To answer your question, I'll quote from https://about.fasht.ml:

Templates were originally created for web development in the 1990s, back when web design required complex browser-specific HTML. By using templates, designers were able to work in a familiar language, and programmers could “fill in the blanks” with the data they needed. Today this is not needed, since we can create simple semantic HTML, and use CSS to style it.

Templates have a number of disadvantages, for instance:

- They require a separate language to write the templates, which is an additional learning curve

- Template languages are generally less concise and powerful than Python

- Refactoring a template into sub-components is harder than refactoring Python code

- Templates generally require separate files

- Templates generally do not support the Python debugger.

By using Python as the HTML-generation language, we can avoid these disadvantages. More importantly, we can create a rich ecosystem of tools and frameworks available as pip-installable Python modules, which can be used to build web applications.

Sure, but that's an advantage, not the learning curve obviously. You can't use FastHTML without knowing HTML anyway, at least not from the examples. In fact it's a really complicated way to do HTML. Jinja2 or Django templates are closer to HTML and much easier to reason about.

> - Templates generally require separate files

Again, that's an advantage. Someone who are not familiar with Python could easily update the HTML, and someone who knows Python most likely also know at least some basic HTML.

I don't like this, at all, but I'm also not required to use it.

They are awkward to use, usually have a foreign syntax of its own and scale poor with dynamic languages (in terms of ability, not speed). But I also think this solution here is not that good either. It's ok for small stuff or purely tag-based output, but if you have many parameters, it becomes ugly really fast.

We've used those HTML-generators 20 years ago, and they were not really popular. I still use this still for bland XML today. But I can't see this scaling well for a complex website. Maybe there are some more features I've not seen in the documentation, but otherwise I think they should step up some more gears for this. But on the other side, I guess you are not forced to use the helper-functions. At the end they are probably just strings shoved around, so you can use whatever template-engine or string-generator you prefer.

I think you are missing how htmx (https://htmx.org/) is intended to be used. You still have your regular HTML page and by interacting with that HTML, you trigger server-side functions that return HTML. That HTML is used to update only a small part of your page. htmx works with HTML fragments while HTML templates work with entire pages.

In general, you'd have an actual database and make it so users can only see their own data! See https://github.com/AnswerDotAI/fasthtml/blob/main/examples/a... which adds a filter to queries and DDL statements to ensure that the user can only see/edit their own todos.

Is it possible to inject custom JS wherever I want in the app? Also, is the generate html/css/javascript readable as the application scale up?

I always found trying to read function calls as markup to get unwieldy. Realistically people are most likely going to either be using Python with traditional templating engines or Python as an API with a JS framework on top.

Good luck to this project, perhaps it isn't for me.

Personally I wanted to create something that made the foundations of the web more directly available to Python programmers, rather than hiding it behind multiple layers of abstraction. Reflex is very impressive though, and I expect for some types of app it might be a better choice; probably worth trying out both!

How does this compare to Dash?

I've used Dash for many applications, so I'm wondering what are the advantages of FastHTML?

Today's HN launch of FastHTML's home page was running on a $5/month hobbyist account at Railway.app, where it averaged 1% utilization of 1 VCPU.

(The trick, as always, is to optimise the inner loops in your app as needed; often that just means using pre-existing fast libs for that bit, but sometimes you may need to reach for cython/PyO3/etc. Often you'll find you don't need anything extra. FastHTML's own home page doesn't need anything extra.)

Back in ancient times, a software project I was working in, failed, precisely because of Python performance with the Zope framework, it was too slow to render a webpage that required more than a few interesting calculations.

Today the language is almost the same, but computers have a thousand times more memory, and the CPUs are similarly faster.

The exact same project would have been successful today, just like neural networks are cornerstones of modern computing, because of the advances in hardware.

Yes, it’s glue. True for Ruby, PHP, Perl as well.

I just think it’s disingenuous to associate the word “fast” with anything implemented with it, granted that C is 70 times faster than it. I mean, me saying it’s slow compared to C is less hyperbolic than saying it’s fast.

And I think Python is perfectly adequate for plenty of use cases, so is PHP, so is Ruby. I like to be mean to JavaScript, but even that is fine for web dev.

The bottom of the benchmark table are all slow Python implementations xD

Just wanted to say, nice job, love how much work has gone in to this and especially the site/docs to help people get going.

"Fast"

The interactivity on the home page is just using Tailwind. I don't see why it would be slow for you (other than that the site is quite visually complex, so it naturally requires some baseline level of performance on your device).

I actually prefer Kotlin for a lot stuff people use those languages for. Similar amount of stuff to download but just a lot better tools (e.g. refactoring) and less leaky abstractions. I've used all of it of course. I just know what I prefer at this point. I was doing some python last week. It's alright but also quite a messy ecosystem.

As for Graphql, I just completed a project of ripping that out. Using it was a mistake. People like it for the wrong reasons; mostly because they are afraid of joining tables with SQL and spending some time thinking about what the optimal table structure is to minimize the amount of expensive joins needed. So they end up using stuff that does that poorly by combining the results of multiple micro-services after it comes out of the database. Which has all the predictable downsides in terms of performance. People use ORMs for the same reason. ORMs are popular for the same reason. It's not the tools but the people wielding them shying away from thinking about doing more optimal things with their databases. This stuff can work fine if you know what you are doing of course. But lots of people simply don't.

Python 3.13 will have a JIT, and true threads. It'll likely take a couple more releases for these features to be stable and utilized throughout the stdlib and the wider ecosystem. In a few years, performance and quirks will likely not be an issue.

Whenever I run some benchmark myself, I do not see any improvements over Python 3.7 and the horrible numbers for the threaded build.

I do not understand why Dropbox and Instagram are cited as references. People also cited Google 10 years ago, but Google has now fired the Python team.

Dropbox moved large parts to Golang, and Instagram code does not seem to be something to aspire for. Perhaps Instagram manages to prop up a horrible stack by throwing hundreds of developers at the problem. Not every company, especially startups, can afford that.

If the new free threading becomes the default, I would not expose Python directly to the web. Already before that CPython has show a lackadaisical attitude towards threading correctness and convoluted abstractions that are barely auditable.

We’ve built a few APIs which serve millions of users without any problems and with very low latency with FastAPI, and so far we’re very happy with the choice.

Static analysis is pretty much impossible for large python codebases. IntelliJ does not understand a single shit about the codebase I'm working on and I find myself having to ctrl+f instead of being able to shift click, etc. There is simply such a thing as "too dynamic".

Python was designed for quick scripts and pseudocode mockup prototypes. There's a bunch of bullshit strapped onto it nowadays but there's no escaping the roots of the design of python. It's not a good fit for large software or software nor software that needs to be reliable. Sure, with _enough effort and discipline_ you can bla bla bla. I'm not interested in that. I'm interested in working smarter, not harder.

but not having to context switch from python to another language is worth it for 95% of applications.

Although I don't see why flake8 should care - multi-dispatch is built into the python stdlib so having multiple functions with the same name is not weird or new.

If you'd like to dig deeper, the reference is:

    F811 redefinition of unused 'get' from line xx 

    error: Name "get" already defined on line xx  [no-redef]

From what I understand is this adds JS bindings.

Like, just using htpy [1] with Django and some minor component abstraction seems like it might already be a feature complete version of this.

[1] https://htpy.dev/

Django is fantastic and I'm a big fan, but it's gotten over-complicated in recent years IMO and isn't explicitly designed to work well with HTMX or ASGI. Using it with htpy and htmx is a totally reasonable option for folks that already know Django well, but it's not going to be quite the same thing as using FastHTML.

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

I'd love to help you with documentation and such; hit me up at [email protected] 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.

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

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.

On the frontend, things are a little less consistent.

How does the performance side of this thing look like?

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.

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 want to see how I can manually wire and create anything I want, is what I'm saying and this demo felt like it capitalized on how fast you can do very simple functionality with a couple of functions, which was a let down.

I want to see how I can route (GET/POST), create a database schema, use the database, use CSS (this is very important) yet what I saw was a simple calls to some database store, and no CSS examples. And "a single python file" sounds unrealistic since anything complex enough is going to be split into a series of files. Maybe I'm not the target audience.

I felt very comfortable using Flask recently because it allowed me to do anything I needed.

I do like the idea of building and manipulating HTML elements through python, so hopefully something good comes out of this.

I will say I do think some opinions on how to structure URLs to return snippets might be valuable. Some of these frameworks leverage headers htmx sends to use just part of the page, but I think it is easier to just have individual URLs for many use cases. I've used Go and Templ in a similar fashion and one benefit with Templ is that the snippets are effectively functions, so returning the specific section and passing args is reasonably natural when breaking something out of a page.

Overall though, the goal is to avoid duplicating your data model and abstractions in the UI in favor of relying better networks, faster browsers, and HTML improvements to create interesting interfaces with simpler code.

really excited for this project. I hope it catches on. It has some really nice ideas in it, like all the stuff jeremy does!

PHP security issues (which may have been fixed in recent versions for all I know!) aside, is there anything that these modern frameworks can do that PHP cannot?

If one argues by corporate authority as done elsewhere in this thread. Facebook used PHP, so clearly it scales (probably much better than Python).

If anyone knows a resource (including books) that explores this topic in depth, I'd very much appreciate a link.