Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Porting to a different stack #696

Open
razzeee opened this issue Dec 12, 2024 · 5 comments
Open

Porting to a different stack #696

razzeee opened this issue Dec 12, 2024 · 5 comments

Comments

@razzeee
Copy link
Contributor

razzeee commented Dec 12, 2024

Hey @jimmac @allanday @AsciiWolf @mwleeds

I'm currently consider to redo this page with next.js mostly to be able to share components from flathub - but also to get this to a more modern stack, that maybe more (webpeople) can help with.

Please let me know, if that's a direction that's fine with you

@AsciiWolf
Copy link
Collaborator

It sounds like a good idea to me.

You could probably try asking @barthalion to give you push rights (Collaborator status) to this repo.

@barthalion
Copy link
Member

Just keep in mind this is currently a static website so if we switch to next.js it has to work with next export.

@razzeee
Copy link
Contributor Author

razzeee commented Dec 12, 2024

yes, that would be my plan - should hopefully be easier here

@jimmac
Copy link
Contributor

jimmac commented Dec 14, 2024

Personally I don't think flatpak.org is a web app. Even Jekyll can make you waste an hour on dependencies when you come back to a project after a few months to do a 3 line CSS fix.

Tobias changed my mind about using plain HTML+CSS for a website. It really works best long term in terms of maintenance. Short term convenience is really diminished by dependency cost.

I have no experience with next.js though, it might be just fine.

@razzeee
Copy link
Contributor Author

razzeee commented Dec 14, 2024

Tobias changed my mind about using plain HTML+CSS for a website. It really works best long term in terms of maintenance. Short term convenience is really diminished by dependency cost.

While it should be maintainable, I don't think we should optimize for that, we should optimize for users and people being able to find it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants