2. If you take a step back and look at the things you argue with your significant other about (or anyone else close to you), it's humbling to see how silly it often is.
3. Love doesn't always agree; if you actually hated the person, why would you stick with them through the annoyances and arguments instead of leaving?
Sure, the whole thing seems unhealthy and petty, but I think that he would have stopped writing a lot sooner if he didn't truly love her. I also think the slightly-hidden image at the very bottom left of the page says a lot more than any of his words do.
> If you take a step back and look at the things you argue with your significant other about (or anyone else close to you), it's humbling to see how silly it often is.
One piece of advice I got from an old family friend when getting married two decades ago ... the next time you find yourself arguing with your spouse, when you feel that slight bit of anger or annoyance bubbling up, lift your shirt up and show them your belly button. You don't have to stop talking, just lift your shirt up and show your belly button while you're making whatever point you are making.
I've tried this a few times and it works wonders - doing something silly makes me stop and realize how silly the argument I'm in is.
The Tuauri team needs to focus on maturing its primary codebase and documentation before branching out to assign teams to separate projects like this. I've written a few hundred lines of code using Tauri, and I've had to do much more API wrangling and searching the official Discord than I would have liked -- a lot of valuable API details are tucked away in very specific places, especially related to using Tauri's state manager, creating mockup tests, and technical information on the IPC model. In addition, some of those APIs are obtuse and confusing to interpret how to use.
Tauri does a few things very well, and its frontend model is much more lightweight and flexible than Electron's. However, the project has a long way to go before it's used in the mainstream and really needs to continue to make testing, debugging, and other DX details much more accessible and clear to gain an edge in the market.
I agree with this. We are shipping our app Caido with Tauri and it is missing quite a lot in feature parity with electron. We always lose time to try to bypass limitations or work around bugs. I honestly can't recommend it for production at this moment, even if it is getting better.
Some of the challenges we faced in the last week: no built-in api for single instances (so basically making sure the app is only run once), no support for the task bar menu (right click on the app icon), a fair amount of APIs are platform specific so you need a lot of conditional compilation trickery to make it work, etc.
On top of that you have platform webview issues that are hard to reproduce sometimes since you need the user specific OS version and packages. If you care about uniformity of your UX and speed of development stick with electron.
> uniformity of your UX and speed of development stick with electron
This is what keeps me from adopting Tauri. I'm following the project with great interest, but I have zero desire to step back in time to wrestle per-platform rendering issues. Big fan of the progression, but it's not quite there yet.
If you care about your user's machines or being able to do anything other than use your app on their machine then please use the platform's tooling and not things like electron.
+10000 I really enjoyed working with Tauri, but had to drop it because after a few days of porting my app to it, I released that it doesn't support AppStore distribution (i.e. creating properly signed .pkg files). This wasn't clear in the docs, and the videos I watched implied the opposite.
The team is doing amazing work and I don't blame them for this, it's perfectly normal for things to slip.
I'm excited about Tauri partially because (in my specific use case) even if I build for Mac only, the UX I can deliver with it will be much better with a hybrid app than SwiftUI [1].
The lesson here is that if you're planning to work with Tauri and Mac, you might want to focus on testing the entire pipeline (design, develop, distribute) first, and then, once you can push to TestFlight, pushing and testing features. Again, YMMV.
[1] Weirdly enough, there's almost no way for me to build a native app that will beat the performance of an optimised web app. Again, my use case is very specific (a niche text editor), but I find it hilarious given how much sh*t web apps get on HN.
Conveyor solves out-of-store distribution and update (albeit, it's not been tested with Tauri specifically yet). You can then have the app check for a license on startup. Stripe integration isn't a lot of coding and the financial overheads are lower than with the app store.
Thanks, but I could probably save time by just using Stripe with the existing Tauri app. Tauri already supports notarised apps, auto-updaters etc... What it doesn't support is generating a properly signed .pkg file.
(this can be done using regular shell script, in my case there is, however, some weird, hard to debug issue with AppStore validation)
The missing bit is making the app paid, which normally should be trivial with the AppStore.
For any specific details that anyone may be curious about, I have a public Notion page with some different documentation issues and the links to their respective sources. [1]
Not necessarily. Having the submit button first means it's the first action the user sees since most people (at least Westerners) read left-to-right. However, your reasoning with having the order the opposite with the submit button last is spot-on.
No specific advantage has actually been attributed to either choice of order. What matters is (1) keeping the order consistent throughout an application, and (2) following the provided style guide for the platform you're developing on.
(Also, the order may need to be changed if the primary action is destructive, such as a "Reset" button.)
> (1) keeping the order consistent throughout an application
Not even just an application. The whole phone needs to be consistent. Every app in it. Otherwise it's just repeatedly discovering and forgetting how to use each and every app's unique interpretation of what their average user wants and what their average user thinks is intuitive.
I mostly agree, and that is why I mentioned that you should follow the general design guidelines for your respective platform. However, when creating a web app, general guidelines are more "implied."
The biggest reason why consistency is more important than following platform guidelines is for cross-platform apps available on multiple devices that have different platform design guidelines. It's obviously not feasible (and I would argue not user-friendly either) to switch the order of action controls for the same app on different devices, especially when the app is available via a web interface as well as native.
