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

191–200 of 229 posts

Re: FastHTML – Modern web applications in pure Python

#191

Post by sk11001 »

bruce343434 wrote: post #171
sk11001 wrote: post #98

Earlier quoted context omitted.

Can you expand on the features you need for managing complexity in large code bases? 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 typing (that is actually sound, strict, and enforced by default) with support for interfaces. Just generally a language that doesn't incentivizes using strings and dictionaries for everything. A language that has actual separation and implementation hiding, rather than the convention of using underscores and praying that no one touches it. Static analysis is pretty much impossible for large python codebases. I…

Pydantic, dataclasses and mypy help a lot, I don't get what you mean by incentivizing strings and dictionaries for everything, that definitely doesn't sound like good modern Python. The go-to-definition functionality is available in any modern editor, it sounds like yours isn’t set up properly.

Re: FastHTML – Modern web applications in pure Python

#192

Post by mrweasel »

jph00 wrote: post #68
CodeCompost wrote: post #65

Sorry, but I hate server-side "helper" functions that generate HTML. For one thing it's never the same as what eventually gets shown on the page. 99.9% of the time you're missing attributes when needs to be hacked around. Debugging is a nightmare. Refactoring is hell. And css programmers have no clue what to do with this. Maybe I'm missing something here. Why not a templating engine?

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 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.

Re: FastHTML – Modern web applications in pure Python

#193

Post by 65 »

I looked through the examples and man is the code ever unreadable to me. If you're using HTMX why not just use Flask or Django and use much easier to read templating engines?

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.

Re: FastHTML – Modern web applications in pure Python

#194

Post by harel »

idf00 wrote: post #157
harel wrote: post #130

Earlier quoted context omitted.

I just don't see how a project beyond a small website can benefit from having it's front end generated in such a way. Once you grow beyond the "website" with simple interaction your front end becomes it's own universe. Coupling it all in the back end never ends well despite all good intentions. That has been my personal experience so far, so mileage varies etc. As an aside, HTML is formatted in a very visual way in m…

> 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 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.

Re: FastHTML – Modern web applications in pure Python

#197

Post by mixmastamyk »

harel wrote: post #130
mixmastamyk wrote: post #31

Earlier quoted context omitted.

1. These folks on such a project will otherwise need to deal with templates with Python in them. Inside out or outside in, there’s some complexity. 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…

I just don't see how a project beyond a small website can benefit from having it's front end generated in such a way. Once you grow beyond the "website" with simple interaction your front end becomes it's own universe. Coupling it all in the back end never ends well despite all good intentions. That has been my personal experience so far, so mileage varies etc. As an aside, HTML is formatted in a very visual way in m…

If you’re using backend templates it’s already coupled. The css as well. It’s a myth that separate langs in separate files == decoupled. I didn’t realize myself until recently—just got so used to it.

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.

Re: FastHTML – Modern web applications in pure Python

#198

Post by mixmastamyk »

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…

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.

Re: FastHTML – Modern web applications in pure Python

#200

Post by harel »

mixmastamyk wrote: post #198
harel wrote: post #194

Earlier quoted context omitted.

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…

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.

Post reply on HN