[HN Gopher] Tauri binding for Python through Pyo3
___________________________________________________________________
Tauri binding for Python through Pyo3
Author : 0x1997
Score : 160 points
Date : 2025-10-08 06:58 UTC (5 days ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| rthz wrote:
| Nice. It might be worth copying some of the introductory text
| from the Tauri package explaining what this does. Otherwise a
| person to lands on the readme gets a lot of technical detail
| about how it is built without any idea what it actually does.
| hamandcheese wrote:
| The first word in the README (other than the title) is a
| hyperlink to Tauri.
| dlojudice wrote:
| Going further, what can I build using it? Basically, can I use
| Python on a Tauri project or can I use Tauri on a Python
| project?
| niutech wrote:
| Tauri in Python project
| rubenvanwyk wrote:
| Interesting how much cross-pollination is happening in the Python
| ecosystem with Rust.
|
| I think the NiceGUI example is good but quite advanced, might be
| beneficial to contact the teams from Reflex or FastHTML, because
| if you could use PyTauri to create potential local apps with
| those popular frameworks, it could be a big win for them and that
| can help with marketing around the project.
| wongarsu wrote:
| Rust and Python have very compatible ideas on a lot of topics.
| For example both think that a developer writing normal code
| should not have to worry about null pointers or be able to
| cause a use-after-free. It's just that Python achieves that
| with runtime costs and Rust with compile-time costs and a
| complex type system. So developers of one liking the other
| makes a lot of sense to me. And pyo3 is an extremely convinient
| way to call between the two languages
| cardanome wrote:
| > For example both think that a developer writing normal code
| should not have to worry about null pointers or be able to
| cause a use-after-free
|
| Like 99% of all languages currently in use.
|
| These things have long been solved way before Rust even
| existed. Rust has only filled the small niche of cases where
| you can't or don't want to use automatic garbage collection.
|
| > complex type system
|
| Python's type system is orders of magnitude more complex.
| Dynamic type systems are crazy powerful, this is why
| Typescript is such an complex beast.
|
| Rust has static type checking, which is what you mean. Which
| also means that Rust is limited to the types that are can be
| expressed and are decidable with that system, while Python
| allows you to do... whatever and types are only checked at
| runtime or with external tooling.
|
| Python's type system is easier to use but more complex.
| Rust's is simpler but harder to use. I know people forget the
| difference between complex and hard but it is an important
| one.
|
| A better reason Python is Rust are seen together is that
| Python is an excellent glue language. Same reason people like
| C and Python. Plus both Rust and Python are pretty trendy
| these days.
| wongarsu wrote:
| > Like 99% of all languages currently in use.
|
| Yes, but 90% of languages don't make a good complement to
| python. If you want to have a language to use in
| combination with python you want something with fast
| c-interop, which most garbage collected languages can't
| offer
|
| > Rust has static type checking, which is what you mean
|
| Maybe I shouldn't have used the word complex. But I did
| primarily mean that Rust uses the type system to ensure
| "safety", while Python primarily uses other methods. Yes,
| Rust doing static type checking is also an important
| component of it.
|
| > A better reason Python is Rust are seen together is that
| Python is an excellent glue language
|
| That would qualify any language as fitting well to Python.
| Which I don't agree with. C fits well to Python because it
| is a good complement: Python is slow to execute and easy to
| write, C is fast to execute and hard to write, and
| communication between the two is fast. Rust fits even
| better to Python because it's easier to write than C (well,
| easier to write correctly) and because interop is fast and
| convinient
| maleldil wrote:
| > Like 99% of all languages currently in use.
|
| That's true about memory, but nearly all mainstream
| programming languages have problems with null pointers:
| Java, C#, Go, etc.
| mrsmrtss wrote:
| This is mostly solved in C# -
| https://learn.microsoft.com/en-us/dotnet/csharp/nullable-
| ref...
| torginus wrote:
| Since Tauri is just a thin wrapper over the system webview,
| what's the point of having a wrapper over a wrapper?
|
| I don't think the Python ecosystem was lacking in browser
| wrappers up till now.
| Ciantic wrote:
| "a thin wrapper over the system webview"
|
| That is very complicated if you take into account also Linux,
| Windows, iOS, MacOS, Android support, and related utilities
| like tray icon, etc. There are other efforts, too, but they are
| also wrappers. Like this C/C++ implementation
| https://github.com/webview/webview that targets only desktop
| operating systems.
| rubenvanwyk wrote:
| I don't think the point is just about Python - this means you
| can use JS front-end with a Python backend for a local app.
| niutech wrote:
| Tauri also has their own experimental Servo engine:
| https://v2.tauri.app/blog/tauri-verso-integration/ So it's not
| necessarily a wrapper over system webview.
| h4ch1 wrote:
| Verso just got archived :( As the project
| progressed, multiple significant revisions to Servo were
| released, and the Verso browser was unable to keep pace with
| these updates due to limited manpower and funding. Therefore,
| we will be archiving the repository for now and look forward
| to a future opportunity to revitalize the project and
| continue contributing to the Servo ecosystem. [0]
|
| [0] https://github.com/versotile-org/verso
| robertlagrant wrote:
| > Since Tauri is just a thin wrapper over the system webview
|
| This isn't true. It's a thing wrapper over various things,
| including that.
|
| Even if it were true - so what? There are probably 30 nested
| wrappers you could name even if you started at WebView as the
| outermost wrapper.
| GardenLetter27 wrote:
| I don't understand why people like Tauri - the fact it uses the
| system web browser completely destroys the main advantage of
| Electron: that you can test it locally and be absolutely sure
| that it will render like that on any other system since the
| browser is shipped with it.
| wolfgangbabad wrote:
| I agree. I don't mind VS Code or some app a person did eats 300
| MB of RAM and is Electron if it does the job done. By the way
| good luck implement something like rtl, i18n, text select and
| right click context menus in you favorite
| C/Go/Rust/ImGui/ImmediateModeWhatever library.
|
| Wanna switch between Arabic, Chinese, English in a textarea or
| input or the whole app? Trivial in Electron. Again, good luck
| with that in any other environment.
|
| Electron is superior for any text/form apps. HTML/CSS/JS are
| truly magical if you dive deeper and for any form-like
| classical type of crud apps there is really no better option.
|
| With our computers getting more RAM and disk space every few
| years - especially compared to AI needs, Electron is actually
| super lean compared to those AI llms models. Funny enough, LM
| Studio is an Electron app ;)
| mpalmer wrote:
| > With our computers getting more RAM and disk space every
| few years - especially compared to AI needs, Electron is
| actually super lean compared to those AI llms models. Funny
| enough, LM Studio is an Electron app ;)
|
| This is a phenomenally bad take. This is exactly the thought
| process that has led to the insane software bloat problems
| we're dealing with now (with Electron as one of the worst
| offenders).
|
| > good luck implement something like rtl, i18n, text select
| and right click context menus in you favorite
| C/Go/Rust/ImGui/ImmediateModeWhatever library.
|
| > Electron is superior for any text/form apps. HTML/CSS/JS
| are truly magical if you dive deeper and for any form-like
| classical type of crud apps there is really no better option.
|
| I don't think you understand what Tauri is.
| Fraterkes wrote:
| For a lot of people the main advantage of electron was just
| being able to use the webdev stack for a desktop app. Tauri
| makes it less portable but is less bloated. Different tradeofs
| I guess.
|
| Also: I think it's kinda funny that Tauri is basically a very
| straightforward of example of trading developer comfort for
| benefit of the user, and you can't imagine people using it.
| ed_blackburn wrote:
| Indeed. It's sacrifices engineering cost for customer
| experience.
| mathverse wrote:
| I have never seen a Tauri app that was significantly less
| bloated than Electron. Can you share any?
| sabellito wrote:
| The bundle size is, by definition, much smaller as it
| doesn't include the browser engine.
| GardenLetter27 wrote:
| It's not for the benefit of the user when you get dozens of
| issues in Github because webkit-gtk or WebView2 changed
| something.
| niutech wrote:
| If you stick to good old HTML5 with CSS3, without cutting
| edge Blink-only features, you should be safe.
| gkbrk wrote:
| > the main advantage of Electron: that you can test it locally
| and be absolutely sure that it will render like that on any
| other system
|
| That's not the main advantage of Electron. The main advantage
| of Electron is being able to use web developers to build your
| desktop software cross-platform for much cheaper.
| est wrote:
| because most Electron apps are not that complex. Just few forms
| with some buttons.
| aitchnyu wrote:
| Do we have an open source Playwright for multiple mobile
| browsers?
| iDon wrote:
| I have drafted a photo gallery app in Rust / Tauri, using a
| JavaScript framework in the frontend. The backend can read
| directories and files directly, and because the backend and
| frontend are in a single process, the backend simply passes a
| file handle (path string possibly) to the frontend. In contrast
| Electron has to send the image file between processes. I
| started with Electron and I think that was the point I shifted
| to Rust / Tauri; seeing the images display immediately was a
| revelation. Rust / Tauri has the advantages of a desktop app,
| and I have the option to use the frontend as a web app also.
|
| This Python binding (pytauri) is interesting too - I have
| colleagues with Python functionality they want to surface on
| the web, and this would give the possibility of running as a
| desktop app also - good for large datasets.
| mpalmer wrote:
| There's an entire _separate_ copy of Chromium attached to every
| single goddam Electron app I install. It 's completely insane.
| It's not at all worth the consistency you point out. Far too
| high a price.
|
| The Tauri team is doing God's work. Electron was a fine enough
| idea, but I can't wait to see it improve or die. Imagine
| Electron supporting cross-compilation for mobile OSes. They
| won't close that particular gap with Tauri any time soon.
| jonpalmisc wrote:
| The times of browsers having weirdly different rendering
| behavior are mostly gone, in my experience. I'm sure ~98% of
| Electron apps that expect Chromium would render just fine/same
| under WebKit as well.
| pjmlp wrote:
| You mean the laziness of developers to write standard Web code
| and rather help Google in their plans to take over the Web?
| niutech wrote:
| Tauri also provides an experimental Servo web engine to follow
| Electron: https://v2.tauri.app/blog/tauri-verso-integration/
| est wrote:
| So why can't Python call system WebView directly? Is passing
| through layers of Rust really needed here?
| Retr0id wrote:
| Abstractions are rarely "necessary" in a strict sense but since
| Tauri already solves the problem of doing cross-platform
| webviews, why not reuse that work?
| akshayKMR wrote:
| I've used pywebview in the past ~2017. Works well.
|
| https://github.com/r0x0r/pywebview
| alejoar wrote:
| What is Tauri?
| postepowanieadm wrote:
| Electron.
| kacesensitive wrote:
| Electron* but without the bloat of Chromium
| kdavis01 wrote:
| A rust-based alternative to electron that leverages the
| system's web view instead of a full copy of chromium.
| zenlot wrote:
| Python, along with C++ enjoys the benefits of Qt. You can build
| great stuff with cross-platform Qt. And it won't be
| webview(Electron / Tauri) based.
|
| What would be the benefits of this? I can't think of any yet.
| sabellito wrote:
| This benefits people and teams who prefer to build UIs with
| html/js/CSS.
| noveltyaccount wrote:
| Avoiding Qt licensing
| zenlot wrote:
| Quite a few options there. Never really a problem.
| WD-42 wrote:
| I worked on a team the switched v2 of our product from Python +
| QT to Tauri specifically to get away from QT. If you have any
| kind of specific design requirements, QT is pain. The ability
| to use the frontend web stack is a huge win especially for a
| team that already has frontend developers.
|
| Rust was a nice bonus.
| kelvinjps10 wrote:
| Doesn't qt also offers a webview solution?
| WD-42 wrote:
| It's very basic. Good enough for oauth flow but not much
| beyond that, definitely not to host your entire UI. Also I
| don't see what the point of that would be.
| kelvinjps10 wrote:
| My point it's that you said you changed from QT to Tauri
| because of being able to use frontend frameworks but QT
| also allows you to do the same. Anki does something like
| that, but since you mentioned rust that might be the
| reason of the change to Tauri.
| WD-42 wrote:
| But why would you pull in an entire UI framework, QT,
| just to use its webview? If it's not clear, these are
| local apps we are talking about. The webview loads local
| content. This is what tauri does.
| yumraj wrote:
| Not to distract from Python or Tauri, but lately I've been using
| Wails[0] which is similar to Tauri but with Go instead of Rust.
|
| There are pros/cons primarily being Tauri seems to allow creation
| of mobile apps which Wails doesn't, but overall it's been
| fantastic since I find Go to be an easier language for me.
|
| [0] https://wails.io/
___________________________________________________________________
(page generated 2025-10-13 23:01 UTC)