As we mentioned Flet here - it's been able to build web apps running completely in the web browser (Flutter + Pyodide). Here are a few examples: https://flet.dev/gallery - most of those apps there are client-side except "Controls gallery" and "Chat" which are server-side.
Flet (https://flet.dev) might be easier for backend devs as it doesn't assume any web experience at all. You use controls (aka widgets) with events (not request/response) and can build not only web, but desktop and mobile apps - all with a single codebase. Disclaimer: I'm Flet developer.
It looks like Flet is for client-side code. It lets you write Flutter apps with Python instead of Dart.
> Simple Architecture - No more complex architecture with JavaScript frontend, REST API backend, database, cache, etc. With Flet you just write a monolith stateful app in Python only and get multi-user, realtime Single-Page Application (SPA). -- https://flet.dev
If I'm writing Python that runs on the mobile device, it must talk to a server to read & write data. Doesn't this still require an API backend, database, cache, etc?
For web you can package Flet app to client-side (with pyodide, all Python logic runs in the browser, see an example here: https://gallery.flet.dev/todo/) and run as a server-side app (or server-driven) with Python logic running on the server (example: https://flet-controls-gallery.fly.dev/layout - notice faster loading compared to client-side one).
> If I'm writing Python that runs on the mobile device, it must talk to a server to read & write data. Doesn't this still require an API backend, database, cache, etc?
That's correct. Any backend service which provides Python API can be used when running Flet app on a mobile: FastAPI, Firebase, Supabase, Pocketbase, etc, but you use Python to call that which is awesome especially for beginner and non-web developers.
I discovered Flet via HN a few months ago, and it has been really fun to play with (although it's a bit tricky to figure out the right path to make updates happen to nested controls).
Thanks for your work on it, and (shameless nudge!) I'm really looking forward to iOS camera access, and easy iOS deployment!
Unfortunately Flutter (which seems to be the backend for Flet), is IIRC rendered in a HTML5 canvas, which yields bad accessibility and is overall a pretty bad way to build web apps.
It's kind of unbalanced, as web tech, on the other hand, is pretty good at building desktop apps.
SEO - maybe, but IFAIK accessibility in Flutter web app shouldn't be an issue (I just saw this comment from someone on Flutter team: https://news.ycombinator.com/item?id=24922849). They've been recently doing a great job in terms of performance (compiling app to WebAssembly) and size. I agree that Flutter web is not good for building websites, but for web apps, especially those "internal" apps used by a small group of users, it's a pretty decent solution.
Flet (https://flet.dev) is a new GUI library for Python to write apps like that. It uses Flutter to render UI with a modern-looking Material design. Your app can be run as a desktop app and published as a web app (standalone with Pyodide or server-driven with built-in web server).
Hey, this is exactly how https://flet.dev works! :) There's a UI server written in Go, you write your program in Python which manipulates a virtual DOM with commands via WebSockets, and there's a Flutter client that renders UI from that DOM: https://flet.dev/blog#current-flet-architecture
I'd love to add other languages, but currently so busy with a top-notch Python support!
Congrats on the launch! Great project and nice execution!
Very similar to what we do on Flet: https://flet.dev
The major difference is that Flet uses Flutter to build UI and can target desktop, web and mobile. Also, we use WebSockets for communicating with the server which gives lower latency (the delay between a click on a button here https://pynecone.io/docs/getting-started/introduction and UI update could be annoying).
Thanks yeah we really like your project as well. We chose the react/nextjs ecosystem because we found it to be more developed and widely use than flutter. Which gives us benefits to be able to wrap more libraries either in our pynecone framework or make a third party component library.
We thought about adding web socket and are still debating. The latency here is not from our framework though its from our server getting slammed with hacker news and reddit from our launch lol. We found the overhead of sockets not worth to for the majority of our apps.
> The latency here is not from our framework though its from our server getting slammed with hacker news and reddit from our launch lol.
Seems like this could be a major barrier to scaling, especially if /all/ reactive state has to be handled through the server. Maybe a future feature could be a WebState class that provides reactivity only on the front end?
It took me a while to re-find a "Python web app" project that has been posted here and that I vaguely remembered. So I am gonna post it here. It's Pglet https://github.com/pglet/pglet and Flet seems to be its spiritual successor.
In the beginning, for mobile it's going to be a websocket to a Python server - kind of server-driven UI (SDUI) approach. Then we'll look into packaging everything into a standalone mobile app: https://flet.dev/blog/flet-mobile-strategy
For desktop using WebSockets within localhost doesn't really add a noticable overhead.
Flet! :) Creator of Flet is here. Could you fix the title please? I've been told that there is a discussion about Flet on HN, tried searching by "Flet", found only an old thread and thought "oh, well, OK then - must be a mistake".
