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.
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.
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
That's true about memory, but nearly all mainstream programming languages have problems with null pointers: Java, C#, Go, etc.
I don't think the Python ecosystem was lacking in browser wrappers up till now.
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.
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]
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.
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 ;)
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.
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.
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.
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.
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.
What would be the benefits of this? I can't think of any yet.
Rust was a nice bonus.
This, of course, comes at a cost of performance as CSS alone is very complicated and has a lot there to support. On the flip side, there are many things that are easy to do with HTML+CSS that are much more difficult with native UI frameworks. Just the reflow support for multiple sizes/scaling in browsers is hard to match.
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.
It runs fine but, speaking as someone with no prior Android experience, once you need to leave the "Everything is in the view" model, it gets confusing. But that's more Android's fault than the framework's
rthz•3mo ago
hamandcheese•3mo ago
dlojudice•3mo ago
niutech•3mo ago