For any UI devs: I’ve starting working on a lemmy front end called
lemmy-ui-leptos [https://github.com/LemmyNet/lemmy-ui-leptos] using leptos
[https://leptos.dev/], a Rust UI framework with isomorphic support, and tailwind
+ daisyUI [https://daisyui.com/] for the component styling. This could
eventually replace the frankenstein’s monster that lemmy-ui has become. Some
reasons for doing this: - lemmy-ui uses infernojs, which is based on the react
model. IMO is largely superseded by signal-based reactivity in use in android
jetpack-compose, SolidJS, and most new UI frameworks. - I had to hack on
isomorphic support / server-side-rendering to infernoJS, and it’s very messy.
Leptos has isomorphic support out of the box. - All the benefits of Rust over
javascript. - Since leptos is in Rust, we can import the lemmy types directly. -
I’ve been waiting for years for a good rust UI framework, and I think we’re
finally here with leptos or sycamore. - lemmy-ui uses bootstrap, which is
showing its age and limitations. Tailwind (and daisyUI) seem to be much more
future-proof. I plan on leaving the site design and component styling to other,
more skilled UI devs, while I work mostly on the auth, services, params, and
overall back-end structure. - Please use daisyUI classes tho whenever possible
over exhaustive tailwind ones. - I’d also like it if the UI could match that of
jerboa’s (whenever possible), so that a change in one could be represented in
the other, and so that things like badge appearance for admins, could be
recognizeable across lemmy’s front ends. You don’t really need to learn rust to
help out with this, as the components look very similar to JSX. Instructions for
running it are in the CONTRIBUTING.md
[https://github.com/LemmyNet/lemmy-ui-leptos/blob/main/CONTRIBUTING.md] . Feel
free to contribute! Right now only the home page, and post pages are working,
but ready to be styled.
Quoting the author
I’ve starting working on a lemmy front end called lemmy-ui-leptos using leptos, a Rust UI framework with isomorphic support, and tailwind + daisyUI for the component styling. This could eventually replace the frankenstein’s monster that lemmy-ui has become.
@sugar_in_your_tea@NotAPenguin I think I agree with you in general and I’m really not worried about some set of words I might not see, but it is a very strange position from the project runners to make this decision in this way imo. I just don’t love seeing FOSS owners tossing a constraint in like this; particularly hardcoding the thing. It makes me anxious in a somewhat slippery slope kinda way that they might flip some other ideological switch on people
But the fact that we’re talking about it means the system is working as intended. Someone noticed something odd in the code and raised a concern to discuss it. I also disagree with the maintainers on this, but from a different angle (i.e. I don’t think built-in filters actually work, we should instead be relying on moderators and moderation tools).
At the end of the day, the maintainers get to choose what changes to accept, and contributors can decide whether to contribute. If contributors are annoyed enough, they can easily fork the project. That’s how open source projects work.
It’s not a democratic system, it’s a consensus system, and the community can choose which fork to follow.
@sugar_in_your_tea yeah I think we’re in agreement here. And I agree it does mean that FOSS works. Nice thing too is the protocol isn’t at all locked down. They could entirely lose the plot and hardcode some insane stuff into their #activitypub implementation and we could still more or less play from another instance of another service from what I understand
Yup, and there are some good examples of projects that have done something similar, such as GrapheneOS which broke from CopperheadOS. Open source can be messy, but at least there’s the option to fork the project.
@sugar_in_your_tea @NotAPenguin I think I agree with you in general and I’m really not worried about some set of words I might not see, but it is a very strange position from the project runners to make this decision in this way imo. I just don’t love seeing FOSS owners tossing a constraint in like this; particularly hardcoding the thing. It makes me anxious in a somewhat slippery slope kinda way that they might flip some other ideological switch on people
But the fact that we’re talking about it means the system is working as intended. Someone noticed something odd in the code and raised a concern to discuss it. I also disagree with the maintainers on this, but from a different angle (i.e. I don’t think built-in filters actually work, we should instead be relying on moderators and moderation tools).
At the end of the day, the maintainers get to choose what changes to accept, and contributors can decide whether to contribute. If contributors are annoyed enough, they can easily fork the project. That’s how open source projects work.
It’s not a democratic system, it’s a consensus system, and the community can choose which fork to follow.
@sugar_in_your_tea yeah I think we’re in agreement here. And I agree it does mean that FOSS works. Nice thing too is the protocol isn’t at all locked down. They could entirely lose the plot and hardcode some insane stuff into their #activitypub implementation and we could still more or less play from another instance of another service from what I understand
Yup, and there are some good examples of projects that have done something similar, such as GrapheneOS which broke from CopperheadOS. Open source can be messy, but at least there’s the option to fork the project.