Write a letter to the lemmy devs and ask them to rewrite the backend to use htmx.

I disagree. I spent some time earlier this year working on a BlueSky client that would work completely without JavaScript. Working without JavaScript means it has to run on a web server somewhere. Using JavaScript means the client can run entirely on your computer with the only dependency being the Lemmy server you connect to. And since there are many Lemmy servers, this means no single entity that can pull the plug on you.

The only alternative I see is a native app that runs a non-JS client on your computer, or maybe WebAssembly? Seriously though, modern JavaScript is actually very capable. You might be dismissing it only because it’s popular to hate on JavaScript or maybe the current Lemmy clients aren’t good. That doesn’t mean the underlying issue is JavaScript.

I’ve abandoned my BlueSky client to work on a Lemmy client that will be written in JS but can run entirely on your computer.

I’m working on my own Lemmy client that I’m hoping will be both a better UI, but also universally better as an app (phone and tablet), MacOS app, and on the web. Voyager provides a web version, but it’s not optimized for larger screens.

My app will deliver the best experience on all screen sizes and will take the best of Reddit, Voyager, etc.

I’m 14 days in lol but if anyone is interested please DM me. I’m happy to share what I’m working on, but I just ask you have realistic expectations as this will likely be 6+ month project to deliver something that can actually compete with existing clients.

Yeah, but it didn’t seemed as stable or well built as the Advantage. And for a travel keyboard it’s not flat enough imo. But I know a lot of people like it and I didn’t actually get a chance to try it. But the Advantage does feel very solidly built.

Did shrodinger also buy beer at self checkout? Maybe all that drinking made him forget if the cat was dead or alive

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.

I wouldn’t mind a weekend project! How do keycaps work for custom layouts? I don’t have a 3d printer and that’s the area I feel least comfortable in if that’s required.

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.

If you didn’t buy the Advantage 360 yet, there is a refurbished store and I found a $50 off coupon. Saved about $100 on the Advantage 360 Pro. The pro wound up being cheaper. You can use it for the backlight but wired if you don’t want Bluetooth.

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.