• 4 Posts
  • 102 Comments
Joined 2 months ago
cake
Cake day: October 6th, 2024

help-circle




  • Why are people on this sub so quick to label things an “ad”? Someone did it to me yesterday. I wish we could just share interesting things we find on this sub.

    Rober made a cool project, gave a really good explanation for what goes into engineering the satellite (see YouTube video announcement), and made a website so you can upload jobs to the satellite yourself. It’s free if you’re a Crunchlabs subscriber, and if you’re not, you can choose to make a donation to help a kid learn engineering.

    If you’re not interested in donating, you can still watch the video and learn a lot about launching small satellites free of charge.




  • Maybe my perception is skewed, but I just got done applying to React jobs, and there were tons of React Native gigs. I haven’t looked at Flutter in years, but I can’t imagine the market is flooded with as many Flutter people compared to React. There are also way fewer people that know Dart than JavaScript.

    Tamagui is definitely more niche, but React has infected a large portion of the industry at this point, like it or not. Voyager is written in React Native.

    The reason I’m choosing to go with Tamagui is that they do a good job of bridging the gap between React Web and React Native. Another solution would be to split native and web into separate code bases or share React business logic but have separate code for the web and native views.

    My goal is to share as much of the code as possible. Feed virtualization will need to be handled differently on web vs native, and navigation will differ, but I’m pretty sure I can share 90% of the code between web and native.

    So Tamagui is niche, but I do think it’s the right tool for the job in this case. The downside is Tamagui One is in beta, and Tamagui itself has more maturing to do, but I like what I see so far and I’m confident it will continue to improve, making it worth the investment. They also abstract away much of the complexity, which means less things I need to worry about.




  • Interesting. If you have any talks or articles, I would love to learn more. Without knowing anything about PieFed vs Lemmy, I will say I do think it’s important with any product to nail down its core functionality first. Trying to please everyone can degrade the overall quality of the product. Is it possible Lemmy is focusing on core functionality first? Like it’s interesting that PieFed includes some features but lacks more basic features.

    Swapping out API calls shouldn’t be too difficult, but if the schema of the data is very different, it could get difficult. If PieFed was a superset of Lemmy in the sense that it returned the same schema with additional information, then it becomes easier. AT Protocol is a good example of having a completely different schema, making it more difficult to implement interoperability - I know people are working on interoperability, so I’m not saying it’s impossible.

    I know nothing about PieFed, so that may sound ignorant on my part, but I will do more research.


  • That makes sense. I appreciate the history lesson. You’re right, my account is very new, and I’m new to Lemmy. Maybe the protocols you mentioned are more compatible than I realize. I would imagine that if Lemmy.world migrates, what they migrate to will be more similar to Lemmy than something like AT Protocol. So it might be okay to run with Lemmy for now and then adapt later depending on where most users wind up.

    I still would like to keep the project’s scope smaller, but if there was a mass migration from Lemmy, I would absolutely reconsider. Let me also read up on the similarity of the protocols. If interoperability is easy to do, I’ll consider interoperability from day one.



  • I need to set some constraints for the project. IMO, going multi-protocol will be too much work. I would rather do one protocol really well than try and satisfy multiple. I also primarily use Lemmy, and a Lemmy-based app is something I myself would actually use. Doing a different protocol would require me to put myself in the headspace of users that I’m not as familiar with. Much of building an app is sympathizing with your user base not just technical.

    But I plan on making the app open source, and that means it can always be forked and adapted to a different protocol later. And I’m happy to draw inspiration from other protocols.

    I appreciate the idea! I think a multi-protocol app would be great, but again I think for this project and my limited time, doing one thing well would yield a better result.




  • Respectfully, I don’t think it’s that simple. I think it’s one of those problems that appears deceptively simple, but when you dive into it, it becomes a big headache. One big difference between truly offline first and arbitrary web requests is an offline first app imo should let you close and reopen the app without dropping those pending interactions. When you marry this with cross platform, you need a robust database solution on both native and web, which makes the stack more complicated. I will consider making aspects of the app offline first, but I have decided not to make fully offline first a core feature.


  • I do share the offline first ambition! I also probably have ADHD and a tendency to start projects without seeing them through. I think it would be wise for myself to keep the initial scope of the project small. I would love to build the app that solves everything, but in practice I know I likely won’t be able to make that happen.

    From what I’ve seen, fully offline first would be more work than I believe it’s worth. Especially when you add the complexity of being cross-platform. I think I have to choose cross-platform or offline first, and I would rather solve cross-platform really well (better than Voyager IMO).

    So it’s not that I don’t share your ambitions, but I need to be realistic. But if an app existed that solved all the things you mentioned, I would happily use it!

    I appreciate you being understanding, and please continue to share your ambitions. I just encourage you not to be frustrated if someone closes a GitHub issue you open. Maintaining open-source software is taxing, and it doesn’t mean that the person closing the issue doesn’t like your idea.


  • You know how when a hobby becomes your job, it often stops being fun and leads to burnout? Side projects are fun because they offer you an opportunity to build something on your own terms. I want to build the app that I want to use, and I want the freedom to make decisions.

    At the same time, I want to hear from the community, and I will take into account that feedback for decisions I make.

    Respectfully, some of those issues you opened up are really big asks. Specifically, offline first (RxJS) and adding activity pub support. Initially, my idea was to build an app that did both of these, but after some experimentation, I decided I would burn out before the project ever saw the light of day just trying to solve offline first.

    I would still love to hear from you. But I have ideas for what I would consider core functionality, and that will come first. But I will take feedback into consideration and will likely implement some offline first functionality, which will be way simpler than being fully offline.

    My tech stack will be similar enough to Voyager that it’s possible I can copy past parts of my code into their app. So I’m not ruling out contributing back to Voyager, and writing my own app doesn’t mean I won’t learn stuff that I can contribute to other clients.