Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

FastHTML – Modern web applications in pure Python

fastht.ml

Post reply on HN
Print view View original

221–229 of 229 posts

Re: FastHTML – Modern web applications in pure Python

#221

Post by idf00 »

mrweasel wrote: post #192
jph00 wrote: post #68

Earlier quoted context omitted.

In this case, it's a 1:1 mapping to what's on the page, so your concern doesn't apply here. Debugging and refactoring is far easier with Python functions than templates, and CSS programmers just use CSS the usual way. 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 usin…

> - They require a separate language to write the templates, which is an additional learning curve 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 fi…

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() ->

Div(P()) ->

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.

Re: FastHTML – Modern web applications in pure Python

#222

Post by anoojb »

Thank you for building this :-)

Can you address the longevity question? Do you think you and/or other highly motivated/enthusiastic folks could be maintaining this project for the long-term?

Or should we only be building projects on top of this framework with a 2-3 year time-frame?

Re: FastHTML – Modern web applications in pure Python

#223

Post by yawaramin »

mrweasel wrote: post #192
jph00 wrote: post #68

Earlier quoted context omitted.

In this case, it's a 1:1 mapping to what's on the page, so your concern doesn't apply here. Debugging and refactoring is far easier with Python functions than templates, and CSS programmers just use CSS the usual way. 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 usin…

> - They require a separate language to write the templates, which is an additional learning curve 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 fi…

> You can't use FastHTML without knowing HTML anyway

We are not talking about the learning curve for HTML but of Django or Jinja or Mustache or whatever templating engines and their special syntax for loops, conditionals, etc.

Re: FastHTML – Modern web applications in pure Python

#224

Post by halfcat »

jph00 wrote: post #20
halfcat wrote: post #16

Earlier quoted context omitted.

This seems like the path to widest adoption. Focus on building an “HTMX component” library and just use Django, and not recreating a less battle tested Django. 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/

Both of the co-authors of the popular book series "Two Scoops of Django" are now FastHTML users and contributors, and they tell me that they're able to reduce the complexity of their Django software by quite a lot by rewriting in FastHTML. 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 htm…

Have you written about the drawbacks of Django anywhere? I can’t decide where I land on this kind of stuff.

On the one hand, Django’s not “fully async”, etc.

On the other hand, someone built Instagram with it, and it hit the right balance of structure and flexibility that they could modify it’s pluggable parts to meet their needs, and eventually it’s perhaps nothing but the Django request/response cycle with everything else custom built. But to me that’s a wildly positive success story. Working as intended.

And you know, the trope of “you don’t have any users”, funny because it’s (usually) true. Like async/etc doesn’t matter when you need to serve 1 request per minute.

Re: FastHTML – Modern web applications in pure Python

#225

Post by [deleted] »

harel wrote: post #194
idf00 wrote: post #157

Earlier quoted context omitted.

> 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 fa…

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 peopl…

[deleted]

Re: FastHTML – Modern web applications in pure Python

#226

Post by yawaramin »

098799 wrote: post #108
jph00 wrote: post #105

Earlier quoted context omitted.

You can just use `@app.get` and name your function whatever you like, just like FastAPI, if you prefer. 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.

Thanks for the info. In general, being compliant with established conventions (even if you don't personally like them) can lower the barrier of entry for some people who may superficially reject your library based on esthetic concerns. If you'd like to dig deeper, the reference is: F811 redefinition of unused 'get' from line xx from flake8 and error: Name "get" already defined on line xx [no-redef] from mypy.

But you would have these 'get' functions in different modules though, so how would it be a 'redefinition'?

Re: FastHTML – Modern web applications in pure Python

#228

Post by damanamathos »

anon373839 wrote: post #209
jph00 wrote: post #107

Earlier quoted context omitted.

I'm a big fan of Locality of Behavior (LoB): https://htmx.org/essays/locality-of-behaviour/ . I don't think this need be incompatible with SoC. But even if you did think so, I believe that it's better to have everything in one language as much as possible, with the simplest possible specification of marshalling over network boundaries. My view is that hypermedia is a better way to do both of these things. (I think HT…

> (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 r…

FastHTML has a NotStr(X) component that renders X as HTML.

I just copied a big HTML Tailwind component to a NotStr() and it worked fine.

I then split it in two, before and after, so I could make the dynamic bit from natural FastHTML components and it worked fine returning Div(before, dynamic_parts, after).

Plan to convert most of my smaller websites to FastHTML in the next few days before it's much more enjoyable for me.

Re: FastHTML – Modern web applications in pure Python

#229

Post by yawaramin »

nprateem wrote: post #137
harel wrote: post #24

First, I welcome any project that enriches a software ecosystem, and this project no doubt does just that. However, I have two points which will deter me from using this (or any python->html/js framework) in a commercial production project: 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 deve…

That's always the problem with these things. You can no longer leverage the bigger ecosystem (e.g. just copy HTML templates from libraries), and I can probably count on no fingers the number of decent designers I've met who knew python. So as soon as you want to grow your team you'll end up with a split. Still, for projects that are only likely to stay small it might be fun. But then you'll have to remember how it wo…

> You can no longer leverage the bigger ecosystem (e.g. just copy HTML templates from libraries

You can definitely do this with FastHTML: https://h2x.answer.ai/

Post reply on HN