No idea. Just saw that post and figured OOP might want to connect with this community.

I’m working on my own app for lemmy, but it’s so early stage I have a long way to go. Literally started on it a week ago. And honestly I’m not sure if anyone will ever use it.

But I cross posted this to the lemmyapps community. I think the maintainers of some of the more popular lemmy clients are active there.

Ohhh that makes sense! Thank you!

I was just looking at image_details but for the height and width of the image. I see this exists in the TypeScript client schema, but I’m not seeing it populated for any posts. Any idea when this is actually populated?

Knowing the height and width of images before loading them would reduce layout shift.

Does Lemmy need to implement this? You might be able to pull most of this data from the API. I might try and build something like this myself at some point, but likely won’t have time until next year.

Lol I think the point was to demonstrate what you can do with addressable LEDs. Not that you should do that. Synchronizing that many LEDs, especially when they belong to multiple controllers, is very difficult to do.

I do think React could learn a lot from Flutter. I don’t think React is going anywhere, but I wouldn’t mind if they borrowed some of the good parts from Flutter. But also, I understand that RN vs Flutter have very different approaches to how they render under the hood.

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.

I agree with that. It’s similar to if someone loads the post in their browser. If the site isn’t actively polling the API to check if the content is deleted, they will continue to see it until they reload the page. The difference is the cache lives longer. I can probably have it poll the API when they reopen a cached article, and if it’s been deleted, purge it from the cache. The result is they may see it flicker as it’s purged quickly, and if they’re offline I wouldn’t be able to poll the API.

Tamagui + One (built on React and React Native), tanstack for querying and list virtualization, flash list for native list virtualization, maybe Zustand, Dayjs. It will be 100% TypeScript. I will likely use no Server Side Rendering with React. I would like it to be possible to host the site via GitHub pages for free so the project can easily be forked. Beyond that I’m still deciding.

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.

Apple is pretty stingy about how often tasks can run in the background. Offline first quickly spirals with complexity that isn’t immediately obvious imo. That’s why I don’t want to make fully local first as a core feature.

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.

I have experience doing YouTube embeds. It’s not hard. It’s just a question of all the different types of media embeds I also choose to support.

Yes! Exactly, I don’t think offline first should be a high-priority feature. I will spend too much time trying to get it perfect at the cost of other features.

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.

That’s amazing! I’ll reach out to some of the devs.