Disregarding all of the negative sentiment and claims of this repeating old work, I must say the source code is very fun to go through. The code is well-structured, integrates many awesome technologies and provides a foundation to build on. The project is the clearly the result of a high caliber level of craftsmanship and labor of love, great work Will Chen (wwwillchen) and others!
This tool fills a very narrow use case for demos of AI chat.
If you know Python and can run inference models on a colab then you can quickly whip up a demo UI with builtin components like chat with text and images. Arguably everyone is testing these apps so making them easy is cool for demo and prototyping.
What other use cases is this tool insufficient for?
BentoML already wins at model hosting in Python IMHO.
What limits this to demos?
IIRC there are a few ways to do ~ipywidgets with react patterns in notebooks, and then it's necessary to host notebooks for users with no online kernel, one kernel for all users (not safe), or a container/vm per user (Voila, JupyterHub, BinderHub, jupyter-repo2docker), or you can build a WASM app and host it statically (repo2jupyterlite,) so that users run their own code in their own browser.
xoogler/ML researcher here. Everyone at Google used colab because the bazel build process is like 1-2 minutes and even just firing up a fully bazel-built script usually takes several seconds. Frontend is also near impossible to get started with if you aren't in a large established team. Colab is the best solution to a self-inflicted problem, and colab widgets are super popular internally for building hacky apps. This library makes perfect sense in this context...
It's funny how much negativity was/is around things like NodeJs when so many back end engineers railed against frontend folks for only wanting to use JS and not adapting "proper" languages when they always go and try to go out of there way to do the same thing in reverse.
I'm struggling to understand this demo app. You type in some text and it echoes the exact same text back to you? I assume the project just hasn't fully fleshed out the readme
I'm noting the use of "stream" and that the upper_case function is a generator (see the `yield` keyword) which I take to mean any asynchronous process could be placed there. e.g. a call to a chatbot api.
The issue that stands out to me with this is its not using coroutines. Python developers who don't know everything about the GIL, threading, blocking v non-blocking sockets, processes, all of that can of worms, are going to try regular blocking I/O (that they might have done fine in PHP) leading to horrible performance. I think the choice to do this with 'threads' in Python (not real threads) = very bad. I think you can have multiple processes here but if you're using just Python for the web server the overhead is going to be massive for an interpreter...
The correct approach would have been to have an event loop in every process handling 1 - however many clients for the server. Then async I/O functions can be done inside the app routes without potentially impacting the performance of every other client being processed. The software here seems to use Flask for the underlying server stuff (when running from Python.) But anyone whose tried to use flask for a web project before knows that its slow AF since it loads everything one after the other. When looking that up I think you can tweak the number of processes it uses but IMO: it's not the right approach.
as usual, the hacker news subset consisting of the echo chamber / hive mind / tech bosses' slave crowd, can't digest / handle comments like mine above, while at the same are fine with the comment in a similar vein by paulcole, to whom I just replied above.
long live discrimination on hacker news! hip! hip! horror!
For some clarity on the support here: at Google it’s very easy to publish arbitrary code on the Google GitHub, and a bit of a pain to get permission to publish (new) projects on your personal GitHub. It’s also not too tricky to take a project with you (i.e. transfer ownership) if you leave. For these reasons, many googlers just publish their hobby projects on GitHub under the Google org. That’s most likely what this is, the support disclaimer is the big giveaway.
I believe many of the repos in the @google GitHub org are people's personal projects (and hence not officially staffed/supported, as disclaimed). In the linked Show HN, the authors confirm it's a 20% side project.
some of them; others are internal tools used at google that the company is happy to let the devs open source, but which are not official google "products". my main project when I was at google was in that category: https://github.com/google/pytype - it was not an "official google product" in that google was not officially supporting it for external users, but it's an extensively used product within google and developing it was my full time job.
Generally interested in this kind of thing, but the documentation seems broken so I can't tell why I’d use this instead of NiceGUI or any of the other Web-GUI-in-Python libraries/frameworks.
I'm thinking of bringing back Basic but with a twist. Hear me out. You'd have a forms package built in. It would be a visual approach for programming business apps. Haven't come up with a clever name for it yet.
What about "Visual <something>"? Since, you know, it's visual.
This idea sounds promising. Who knows... you might even get one of the tech giants interested! Some of them have a lot of business customers that could use something like this.
Don't you think that would be going too far? I worry what unholy creations people might come up with... A tabular data tool with a full development environment might just be too much power concentrated in a single application.
I have quite a few ideas for web sites or web apps but JavaScript syntax and HTML/CSS web modelling is turning me off so I wonder would this be feasible for simple experimental web app/s? I also explored Golang which also has easy to pick up syntax as Python and it is also easy to build web apps with it so I kinda dunno where to start.
IMO it's better long-term for an individual to just learn Next.js, React, Tailwind.css (my preference), and TypeScript. You will be a better developer than using something like this.
Those sound like tools used to build a production, customer-facing webapp. Whereas this framework and others like it seem targeted at internal things, like some buttons and textboxes for an internal "admin" page or similar.
You’re totally missing the point. The point is: you have some Python script, and you don’t want it to disappear into the sad world of a ticket attachment, and if you add the 5 lines of code and have a nice onboarding experience, it doesn’t have to disappear into a ticket attachment, it can instead disappear into your browser bookmarks. You should never test the limits of this framework because if it’s anything other than putting a simple script into a webpage, you shouldn’t be using this. It’s rot proof.
The US Python foundational team was less than 10 people. If you think any 10 person team in a 200,000 employee corporation is that critical well I’d have to disagree
When their jobs were moved to Munich there was a lot of discussion about how important they were, but something else stood out to me. One of the things they accomplished was taking over a year to make sure the monorepo can be upgraded to the latest version of python
As an outsider this definitely smells like an org creating work just to justify its budget. You have a single team of a handful of engineers doing the python upgrade work for tens of thousands of engineers. Doesn’t feel right out of the bat
I’m sure soon enough with the role moving they’ll find out if the team is needed at all
you are right. made worse because there's an internal rule that you can't ever have two versions of a library in the monorepo ant the same time. it has to be one giant CL for the entire migration company-wide.
It was a nightmare. Mostly because there were a lot of special cases (think of a Python2 appengine-classic having no upgrade path on some //third_party lib that the team needed to keep running anyway), and it's not just the 10^5-10^6 # of concurrent contributors to the codebase, it's 10+ years of contributions much of which were maintenance-mode projects, many of those had been inherited two or three times over.
IF every package in the monorepo is forced to use the same exact version then there would exist literally thousands of these teams, even tens of thousands, which I doubt
I don’t really believe if I go to 500 Google owned websites I will find the exact same version of angular everywhere
every package in the monorepo did indeed need to use the same exact version of python. the python interpreter itself is part of the monorepo, and all other python code builds and runs that binary.
the python team did not personally upgrade every line of code to work with a new python version, we made sure that the code could be upgraded and got the people maintaining each package to do the upgrade. (a missing piece of the puzzle is that every package, even mirrored third party code, has an official owner responsible for keeping it working within google).
what the python team needed to do was upgrade all the tooling (build system, linter, type checker, etc) to work with the new version, run large scale tests to see what would break in an upgrade, analyse the dependency graph to figure out what order packages needed to be fixed in (e.g. if numpy needed to be upgraded that would be super high priority because thousands of other packages depend on it, and we might even pitch in and help the team maintaining it with that if needed), and track the progress of the upgrades, communicating with teams whose code hadn't been upgraded so that they could prioritise the work.
sometimes we also needed to write automated refactorings to fix some basic code pattern that changed, e.g. if some very widely used library decided it was going to stop accepting numbers where it needed strings, and that the caller should do the conversion first, we would try to mechanically fix that across the codebase rather than make everyone do it themselves.
anyway, this is all to say that it was indeed a large and time consuming problem, and we were certainly not doing it because we had nothing better to do with our time.
What's with the obsession of writing web apps in Python?
> Build custom UIs without writing Javascript/CSS/HTML
Why? These three were built for the web and work flawlessly. I doubt that an abstraction built on top of these will result in faster development times.
The State Management guide[1] explains state and then explains the usage. If you know Python and want to build a UI with it you'll have to read the guides. The argument that having a familiar language simplies development doesn't stand here.
There are multiple projects now that allow you to build a UI in Python and it feels wrong to me. Who is it even intended for?
Counterpoint: you have made a fun and interesting thing in Python that works great in your command line/Jupyter notebook. You want to share it with your non-developer friends/anyone who might be interested, so you need some kind of interactive GUI, and the easiest one is a web page of some kind. But you don't want to learn a whole new stack because web development is really not Your Thing.
So you use something like Dash, Streamlit, or this, which allows you to do everything in Python and put up something that looks reasonably professional but does not require a great deal of time or effort. Or get serious and do it in Flask or Django.
From your other comment: But you don't need that. You can create amazing user experiences with a plain HTML, CSS and a JS file.
What do you consider the best example material for that? The reason us Python programmers (many of whom are amateurs) are so leery of Javascript et al is because most commercial websites are so hideously complicated, and most of us are just not interested in front end stuff or we would have started out with Javascript in the first place.
I've said it before, what most Python programmers want for UI is something like Visual Basic used to do - just a simple canvas with a palette of standard UI components that can be thrown together like Lego and doesn't look like a complete mess.
That's a great question. And I completely agree. It's become extremely common to obfuscate client code or throw together 5 NPM packages into a frontend framework to justify "rapid development".
Here are a few websites that have great UX and readable source code. For each, you can view source and understand how the page is structured, styled and made interactive:
Web technologies are amazing. It's one thing to say that it's hard because you're not familiar with it and another that they are objectively bad. I disagree with the second statement.
If people want a drag and drop solution for building UIs that's great. I'm sure no-code solutions exist for that. Again, my disagreement is on the point that somehow building UIs with Python is better.
Thanks - those are very interesting. I fully agree that building UIs with Python is not better in objective terms; I just think it's more convenient if all you want is a minimal interface.
It appeals to me. I don't write fronted code, but sometimes I want a frontend, even if it's really dinky. This seems way more approachable to me than learning JS/all the shit you have to deal with to write a non-toy ui
Let's say you want a frontend for your server and have never written HTML before.
Where so you start? If you have decided on using Python for the UI you have a handful of libraries each with their own documentation. To get started you need to choose one and then read the guides.
If you decide to use HTML you have a whole lot more resources. I'd argue you'll be able to make a frontend faster using this approach.
I understand the hesitation because of the complexity associated with JS. Maybe you're thinking about bundlers and minifiers when you think about writing a frontend with JS.
But you don't need that. You can create amazing user experiences with a plain HTML, CSS and a JS file.
I'm not trying to make an argument for "Python for the UI" in general. I just looked at their demo page, and thought "huh I could probably turn my debug script in to an okay looking UI in an hour with this". Maybe you are right that I could make something okay looking with plain HTML/CSS/JS in less time (including the time to figure out HTML/CSS/JS?)
I agree on making a demo for an existing Python project. I have used Gradio and I think it's amazing!
I disagree on the using something like this to start making a UI. When you know that your project requires a complex frontend, you're better of starting with HTML.
While you may be able to create amazing experiences in JavaScript, JavaScript still has multiple problems:
1. It is inconsistent [1]
2. It does not have many features that programmers love and other languages have.
3. It has a community that holds different values from what other programmers value themselves.
If people want to continue development in JavaScript, they can. But since JavaScript has a monopoly on the (fairly large) 'frontend development for the web' market, there will always be attempts to find an alternative.
> > Build custom UIs without writing Javascript/CSS/HTML
> Why? These three were built for the web and work flawlessly.
Because you are throwing a Web UI on something written in Python for other reasons, and don't want to add 3 additional languages to the mix to do that.
