I'm sure everyone has their own tolerance for what is and isn't maintainable :). For me, not knowing what code exists, where it is, how it fits together, and stuffing it all in one main file feels like a recipe for trouble down the road. Sure, I could probably tell the LLM to split the main file into modules and ask it to refactor code etc.
However, from personal experience I'm a lot more efficient when I use LLMs to help with tedious, boilerplate-like code writing but I remain in control over structuring the project so it's maintainable by more than machines only.
I use LLMs every day to write tests for example, it's a massive time saving and I wouldn't want to write tests manually ever again.
Hey, I did not. As mcbetz mentioned, I tried vibe-coding and anything you see is generated by LLMs. He linked to my blog post where I summarized the journey.
ZenQuery looks nice, I like the focus on supporting regular files.
No worries.. even if it were copied, it would have made me feel proud. Nevertheless, I saw it now that's its actually fully vibe-coded... so, high chance my product's webpage was part of it's training data..
I did download your product ans using it for postgres. Was using dbeaver earlier, but, it's tooooo messy in it's UI.
Awesome... for databases containing large number of tables, you can pre-process the tables and generate embeddings for each. Then, when user asks a question in plain english, filter relevant tables using in-built vector search and pass metedata of these only as context to LLM.
A database desktop client, built with Tauri & SvelteKit.
"But there are many already!" I hear the crowd exclaim.
I respond, "Yes, but..."
It's really something I want for myself. Lightweight, as fast as humanly possible, extensible via plugins (in fact the entire app is mostly plugins, with a small core to glue it together), and a tiny bit of LLM (call it AI if you wish) integration to ask questions about the database or generate/review queries.
I've built apps with Iced, Dioxus and PopOS's version of Iced. Here is my opinion:
1) Iced requires you to style everything in their own styling methods. It's not as intuitive as CSS. I found that, coming from using CSS, I struggled to recreate the style to the same high bar I expected from websites using css.
2)LLMs are not as familiar with Iced's styling, and will struggle with helping you plus also dealing with the breaking changes between Iced versions. Same to a lesser extent with Dioxus
3) Dioxus is easier to build by hand and via LLMs since you just use CSS/tailwind CSS. That said, even Dioxus is rough on the edges, you occassionly get some weird bugs, that you just have to deal with
4)PopOS' Iced version is great if you're using it on PopOS specifically but will require you to install a separate style pack on other linux distros to get the styling of the windows to show correctly. It's more mature than the original Iced IMO, though it's opinionated styling(of it's starter boilerplate) may be less to your liking. While I haven't used it in some time, I would consider it an almost independent fork by now
5) Last but most important negative IMO of Iced and Dioxus is their release cadence. Iced 0.14 has now launched more than a year since 0.13. For some the stability is great, but for frameworks that are still maturing with lots of improvements pending, I think it's actually important to have faster release cadences so that you know issues you face are not left hanging for a fix for a year.
Now onto more practical stuff:
1) If you need simple, standalone apps, any one will work. I think this may be true for your app idea
If you need speed of change, multi platform, etc, you will likely end up with Tauri. In that case, you might as well use the front-end framework you like.
2) None of the frameworks give you a pathway to publishing except Tauri. Basically, only Tauri really puts that as part of its guide, and so when you are going to Publish, you will be using Tauri's guide anyway
3) If you need multi-processing, Dioxus is out of your option, or you will end up using Tauri with Dioxus as your front-end
Thank you, I appreciate the in-depth opinion! I think Tauri with SvelteKit is going to be my first prototype, likely followed by gpui because I'm impressed by Zed which is built with gpui.
You do not know their specific issues, their wording isn’t stating what you seem to think.
The master branch approach isn’t always ideal and people prefer having actual releases to base their work on. Not having a set release cadence and it more or less being on the whims of the one maintainer doesn’t exactly inspire the same level of trust you get from Dioxus/etc.
No issue at all is guaranteed to be fixed by the next release. There's no expectations that the deck of issues gets cleared when a new release is published, so conflating the two topics isn't accurate or helpful.
You'll have to explain why the master branch approach isn't ideal. The only argument I've seen hold up is that the community can pin their own crates around a specific release, so if you rely on a lot of third party crates, you benefit from more frequent releases. Given iced is still pre-1.0, I do not encourage people to rely on a lot of third party crates. Most of them also have permissive MIT licenses so you can always bring any one-off bit of code into your own crate and maintain attribution. I did that with the split widget from iced_aw, which was available in 0.12 and dropped by those maintainers when 0.13 came around. I've since made several tweaks to it to fit my specific use cases, so all in all I'm just better off vendoring it myself.
In fact, you also have no guarantee that third-party crates will (1) continue to update for future releases and (2) evolve their own APIs in the manner that you prefer. So if you're worried about being up-to-date and/or stability, again bringing the code into your crates is again the better choice—at the obvious cost of having to maintain it yourself, but such is the nature of software.
I do not know what you mean by "inspire the same level of trust". Or I think I do, but I do not think it's helpful language or an accurate framing. Are you a part of the iced community? I can't speak for everyone, but ISTM that most everyone trusts hecrj implicitly—and we all understand iced is a labor of love, not commercial and the fact that it is subject to his whims actually helps guide a specific vision forward, however long that may take. The ride has been great so far. The Pop!_OS team seems to agree.
I watched this video when it first came out. Honestly, the video is right in what it was trying to say. That said, that video didn't change my mind on whether to build on Dioxus and it should not for someone either.
The choice of framework should not be dependent on who else is building on that framework. Ideally the factors that matter:
1) Why are you building a GUI app on rust?
2) Target platform/OS support?
3) Are you ok with custom styling methods? Would you prefer to use CSS?
4) Need for multi threading?
5) Publishing / bundling / signing app
I think the reason Dioxus cadence release is slow is that they realised so many things are missing with the rust gui ecosystem that they decided they needed to fix these while building the main product. Guess what, this basically slows down your main product cadence. Does rust need a sub second hot reloader? Yes. Does rust need a native html/CSS renderer? Also probably yes. Did the Dioxus team have to take it on given their size and all the things pending in building rust with html + css? Armchair observer me thinks not.
*Note that I am currently building an app with Dioxus, so I'm putting out my honest opinion, and not saying that you shouldn't use it.*
>The master branch approach isn’t always ideal and people prefer having actual releases to base their work on.
I think this is me. My view is basically like this - if you use a tech you know works, you're only wrangling with your bugs. If you use a tech that is still being worked on, you are wrangling your bugs and the bugs of the tech you're using.
To be fair, I've tried this master branch thing with both Iced and PopOS's Iced fork. One year ago, PopOs's Iced fork was so slow I realised it basically wasn't going to be production ready for non Pop distros anytime soon.
IMO, both suffer from having very slow release cadence but at least dioxus has CSS
I appreciate the thoughtful replies. I struggle to understand why CSS is such a big deal if you're not building for the web. I can make my app as pretty as I'd like using styling that isn't CSS. OK, maybe I miss glow effects, some nicer gradients and 3D transforms, but those are far from showstoppers and still worth giving up for everything else I gain with iced
You bet! Shadcn is defacto component framework for a reason - it removes a lot of the mental load of design when you're an individual/small team building apps
TLDR; I'm keeping an eye on using LibWeb instead, which promises to be less bloated
-------------------------------------
Honestly, we're solving the wrong problem by using something like Electron, webit, Tauri, etc. We're aiming for perfect feature parity with web browsers.
Instead, I want a good way to declare my UI in a subset of HTML, a subset of CSS and optionally a subset of Javascript. That's it, as far as web support goes. I don't need support for 1999 HTML/CSS, or special cases for animation in CSS, etc.
What I actually need for native applications is support for desktop/OS integration. Things like taskbar/panel icon control, notifications (not just toasts), access to the file system that doesn't use Javascript inside node.js, running tasks in the background independent of the GUI (after the GUI is closed, I expect the browser engine to end, freeing up all that RAM).
Striving to maintain feature parity with actual web-browsers eats up a lot of dev effort, so instead of targeting a sane subset of HTML, CSS (and optionally Javascript) it's simply easier to use an existing browser engine, which brings in the bloat and difficulty.
"Perfect is the enemy of good" has never been truer: I don't need everything that webkit, chrome, servo, etc provides when writing a native application, but "bloated" are the only options.[1]
Personally, I'm waiting for some free time, or a week off, to look into LibWeb (the SerenityOS engine, currently used by Ladybird browser). I think that creating a simple FFI around it is probably a better use of my time than doing the debug dance with Tauri and similar; at the end of the dance I'll still have a heavily bloated thing tied to an engine better suited for writing browsers than for writing apps.
It's not ready yet (it does layout HTML semi-properly, but it still needs some polishing and the desktop integration is currently not working, only the layout), I hope can get a release of it out before Christmas.
How about HTML, CSS, and Rust? (cutting out the JS engine removes a lot of the bloat)
I'm building a web engine specifically targeting application development use cases here: https://github.com/DioxusLabs/blitz. Binary sizes are in the 5-15mb range (depending on which features you enable).
Just use Qt. QML is not exactly like HTML, but in a lot of ways it's better. HTML is primarily a document format, QML gets closer to the semantics of an application, but in a declarative format. It's also much, much faster and simpler to deploy.
I installed Zed to read JSON logs that caused my browser and Pycharm (Jetbrains, Java-based) to lag hard. Sometimes I scroll down to the millionth line since the quickness makes me think I downloaded only a subset.
When I want to implement a TUI, I just write it myself (usually by modifying my own preexisting code) rather than use an external tool. So there isn't anything I'd like to do that I can't do. But that's not really helpful to you, sorry.
However, from personal experience I'm a lot more efficient when I use LLMs to help with tedious, boilerplate-like code writing but I remain in control over structuring the project so it's maintainable by more than machines only.
I use LLMs every day to write tests for example, it's a massive time saving and I wouldn't want to write tests manually ever again.