Here are the problems I want to solve:
The same app everywhere
It will run as a website, iOS app (also on macOS), and Android app. It will be responsive, supporting phone, tablet, and computer screen sizes along with everything in between.
And I’m not talking about simply resizing the interface. Navigation (e.g. sidebar or on mobile bottom tab bar) will match what you would expect to see on the device size you’re using. But everything else (e.g. posts) will look the same, which I hope will make it really easy to jump from mobile to desktop.
Onboarding and configuration
The app will allow you to configure it to look like a typical Reddit or Lemmy app. During the onboarding process, I will prompt you, asking which style of interface you prefer. Consider these presets, which change a bunch of more granular configuration options. I will also give you the ability to fully customize each option instead of picking a preset.
Caching and offline support
This is where it starts to get more tricky. Caching is easy. If you launch the app, it will have everything you previously saw still loaded.
I would like to make it so upvoting, for example, can be done offline. The app will optimistically apply the upvote to the post or comment, then when you reconnect to the internet, it will actually apply the upvote. This is a difficult problem to solve, so I can’t promise this will work, and it would likely be the last feature I add.
I need your feedback
This is a big project to undertake. I really want a Lemmy client that checks those boxes for myself, but I’m curious if any of those resonate with you? Is there anything I missed that you would like to see? If I do build this, I will likely have to keep the project very focused as far as features go initially.
Just for context, I’m using Voyager on iOS currently. I really like it, but the “the same app everywhere” concept and making it easier to onboard Reddit users are my main motivations for creating my own app. My app will also be fully open source
Wow, I totally missed that. However, it does feel like the web was tacked on as an afterthought. It feels like navigation hasn’t been optimized for larger screens (see screenshot below). A sidebar would be much more usable on larger screens than this stretched bottom tab bar.
That being said, it would probably be easier for me to contribute to Voyager than to build my own app. But I also kinda want to build my own app, lol. But I might also consider contributing to voyager if they are interested in optimizing their interface for larger screens.
If you don’t like how voyager does some things, fork it to add your own ideas. It’s faster than starting from scratch.
True. The thing is, my day job dictates the tech stack I use. There are specific technologies I want to learn in my free time, and those technologies happen to align well with this app, in my opinion. Forking is probably the smarter move… but I think I’m going to do it my way.
What stack do you want to be working in?
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.
Good luck then, with that stack you’ll likely be working alone as contributors typically drive forwards Flutter these days. But it sounds like you’re doing this to learn anyway, which is great.
Personally I use Thunder and added the two column view for tablet, had considered PRing a web and/or desktop compilation to see how it looks, but realized I never used it. I don’t even have a standard web UI up ony server all the time.
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.
React Native is big because ot was first. Stats I’ve seen show new apps leaning towards Flutter since Dart compiles native, unlike RN. RNs native parts are written in Java, and personally I’ve found Flutter to solve all the issues I had with RN.
For instance, large image galleries were simple in Flutter, and required all kinds of memory management in RN.
That being said, I still like RN a lot, so don’t take this as me bashing on it.
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.