[HN Gopher] FastHTML - Modern web applications in pure Python
___________________________________________________________________
FastHTML - Modern web applications in pure Python
Author : bpierre
Score : 731 points
Date : 2024-07-29 22:18 UTC (1 days ago)
(HTM) web link (fastht.ml)
(TXT) w3m dump (fastht.ml)
| jph00 wrote:
| Hi all. Jeremy here -- I created this project. Thank you @bpierre
| for sharing it!
|
| 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.
| mloncode wrote:
| I am a python developer who has been envious of modern
| application dev frameworks & typescript, but never had the time
| to invest in another stack. This is so exciting. I suspect this
| might be catalyst that empowers more people to ship stuff
| nknealk wrote:
| Take a look at streamlit as well. It's got a few weird sharp
| edges but is really easy to pick up
| pydanny wrote:
| I like streamlit but found it if gets beyond a certain size
| it gets very hard to manage.
|
| Also, because FastHTML is powered by starlette, it handles
| async really well. That means web sockets have been a trivial
| implementation.
| kylerush wrote:
| Nice work! I think the Python community definitely needs
| something like this. The thought never occurred to me to use HTMX
| w/Python for both server rendered HTML and dynamic behavior in
| the browser.
|
| 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.
| jph00 wrote:
| 1. I don't think we mention conda afaict? We suggest pip since
| it's already available and works fine, and most people are
| familiar with it. uv works fine too, but we always like to show
| how to do things the way with the fewest steps and that the
| most people will already know about.
|
| 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
| kylerush wrote:
| 1. The conda recommendation is in the JS App Walkthrough
| documentation page:
|
| > 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!
| jph00 wrote:
| I possibly misunderstand your q3 -- if so apologies.
|
| 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.
| synparb wrote:
| I've added fasthtml (and its dependencies) to conda-
| forge, so it's available in conda/mamba now.
| zelcon wrote:
| The asyncio runtime should suspend while waiting for a LLM API
| response, not block
| jeanlucas wrote:
| Hey, just looking this quickly, the ideal case are for python
| developers that don't use Flask or Django? I'm a web developer
| for just 10 years, and I like seeing HTMX being applied, but I
| don't see why I should consider adopt it.
|
| Maybe I'm not the ideal user, but would like to know from you who
| do you think this is for.
| jph00 wrote:
| Flask or Django users should be able to get started pretty
| quickly with FastHTML, and users of the preview that have
| switched over tell us that they're finding it easier and faster
| to create what they want in FastHTML.
|
| 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._ "
| globalnode wrote:
| I'm a hobby programmer and would never use the existing web
| ecosystem to write anything -- seems unnecessarily
| complicated. If I have a task to do I'll get it done in C/C++
| or preferably Python. I do see the benefit of using the
| browser for cross platform UI under Python over say Tcl/Tk
| though, would this project be of help to someone like me that
| wants to keep it simple and just get something done for their
| own personal use?
| jph00 wrote:
| Yes it should be a great fit. If you give it a try, and
| have any issues, we have a Discord community that can help:
| https://discord.gg/qcXvcxMhdP
| hyuuu wrote:
| does this integrate with django?
| halfcat wrote:
| 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/
| jph00 wrote:
| 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 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.
| ptero wrote:
| Thank you! I'm another engineer who uses python (and C, Matlab
| and a few others) and whenever I want a web app I end up with
| some Rube Goldberg style contraption. Looking forward to trying
| your software.
| Yenrabbit wrote:
| I've been using this while it was in development and it's a
| pleasure to work with. Highlights for me:
|
| - 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.
| harel wrote:
| 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 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.
| jph00 wrote:
| Regarding (1), I think you might be misunderstanding how
| FastHTML works. If you want to write JS code in FastHTML, then
| you can just do that. But you can focus entirely on using it
| for the bits it works well for.
|
| 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.
| harel wrote:
| Regarding 2, I completely agree. A good existing project is
| no argument against new projects in the same space. It was
| more an observation (and very current experience of me
| reworking a fastapi project to Django+ninja because it simply
| grew in scope enough to merit it).
|
| 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.
| mixmastamyk wrote:
| 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 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.
| harel wrote:
| 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 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.
| pelme wrote:
| In our company, where htpy was born, we are building a
| highly interactive application with htpy combined with
| Alpine.js+htmx. We have a couple of thousands lines of htpy
| code in production right now. We stick all HTML generation
| code into components/x.py or components.py files to keep it
| separate from other code. It is easy to grasp the
| structure. We use type hints so it is clear what data
| different components expect. "Goto defintion" just works so
| it is easy to navigate the code.
|
| 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.
| idf00 wrote:
| > 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.
| harel wrote:
| 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.
| mixmastamyk wrote:
| 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.
| harel wrote:
| 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.
| mixmastamyk wrote:
| 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
| mixmastamyk wrote:
| 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.
| nprateem wrote:
| 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 works after
| coming back from your day job that uses a more mainstream
| framework.
| lyjackal wrote:
| I've been trying out fasthtml as a more scalable prototyping tool
| for a side project. I've really enjoyed using it! I tried gradio
| first, but 1. didn't like the look, and 2. You can't really go
| off the beaten path. So far I've really enjoyed working with fast
| HTML and htmx. Honestly my biggest complaint on working with
| "Python-only" dev has been the CSS. I wanted to give the app an
| easy, but unique/customized look. Most CSS libraries expect to be
| part of a JS based build pipeline for any type of customization.
| bootstrap still requires scss customizations, tailwind is its own
| thing of configuration, pre-processors and tree shaking. Really
| wish there was a robust css library that relied on css-variables
| to customize. There are a few but they're relatively anemic.
| Anyone know of any good options out there that would be a good
| fit, or did tailwind just eat everything up?
| jph00 wrote:
| This might sound kinda retro/boring, but I've been really
| enjoying Bootstrap v5 -- it's come a long way!
| https://about.fastht.ml/ is written with it. I've started
| creating a FastHTML wrapper for bootstrap here:
|
| https://github.com/AnswerDotAI/fh-bootstrap
| skeledrew wrote:
| This looks really nice. I'm just wondering how it would combine
| with Pyscript, which I've been watching for a good while now. As
| a primarily Python user wanting to do some web dev, I'd rather
| not touch JS/TS at all, beyond importing 3p packages.
| jph00 wrote:
| I doubt you'd need pyscript with this. Pyscript uses WASM in
| the browser, whereas FastHTML uses Python on the server
| directly -- the FastHTML approach avoids the need for your
| phone/laptop to download an entire python implementation just
| to use a web page!
| smrt wrote:
| Jeremy, this is awesome. I hope this catches on
| ianbutler wrote:
| I was talking with my cofounder today about how we'd likely need
| to become a multilingual platform once we eventually take on more
| than backend applications and I'm glad to see projects like this.
| They give me hope that we won't have to make that jump.
|
| 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.
| throwaway86586 wrote:
| Did you try Reflex.dev? Any opinions on it?
| jph00 wrote:
| Reflex converts the Python code into a react frontend and
| fastapi backend. It's an abstraction that hides much of the
| underlying foundation, which is a very differently philosophy
| to FastHTML -- which endeavors to make the underlying
| foundation directly available.
|
| 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!
| darkteflon wrote:
| Oh my goodness. I like to keep things boring where possible and
| swore I would never stray from Django + HTMX + Django Ninja, but
| I am exceedingly tempted to use this in an upcoming project.
| Lovely architectural choices - bravo!
| gkhartman wrote:
| It's a bit of a tangent, but do you have any go-to resources
| for learning how to use Django-ninja with HTMX? I haven't
| really put a lot of time into it, but HTMX seemed difficult to
| use with JSON APIs on first attempt.
|
| I'm only really familiar with Django and DRF, but if love to
| switch at some point.
| simonbarker87 wrote:
| Htmx isn't designed to work with JSON APIs at all. It needs
| HTML back from the server. You can detect when a request
| comes from htmx with a header it adds though so that allows
| you to return a different response if you want.
| jll29 wrote:
| While the design of it violates the separation of concern
| principle (keep data and code separate), I have to say this is
| most impressive, thanks for writing and sharing it.
|
| 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.
| langcss wrote:
| Can you explain how this doesn't keep data and code separate?
| Not sure what you mean.
| hopfenspergerj wrote:
| I'm looking at the very first example, and I'm a little confused.
| The function `home()` displays a list of messages, but they
| aren't passed into `home()`. Instead, `messages` is basically a
| global variable, and some other functions can append messages to
| it. Then I went looking at some more examples, and I see this
| pattern repeated. Is this how you're supposed to build webapps
| with this package? How does it isolate the list of messages for
| different users?
| Yenrabbit wrote:
| Which example? I see global vars in a couple of the demos. The
| game state for the Game of Life makes sense, since it is
| intended to be shared. The `messages` list in the Chatbot demo
| is definitely NOT how you'd build a multi-user application,
| that's mainly showing the styling aspect.
|
| 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.
| OutOfHere wrote:
| GitHub link to project: https://github.com/AnswerDotAI/fasthtml
| looop101 wrote:
| Not a very good "ad" as your page is quite slow and skips many
| frames, especially when scrolling past "The fastest way to create
| a real web application."
|
| "Fast"
| jph00 wrote:
| I'm not seeing that. What browser/device are you using?
|
| 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).
| looop101 wrote:
| Funny that you say "Visually complex" and "requires some
| baseline level of performance" when this same machine handles
| 3D games that are a thousand orders of magnitude more complex
| than your HTML displaying text and a few colours. What am I
| expecting though, that's the state of the web these days.
| Keep on creating more of the same rather than trying to fix
| this brainrot foundation you're building on.
| durraniu wrote:
| This looks really cool. I have experience with shiny apps in R,
| and Python has a shiny package too now. FastHTML looks a lot like
| Python shiny without routes. I think both of these frameworks are
| great for people with no web dev experience. It would be great if
| there is some discussion of htmx and why it is used in the
| tutorials section of FastHTML docs.
| jph00 wrote:
| Shiny and FastHTML are both built on top of Starlette, so both
| use the same routing implementation. FastHTML by default uses a
| `RouteX` subclass that adds quite a bit of functionality to
| Starlette routes (mainly around automatically passing in the
| needed parameters for a handler).
|
| There's quite a bit of background of why HTMX is used,
| particularly these two sections of about.fastht.ml:
|
| - https://about.fastht.ml/foundation#sec2
|
| - https://about.fastht.ml/tech#sec2
| wodenokoto wrote:
| How does this compare to streamlit?
| ultrasounder wrote:
| Came here to post this but HN hivemind beat me to it. Can't
| stress this enough. This Coupled with generative AI for code
| generation will make the barrier to entry sure low. Time to
| migrate my bootstrapped Flask/JINJA2 templates
| website(www.voxtodo.com) to this shiny new.
| pzo wrote:
| Look very nice, I love simplicity. Wondering how it would scale
| in real life - game of pi example feels slow.
|
| 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?
| jph00 wrote:
| The home page was running on a $5/month hobby account at launch
| today and reached 1% use of 1 VCPU -- so speed seems pretty
| good to me! Having said that, not all the example apps are well
| optimised, since we're aiming largely to teach the basics.
|
| 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.
| crimsoneer wrote:
| Honestly, Jeremy and the Fast.ai team really deserve some kind of
| award/medal of honour/general sainthood at this point.
| kissgyorgy wrote:
| Frameworks 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 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
| inbetween wrote:
| That looks super interesting, congratulations. I would suggest
| you do write lots of documentation, a more elaborate readme on
| github and generally push your approach. As it stands, the repo
| looks somewhat unfinished and inactive, unlikely to make people
| spend their time and energy digging into it. I hope you drive
| it forward!
| kissgyorgy wrote:
| You are totally right, but I'm not actively working on it,
| because core (the base library) is basically ready and I'm
| working on a project in production which is exclusively using
| it [1]. The site is using htmx, feels snappy overall and I'm
| even generating static parts with it (e.g. the home page).
|
| [1]: https://findendurancecoach.com/
| bruh2 wrote:
| This sounds exactly like what I was looking for. I settled on
| htbuilder[1], but it certainly does not feel right as it
| requires a fair bit of wrangling in order to fit with Django.
|
| I'd love to help you with documentation and such; hit me up at
| smart.tent1246@fastmail.com 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.
| 0x3444ac53 wrote:
| Looking over your examples makes me think of sxml
|
| https://en.wikipedia.org/wiki/SXML
| port19 wrote:
| At the risk of being ignorant/heretical: Why use this over
| "raw" templating (e.g. jinja2) at this point?
| murkt wrote:
| I've switched back to writing server-based code from writing
| React SPA. Text-based templates (I use jinja2) is my least
| favorite part of that.
|
| 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.
| kissgyorgy wrote:
| 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.
| BiteCode_dev wrote:
| I've been writing react for years, and going back to
| templates, I wish I could never have to write a react
| rendering function again.
|
| 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.
| bdcravens wrote:
| 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)
| barrenko wrote:
| But I cant use this instead of jinja?
| murkt wrote:
| yes you can
| barrenko wrote:
| Thank you. Death to jinja!
| shakna wrote:
| Most Python web apps implement WSGI, and so can absolutely be
| used together. Just mount them on top of each other. Wanna use
| both Flask 'n Django? Go for it! Unfortunately, that's the
| backend story.
|
| On the frontend, things are a little less consistent.
| murkt wrote:
| This is fantastic and exactly what I wanted! A very neat idea
| about how you separate attributes and children.
|
| How does the performance side of this thing look like?
| kissgyorgy wrote:
| I did not measure performance yet, but I definitely will! My
| hunch is that it's faster than any templating library,
| because those are compiling from their own DSL, but it's
| completely ommitted here.
| BiteCode_dev wrote:
| That's why I like django-ninja: it's django with fastapi like
| features.
|
| But it's fully django compact.
| lelanthran wrote:
| > 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 any of the examples in any current framework, including
| this one.
|
| I find it hard to get impressed these days.
| kissgyorgy wrote:
| Next gen in Python land. Nobody implemented a component
| framework properly yet.
| magnio wrote:
| Thank you for saying this. Having to dabble with streamlit at
| work, I am very disappointed in those kind of solutions, where
| the moment you venture off the happy path, you are on your own.
| Any kind of integration or extension needs you to be aware of
| streamlit's internals. For example, there is no built-in way to
| open a folder picker AFAIK.
| daelon wrote:
| Streamlit is fine for the first 20 minutes and then it sucks.
| I switched to NiceGUI and couldn't have been happier for my
| internal crud app with very specific ui/interactivity
| requirements.
| kolanos wrote:
| Another Python framework agnostic project is ReactPy. [0]
|
| [0]: https://github.com/reactive-python/reactpy
| Nathanael_M wrote:
| Weirdly topical. Currently investigating Django as a backend for
| product redevelopment. I'd like to avoid a fully separate
| frontend app, because frankly it's overkill. I was thinking of
| HTMX, Alpine, and cobbling together some component-esque template
| organization. I'll check this out!
| langcss wrote:
| Are there any UI libraries developed for this? Or other ecosystem
| stuff.
| jph00 wrote:
| It was just launched today so the ecosystem is just what we've
| built so far. I've create initial starting points for UI libs
| for boostrap and flowbite, and we have examples showing how to
| use daisyUI.
| vikaspooddar001 wrote:
| Hey fastHTML team, congratulations on first public release of
| fastHTML. I just want to point out fastHTML, fastAI and fastAPI
| can bering together to form a python stack for training,
| deploying ml application python native fashion. The stack will
| known as faststack
| sadlion wrote:
| I wasn't expecting to see Jeremy when I opened the link. I'm a
| long time fan of his work and have been recently playing with
| Claudette. Claudette is written using a Jupyter notebook in a
| literate programming style. Seeing Jeremy deconstruct problems
| and build solutions from first principles is always amazing. I
| have experience with multiple JS frameworks and I am excited to
| try fasthtml. Thank you Jeremy for all your contributions.
| ironfootnz wrote:
| I think this is a very useful framework to write about on
| Wikipedia on how not to use HTML in your python code. There's a
| canonical reason on why we shouldn't.
|
| Readability, reusability ... the list goes on.
| btreecat wrote:
| I'm not sure I understand your perspective, we've been using
| HTML + template library for a while with great success as an
| industry, across multiple languages.
|
| From what I understand is this adds JS bindings.
| EternalFury wrote:
| Python is fast compared to something? Maybe fast enough to
| generate HTML.
| benatkin wrote:
| Not just fast, but webscale. Also fast to develop.
|
| https://youtu.be/b2F-DItXtZs?si=r6vGxl22gXkXO1Y7
| jph00 wrote:
| Fast enough for YouTube, Instagram, and Dropbox. If you need to
| scale up bigger than that then maybe reach for something else I
| guess.
|
| 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.)
| curioussavage wrote:
| YouTube instagram and Dropbox definitely don't scale thanks
| to python. They scale thanks to the massive infrastructure
| they built around some python code. Cdn caches etc. we all
| know this. And they could probably save money by migrating to
| a more performant and safe language. But they have money
| firehoses and household brand recognition so they don't care.
| nl wrote:
| > Cdn caches etc. we all know this.
|
| No matter what language you use, you use CDNs and caches.
| benatkin wrote:
| They could partly run Python, in which case it would be a
| better example of FastHTML scaling in this way. Some CDNs
| have Python edge functons: https://developers.cloudflare.
| com/workers/languages/python/
| https://aws.amazon.com/developer/application-security-
| perfor...
|
| With Vercel and Netlify it's just TypeScript/JavaScript:
| https://vercel.com/docs/functions/edge-middleware
| https://docs.netlify.com/edge-functions/overview/
| idf00 wrote:
| > YouTube instagram and Dropbox definitely don't scale
| thanks to python
|
| But python doesn't prevent them from scaling either ;)
| 0xedd wrote:
| ROI is more important than silly benchmarks.
|
| https://www.tiobe.com/tiobe-index/
|
| But, we can play the benchmark game, if that tops your morning
| cereal.
|
| Competes with Go. Blows most popular TS frameworks out of the
| water.
|
| https://www.techempower.com/benchmarks/#section=data-r22&hw=...
|
| For you: https://gprivate.com/6chku
| Shorel wrote:
| That benchmark makes Go look good, and JS very good. The
| upper part of the table belongs to Go, and the very top is
| JS.
|
| The bottom of the benchmark table are all slow Python
| implementations xD
| Shorel wrote:
| Python is glue, used to call and integrate other faster
| languages. Most of what is done with Python is calling fast C
| and C++ code.
|
| 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.
| EternalFury wrote:
| I never expected this quick jab to trigger such reactions.
|
| 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.
| awahab92 wrote:
| fast enough for a million users on a $4 budget.
|
| When you get to 1% of the world population, you can switch to
| rust/go
| sweca wrote:
| Fantastic design!
| polyrand wrote:
| Very cool! After trying different approaches to render HTML from
| Python objects (including lxml, xml, etc.) I ended up liking
| htpy[0] the most, and the apps I built look similar to the
| examples in the FastHTML docs. I'll definitely try it.
|
| 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"))
|
| Then `self.header()` can be reused in other parts, or to return
| partial HTML. It also makes it easy to pass the "request" object
| to the class, and do conditional rendering based on it (cookies,
| auth, language, etc).
|
| [0]: https://htpy.dev/
| jph00 wrote:
| Yes htpy is nice! Other interesting examples of functional HTML
| include Elm-html (Elm), hiccl (Common Lisp), hiccup (Clojure),
| Falco.Markup (F#), Lucid (Haskell), and dream-html (OCaml).
| FastHTML's system, called "FastTag" (FT) is a bit of a mashup
| of all of them plus some extra bits. I seriously considered
| just using htpy actually -- but in the end decided I preferred
| something a little different.
|
| 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...
| pelme wrote:
| Thanks for making FastHTML, it is great to see more Python
| tooling that embraces Python for generating HTML.
|
| What made you build FastTag instead of going with htpy? I am
| the author of htpy and any feedback would be very welcome!
| jph00 wrote:
| I wrote a few things with each of FT and htpy, and looked
| at the resulting code -- I felt like the htpy approach was
| slightly less neat personally. htpy has the benefit that
| '.' and '#' can have special meanings, but the downside of
| needing to use both __getitem__ and __call__. I didn't feel
| like that was a tradeoff I wanted to make. I actually
| originally wrote FT for a different purpose (XML for
| language model input) so id and class attributes weren't of
| any interest at all at that time!
|
| 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
| pelme wrote:
| Thanks, that makes sense! :)
| polyrand wrote:
| For what it's worth. One thing I really like about `htpy`
| is that the element attributes go before the child
| elements. I find this easier to write and read. Other
| things I like:
|
| 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...
| CodeCompost wrote:
| 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?
| jph00 wrote:
| 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 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.
| CodeCompost wrote:
| I disagree. But ... I am somebody who listens and am able to
| change my mind. I'll experiment with this.
| mrweasel wrote:
| > - 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.
| vaylian wrote:
| > Maybe I'm missing something here.
|
| 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.
| slightwinder wrote:
| > Why not a templating engine?
|
| 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.
| chompychop wrote:
| One check I always like to do with a new Python-based framework
| is this - does it support the creation of a dynamic number of
| components at runtime, AND each having their own component state?
| Most frameworks I've tried support one or the other, but not
| both. Is there an example that demonstrates something like this
| in FastHTML - user provides a number n at runtime, n cards are
| generated, each card has its own text field which can be modified
| by the user without affecting the other cards' text fields.
| jph00 wrote:
| Yes lots! The "idiomatic" todo app is a nice simple example:
| https://github.com/AnswerDotAI/fasthtml/blob/main/examples/a...
| amai wrote:
| What is the advantage over e.g. https://streamlit.io/ ?
| odie5533 wrote:
| Streamlit is for small, interactive, data-driven applets.
| FastHTML is for building entire websites with direct control
| over the HTML output.
| jwmoz wrote:
| This is not the way to do html with python.
| isoprophlex wrote:
| That's like, your opinion, dude.
|
| Maybe expand a bit on why it's not? Otherwise this is a useless
| troll comment.
| mtxlan wrote:
| You can do HTML even with exel;)
|
| Python just parsing data and injecting it back. That all up to
| you
| vaylian wrote:
| This looks really impressive. What is the idiomatic way to test
| webapps created with FastHTML?
| jph00 wrote:
| We've been using Starlette's testclient, which works really
| well.
| jaehong747 wrote:
| FastHTML is an impressive and innovative idea. It seems like a
| web development tool similar to Streamlit, but with more precise
| control.
|
| 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]
| truth_seeker wrote:
| will it compatible with pypy now or in future to speed it up ?
| rasmus1610 wrote:
| We have 75 comments and no one has mentioned the awesome domain
| name? c'mon :D
|
| really excited for this project. I hope it catches on. It has
| some really nice ideas in it, like all the stuff jeremy does!
| goosejuice wrote:
| I'm not sure if I'm alone in this, but I feel domains like this
| are a bit user hostile. It's cute but harder to commit to
| memory and it reads like fastht dot ml
| trvz wrote:
| Fast Hyper-Threaded Machine Learning
| jph00 wrote:
| After creating fastmail.fm in 1999, and then fast.ai, this felt
| like the right name and domain to me! :D
| throwaway89988 wrote:
| Hi Jeremy, congratulations for the launch and the website looks
| very nice indeed.
|
| 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?
| jph00 wrote:
| 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 HTML templating is a historical accident for what it's
| worth, and I hope it dies.)
| throwaway89988 wrote:
| Thank you very much for insights and elaboration!
|
| 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. ;-)
| jph00 wrote:
| FastTags (FT) are a 1:1 mapping to HTML. It takes ~5 mins
| to learn. There's no transformation other than that the
| function name is the tag, the positional args are children,
| and the kwargs are attributes. (Oh and we have to rename
| `for` and `class` since they're reserved words.)
|
| 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.
| vaylian wrote:
| > (I think HTML templating is a historical accident for what
| it's worth, and I hope it dies.)
|
| It might be worth writing a blog post about that. It sounds
| like you have some more interesting things to say about the
| topic.
| pydanny wrote:
| My impression having done Django for over 15 years is that
| FastHTML allows for separation of concerns, albeit not within
| templates. Rather, most of the "presentation layer" is executed
| during the return statement. A common pattern in people
| building non-tiny FastHTML projects is to break out
| presentation into a components layer and business logic into a
| business layer.
|
| 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. :-)
| bruce343434 wrote:
| Whoah, 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 and I'm basically considering
| buying a farm at this point. Python is really not the right
| language.
| mkesper wrote:
| 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?
| jillesvangurp wrote:
| Downloading that all that stuff is a one time thing if you
| are developing. And most js dependencies are actually
| developer tools. The runtime dependencies of a webapp tend to
| be pretty minimal actually. Also, python has lots of
| dependencies typically.
|
| 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.
| bruce343434 wrote:
| You're the one starting about JS... I never said I liked JS
| either
| mronetwo wrote:
| Yeah I also don't get it. Python is great and I really like it,
| but it never feels like a good choice for an app that runs 24/7
| for years to come. So many wasted CPU cycles.
| sk11001 wrote:
| 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.
| bruce343434 wrote:
| 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. 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.
| sk11001 wrote:
| 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.
| pacha-- wrote:
| I've seen good Python projects and bad Python projects. Not all
| errors are caught at compile time and performance may or may
| not matter in non-cpu bound workloads. There's no "right"
| language. Python can shine in the right context (including web
| applications).
| awahab92 wrote:
| The only two langauges that have better error handling are
| golang and rust.
|
| but not having to context switch from python to another
| language is worth it for 95% of applications.
| timkofu wrote:
| There has been funding in recent years to fix the quirks and
| improve performance. The Faster CPython project has had good
| outcomes towards achieving these goals.
|
| 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.
| asdfkl wrote:
| Threads that slow down single thread performance by 50-100%.
| The "faster CPython" figures are just marketing as well.
|
| Whenever I run some benchmark myself, I do not see any
| improvements over Python 3.7 and the horrible numbers for the
| threaded build.
| pzo wrote:
| I'm wondering whats the state of GraalPy - seems it support
| many of pip extensions. https://github.com/oracle/graalpython
| asdfkl wrote:
| Yes, I think people are polite and give the new framework a
| chance. Anything that is not Django is of course appreciated.
|
| 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.
| hum3hum3 wrote:
| I have used and liked FastHTML although I was going in a
| different direction (not very modern and no javascript)
| https://github.com/drummonds/lofigui. It works well.
| BerislavLopac wrote:
| I'm personally always confused with those batteries-included
| frameworks like Django, FastAPI and similar. Sure, they might be
| easier for a beginner to quickly whip up a simple Web site/app,
| but in my experience as your requirements grow they quickly start
| getting in your way.
|
| 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.
| simplecto wrote:
| Django is like a marriage. You have to commit fully to get the
| most out of it. You have to work through the (perceived)
| suboptimal parts to find a compromise that such that the whole
| system does not fall down.
|
| 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
| shawnz wrote:
| Is FastAPI really "batteries included"? I would say that it's
| orders of magnitude lighter than Django
| JPKab wrote:
| So I don't disagree with your general premise, but FastAPI
| isn't in the same ballpark or even universe with Django. Yes,
| it's heavier than Starlette, but it's an extremely light
| framework, and was really intended to be a successor to
| microframeworks like Flask.
| 098799 wrote:
| Yikes. I'm going to follow this one cause it's right up my alley,
| but I'm worried I will absolutely hate the process if some
| standards don't change, e.g. having to have multiple functions
| called "get()" for them to be a GET request is going to drive
| mypy/flake8 mad.
| jph00 wrote:
| 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.
| 098799 wrote:
| 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.
| openrisk wrote:
| What would be cool++ (and potentially very impactful) is if
| somebody builds a python/htmx native "wordpress" on top of this.
| The Python ecosystem offers django/wagtail and some other CMS
| like options but imho they have not (yet?) taped into the vast
| potential of the Python ecosystem once the algorithmic / data
| science part is natively integrated with cms type web apps.
|
| The .ml domain extension may be exactly the placeholder needed
| :-)
| pokipoke wrote:
| I haven't seen such bad Python code (fasthtml repo) for a long
| time. It feels like its written in 2008 using Python2
| dsissitka wrote:
| It doesn't look like they use a formatter or linter. I hope I'm
| wrong but I feel like that and their use of nbdev are really
| going to hurt adoption. :(
| crabbone wrote:
| I started grasping for air once I saw hand-parsing data coming
| from configuration file _written by the same authors!_
|
| 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.
| ostwilkens wrote:
| "What's the FastAPI of frontend?" - A tweet I wrote 2022 I'll
| give this a go for my next project!
| cynicalsecurity wrote:
| People do all kinds of crazy useless things just in order not to
| do it the proper way in PHP.
| ibz wrote:
| While I've been a PHP hater most of my life, as I get older I
| start appreciating its simplicity. I still think it's a
| terrible language, but I would not be surprised if it went
| through a revival period simply because everything else has so
| much more unneeded complexity.
| lkambnr wrote:
| I am really interested in the comparison of PHP vs. the
| hundreds of templating engines used in other languages.
|
| 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.
| yashbindal wrote:
| This is so cool
| fraugdib wrote:
| Dude - Fastmail was the shit back in the day
| bapetel wrote:
| Python to Python HTML to HTML JS to JS CSS to CSS
|
| That's it, no more complexity
| MemphisTrain wrote:
| I have no interest on magical sugary functions that make
| something quick. The modern reactive concept doesn't impress me.
| What I want is a very well thought-out set of tools that allow me
| to do anything and everything, because I will be refactoring and
| fine-tuning my functions a lot, and I will do it my own way, I
| don't need some automatic shortcut which is not going to help me
| if I can't modify its full functionality. (I don't mind
| decorators if they make sense)
|
| 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.
| lofaszvanitt wrote:
| This is the future, right after React.
| pietz wrote:
| This looks cool and I will check it out but I'm also quite happy
| with my tech stack.
|
| 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.
| giancarlostoro wrote:
| One 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.
| randyzwitch wrote:
| Might not be exactly what you're talking about, but Shiny for
| Python compiles to WASM, so that you can deploy stand-alone
|
| https://shiny.posit.co/py/docs/shinylive.html
| giancarlostoro wrote:
| I'm specifically talking about say jinja2 rendering to WASM
| and doing any sort of application logic client side like
| Blazor does. Blazor can also do server-side logic. It's
| essentially a SPA framework on serious steroids with minimal
| mental overhead of having to go to JavaScript and back.
| tiffanyh wrote:
| <!doctype html> </!doctype>
|
| OT: is there a reason to open/close the DocType at the beginning
| of the homepage source?
| bdcravens wrote:
| 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.
| svieira wrote:
| 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.
| vdfs wrote:
| https://stackoverflow.com/q/23005510/3896300
| electroly wrote:
| HTML5's HTML syntax is no longer SGML-based. It's still
| invalid but no longer because of anything related to SGML;
| now it's simply because the HTML5 spec says so.
| ammar_x wrote:
| 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?
| nurbl wrote:
| Looks neat! It seems at least superficially similar to
| https://github.com/getludic/ludic which I quite like too.
| 2wrist wrote:
| It'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.
| bartron wrote:
| I 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
| DonnyV wrote:
| Python isn't really known for its speed. The syntax seems like a
| nightmare. Very magic syntax like Ruby on Rails. I feel bad for
| the person that will need to maintain this in 5 years when its
| grown to large.
| bbminner wrote:
| I have been reading about these kinds of projects for some time,
| and even prototyped my own a while back, but one question that
| keeps popping up is - all these python abstractions over how html
| and js and dom interact tend to be extremely leaky. So, as soon
| as you go beyond the simple todo example, you need to manage BOTH
| the standard browser model and the abstraction model in your
| head, and all the funny ways in which they interact. Do these
| kinds of libraries prove useful for people beyond their authors
| (who have a good mental model of a framework in their head anyway
| because they are developing it)?
| ionrock wrote:
| This kind of framework helps to optimize a bit for returning
| hypertext (iow HTML snippets) rather than leveraging a frontend
| system that only interfaces with the backend via an API. From
| that perspective, you need to be able to send HTML snippets
| precisely and manage more URLs that provide the snippets. React
| already has a pretty strong abstraction around HTML with JSX
| that has been generally morphed into web components. Writing
| the HTML components on the server using a library that
| maintains valid HTML is convenient, and it also means you can
| deploy an application without having to bundle a bunch of
| template files.
|
| 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.
| leke wrote:
| This looks like a lot of fun, but I wouldn't probably have any
| need for it. I currently find an AI prompt in the code editor,
| along with AI code completion, a fantastic way to rapidly code.
| Mixing Latte template files with a minimal framework like Flight
| PHP, and HTMX makes me just as productive. I guess python devs
| would be more appreciative though.
| 65 wrote:
| 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.
| nothrowaways wrote:
| Cool domain, fastHT.ML
| Iacjr wrote:
| IS It work in termux?
| Art9681 wrote:
| I love everything about this. I have been using HTMX heavily for
| a side project and glad to see it used in this project. Is
| fast.ai hiring? I would love to make contributions to their
| mission.
| iamcreasy wrote:
| This looks very interesting.
|
| 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?
___________________________________________________________________
(page generated 2024-07-30 23:01 UTC)