If you had python code and you didn't want it to have syntax highlighting or be run/imported or any of the other normal things that you do with python files, it might make sense to have python code in a .txt. file.
Same idea here IMO. .md would signal the wrong intent, as you don't want to render it to markdown formatting or read as a markdown file normally is. You want it to be read as plain unrendered text.
...it gives you a version only the LLM will see, as opposed to having to identify the visitor as a scraper or human and determining if they get the good or bad version.
What do you have trouble reasoning about regarding FastHTML python compared to Jinja2 or Django templates?
To me, it seems like a direct translation, and that's what makes it easy to reason about. I'm curious about what situations you find more intuitive to use Jinja2 over Python.
For example, in FastHTML:
P() -> <p></p>
Div(P()) -> <div><p></p></div>
The lack of a big transformation layer and things being 1:1 is what makes me think it's just as easy to reason about, but it comes with the advantage of a more powerful Python over a templating language.
I agree that this wouldn't be a great solution if you want people who don't know Python to make HTML edits.
IMO it's not a "structure in one place" vs "more composable so more spread out"
In HTML, you are much more likely to have things in one place because you don't have great options otherwise.
In Python, you can choose to keep things in one place and not compose them, or you can choose to refactor to compose them if that makes them better for your particular use.
It is, however, definitely true that with the extra option, you have the option to refactor it so much it's less readable. How much to refactor and split things apart, decentralize, DRY vs how much to keep things in a structured place can be a hard thing to figure out!
> Once you grow beyond the "website" with simple interaction your front end becomes it's own universe
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.
I guess it's a personal preference. I tried it, and it looked a mess in my eyes.
Take a strong tag:
Div(
"If you click '",
Strong('Accept all'),
"', we and",
A('our partners', href='/v2/partners', target='_blank'),
...
It just verbose, very Java like, and feels like a step back in a commercial setting. It's absolutely fine if you're a single developer, HTML disgusts you, and Javascript is an abomination. I know people who think that way and I know they would love it. But I'm as comfortable with JS and I am with Python (after over 25 years using both). Someone likened JSX to it - but it's not even close - JSX brings the tag structure INTO JavaScript, not takes it away, to achieve the exact opposite result of fastHTML.
This is html building not js. It’s not any more verbose, in fact slightly less because no need for closing tags. Main difference is parens instead of angle brackets. Now you can use tools.
I do prefer lower case callables but that’s a minor nitpick, and “htpy” and other libs can do that.
Yes, it is HTML, and it loses all the benefits of HTML, by adding complexity of code and loss of structure. I'm uncomfortable with HTML and JS obfuscated by Python like that. I'm not using the word "verbose" as a character count comparison, but as an overall feel of weight when I see such code. It just takes me back to Java Swing, or ExtJS in the JavaScript world. It's not bad if it's the only way to describe an interface or layout. But there are better ways - HTML.
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.
The complexity and structure are near equivalent. S-expressions are an html precursor.
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 guess you have to add some plugin? I mean in Rmarkdown in Rstudio I just go ```{ruby} and I have a ruby block with nothing special installed. That doesn't work by default with Quarto.
In the Quarto front matter, you can choose to use a Jupyter backend, in which case any Jupyter kernel can be used to interpret code blocks. Many languages, including APL, have Jupyter kernels you can install.
I didn't see anything in the article that indicated the authors believed that those who don't see use cases for LLMs are anti-progress or anti-technology. Is that comment related to the authors of this article, or just a general grievance you have unrelated to this article?
