sergix

Related, my favorite paper title of all time, "Robust Soldier Crab Ball Gate" [1], demonstrating how soldier crabs can perform functionally complete reversible computations.

[1] https://arxiv.org/abs/1204.1749

Another way to put it: each step in a reversible process must be a bijection, or "information-preserving". The naive way to do that is to return the entire input as part of the result, but that's missing the point.

Great tongue-in-cheek project. Ignore those who don't get the joke, and keep building fun stuff like this.

https://xkcd.com/2610/

I believe the point is multifaceted:

1. Relationships are hard.

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.

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]

1: https://sergixdev.notion.site/Tauri-Documentation-b695823f0b...

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 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.

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.)

I did an extensive write-up about this topic if you're curious on more details: https://dev.to/sergix/ux-illuminating-intention-198k