that it is fully featured either directly or by easy integration with another framework that is fully featured. This requirements is in place so that people don’t get burned with a shiny short-term solution that cannot scale out to evolving requirements. Streamlit, Gradio and others are great for single-user web apps, but they do not provide a path for evolution into full-blown industrial strength web applications. In short: unless a product can directly, or with easy integration do everything in Miguel Grinberg’s Flask Mega-tutorial it is not fully featured.
well-maintained – anything with no source code updates in more than 1 year cannot be considered well-maintained. If there are serious outstanding issues and pull requests this also factors in.
well-documented – Ideally all major forms of documentation exist – FAQ, tutorial, Guide and Reference.
Good support channels – rapid accurate response to community questions is a must.
(New soft criteria) It must scale to handle 1 million requests per second or more. Cute little toy apps running on your personal Macbook pro are nice, but the world’s top 100 web properties have much higher demands for seamlessly handling large amounts of traffic. If the web solution cannot produce a site like amazon.com and handle the web traffic like amazon.com then it might be OK for building a toy app for your local barber, but it will never survive at the top level in demanding industrial situations.
Panel clearly fails on 5 unless you have very deep pockets.
But I would like to challenge you For me this does not mean its a toy app. Its just not not a public many users facing web app. In trading environments Panel is used to handle billions of dollars. At CERN and other scientific institutions its used to drive very important science. At the worlds biggest military institutions its used to provide key insights.
Regarding 2.-4. it clearly passes.
Regarding 1. I would say it passes most things. Then one thing I don’t think it passes is the I18n and L10n support. There is no built in support for this. But of course you can do everything - its just python. I’ve never seen a request to support this though.
Please note that you can use Panel as a part of your favorite web framework. For example Flask, Django and FastAPI
@metaperl , I’d very much agree with Marc’s point about the 1 million requests use case. Panel is built on Tornado/WebSockets, which means that it is excellent at real time syncing between server and client. That’s actually an extremely useful feature for a commercial SaaS application, but for a specific use case. It would not be a practical way to build a site like Amazon.
… also, I know a bunch of people at Blackstone. They are VERY careful about how they invest money. “A toy app for your local barber” would certainly not meet their criteria.
yes, and actually point number 5 is not really about the web framework. To handle a large number of requests is more about hardware, networking, caching, read-only-pre-queried-denormalized data stores, etc.
As long as the pure python web framework is not blocking the way of moving towards scalable app development, then it is not an issue.
But take PyScript and Pyodide, for instance. There needs to be a way to make such sites performant and on-par with other solutions…
so Marc, what do you think about point number 5? trash it? ease up on it? revise it?
By the way, i see no reason after this discussion not to promote Panel to class A given the heavy duty use cases once we make point number 5 more reasonable AND ALSO NOTE: point number 5 is a soft requirement, not hard requirement.
For me this does not mean its a toy app. Its just not not a public many users facing web app. In trading environments Panel is used to handle billions of dollars. At CERN and other scientific institutions its used to drive very important science. At the worlds biggest military institutions its used to provide key insights.