Hi Jeremy, congratulations for the launch.
How does this compare to Dash?
I've used Dash for many applications, so I'm wondering what are the advantages of FastHTML?
FastHTML – Modern web applications in pure Python
161–170 of 229 posts
Re: FastHTML – Modern web applications in pure Python
#162Frameworks like this are really next-gen, but I wish people would think in terms of the bigger Python ecosystem and not just their own framework. This is about the fifth web framework which are not compatible with each other: Streamlit, ReactPy, FastHTML, Dash, Shiny, etc.. 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 fra…
> Frameworks like this are really next-gen, 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 an…
Next gen in Python land. Nobody implemented a component framework properly yet.
Re: FastHTML – Modern web applications in pure Python
#163One thing I'm dying to see is a Python template engine that builds to WASM. This is the killer feature of C# for me right now. Blazor removes any need for me to ever touch React or JavaScript ever again. I think if done as a stand alone template engine, then every web framework could benefit from it, including this one. I just might have to research.
Might not be exactly what you're talking about, but Shiny for Python compiles to WASM, so that you can deploy stand-alone
Re: FastHTML – Modern web applications in pure Python
#164Looks neat! It seems at least superficially similar to https://github.com/getludic/ludic which I quite like too.
Re: FastHTML – Modern web applications in pure Python
#165Earlier quoted context omitted.
At the risk of being ignorant/heretical: Why use this over "raw" templating (e.g. jinja2) at this point?
My suggestion is to just try writing React for a week or two and experience the component based development. You never want to go back to templates again.
I love the idea of components. (been doing variations of it since 1999, starting with custom tags in ColdFusion) What I don't love is giving over to "full stack" development to gain the advantage of components (fortunately, there's options like server-side components, even when not using a JS-based framework, as well as partial-stack options like Inertia JS)
Re: FastHTML – Modern web applications in pure Python
#166OT: is there a reason to open/close the DocType at the beginning of the homepage source?
No. It's not in the spec, and in almost 30 years of web development, this might be the first time I've ever seen someone use a closing tag for it.
Re: FastHTML – Modern web applications in pure Python
#167It's you!
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.
Re: FastHTML – Modern web applications in pure Python
#168I have been looking for something like this for a while and am very excited to see this project.
I am currently settled on [ludic](https://getludic.dev) which is very similar to my eyes and has been discussed here [1]. The developer is responsive and the repo has a comparable number of stars to FastHTML on github.
Ludic's big feature is type-guided-components[2] that allow compile time checking of the compatibility of components forming a structure---and autocomplete while writing. So for example the component `WithSideBar` from the catalog[3] needs to contain a `SideBar` component and a list oof other child components. It seems elegantly put together too.
Looking forward to trying out FastHTML.
[1] https://news.ycombinator.com/item?id=39776199 [2] https://getludic.dev/docs/components [3] https://getludic.dev/catalog/layouts#sidebar
Re: FastHTML – Modern web applications in pure Python
#169Whoah, this comment section is surreal. People really aren't bothered by the propensity for runtime errors in python? How slow it is? That it has no good features for managing complexity in large codebasea? The fact that abstractions like these pretty much always break, or at some point you want to do something more outside of the box, and you have to put in a monumental effort? I'm working on a Django+graphQL app an…
Slow is if you need to download MBs worth of JS frameworks. I love that this is usable without JS if you want to. Also the abstractions around HTML seem to be very thin so I don't really get your pint there. GraphQL seems to be a performance killer too, so maybe just use simple, boring SQL?
You're the one starting about JS... I never said I liked JS either
Re: FastHTML – Modern web applications in pure Python
#170OT: is there a reason to open/close the DocType at the beginning of the homepage source?
No. It's not in the spec, and in almost 30 years of web development, this might be the first time I've ever seen someone use a closing tag for it.
It's also not a tag, but an SGML (?) directive (specifically a https://en.wikipedia.org/wiki/Document_type_definition) and so it is in fact invalid to produce a closing tag.