Codeberg/Community
54
325
Fork
You've already forked Community
12

Idea: Create a Progressive Web App for Gitea #288

Closed
opened 2020年09月20日 15:30:12 +02:00 by lhinderberger · 8 comments

Hey everyone! 👋

I couldn't help noticing that a large number of issues reported on Codeberg are related to requested UI/UX changes, including frontend bugs and customizations.

I noticed that although Gitea does have an API, Gitea's frontend still seems to be mostly server-side rendered, creating hard dependencies between frontend, backend and frontend customizations (such as we do in build-deploy-gitea). That, to me, makes the frontend development process rather hard, requiring good full-stack development skills to be able to make even moderate changes.

I think it would be beneficial for us to make development on Codeberg's/Gitea's frontend more approachable for developers who are specialized in modern frontend development.

Therefore, I want to propose the idea to create a standalone web-based frontend for Gitea that accesses Gitea only using the API, similar to what GitNex does for Android.

Doing so would likely speed up frontend development and lead to UI feature requests being implemented more quickly, making users happy :) Due to a simpler architecture, we also might be able to react to new front-end technologies more quickly.

Lastly, rendering our frontend client-side as a Progressive Web App might improve performance due to better caching and it might take some load off our servers.

The best thing is that this can be developed and tested without affecting our current technology stack and without requiring major changes to Gitea. Only Gitea's API might need some extensions here and there, if we should encounter limitations.

What are your thoughts on this? And are there people who would like to participate in such a project?

I'm happy to hear your feedback, ideas and criticism! :)

Hey everyone! 👋 I couldn't help noticing that a large number of issues reported on Codeberg are related to requested UI/UX changes, including frontend bugs and customizations. I noticed that although Gitea does have an API, Gitea's frontend still seems to be mostly server-side rendered, creating hard dependencies between frontend, backend and frontend customizations (such as we do in build-deploy-gitea). That, to me, makes the frontend development process rather hard, requiring good full-stack development skills to be able to make even moderate changes. I think it would be beneficial for us to make development on Codeberg's/Gitea's frontend more approachable for developers who are specialized in modern frontend development. Therefore, I want to propose the idea to create a standalone web-based frontend for Gitea that accesses Gitea only using the API, similar to what GitNex does for Android. Doing so would likely speed up frontend development and lead to UI feature requests being implemented more quickly, making users happy :) Due to a simpler architecture, we also might be able to react to new front-end technologies more quickly. Lastly, rendering our frontend client-side as a Progressive Web App might improve performance due to better caching and it might take some load off our servers. The best thing is that this can be developed and tested without affecting our current technology stack and without requiring major changes to Gitea. Only Gitea's API might need some extensions here and there, if we should encounter limitations. What are your thoughts on this? And are there people who would like to participate in such a project? I'm happy to hear your feedback, ideas and criticism! :)

In my opinion: I like the current way UI things are handled,

But I'm happy to help out with API stuff just @ping to me

And having Alternative UI's is nice, so user's can then decide what to use

In my opinion: I like the current way UI things are handled, But I'm happy to help out with API stuff just @ping to me And having Alternative UI's is nice, so user's can then decide what to use

Related gitea issues:

https://github.com/go-gitea/gitea/issues/8174

https://github.com/go-gitea/gitea/issues/5937

With all the great work being done on GitNex, it is sad we cannot reuse that...

Related gitea issues: https://github.com/go-gitea/gitea/issues/8174 https://github.com/go-gitea/gitea/issues/5937 With all the great work being done on GitNex, it is sad we cannot reuse that...

Thanks for sharing the links!

Seeing that the Gitea developers seem to prefer Vue.js, it might be wise to use that as the base for the (hypothetical, at this point) progressive web app, to enable code to be shared, where possible.

Also, Vue.js 3.0 has just been released 🎉

Thanks for sharing the links! Seeing that the Gitea developers seem to prefer Vue.js, it might be wise to use that as the base for the (hypothetical, at this point) progressive web app, to enable code to be shared, where possible. <sub>Also, Vue.js 3.0 has just been released 🎉</sub>

With all the great work being done on GitNex, it is sad we cannot reuse that...

While it indeed might be hard to reuse code due to the different technology stacks, we can certainly share knowledge, I think :)

> With all the great work being done on GitNex, it is sad we cannot reuse that... While it indeed might be hard to reuse code due to the different technology stacks, we can certainly share knowledge, I think :)

https://github.com/unfoldingWord/gitea-react-toolkit may be what you are looking for, it is a component library to build custom interfaces on top of gitea.

https://github.com/unfoldingWord/gitea-react-toolkit may be what you are looking for, it is a component library to build custom interfaces on top of gitea.

This is a big project, I'd like to take a stab at it from scratch to improve my frontend skills. Most likely I'll start a PWA git client based on vue 3 soon. Those react components are a good resource, but it uses axios and react. Axios can be replaced with the browser native fetch api directly (I don't like bloat). I've worked with react before and I also like Vue a bit better so far.

This is a big project, I'd like to take a stab at it from scratch to improve my frontend skills. Most likely I'll start a PWA git client based on vue 3 soon. Those react components are a good resource, but it uses axios and react. Axios can be replaced with the browser native fetch api directly (I don't like bloat). I've worked with react before and I also like Vue a bit better so far.

Most likely I'll start a PWA git client based on vue 3 soon.

That is magnificent! If you need a helping hand that knows his way around Vue, let me know :)

> Most likely I'll start a PWA git client based on vue 3 soon. That is magnificent! If you need a helping hand that knows his way around Vue, let me know :)
Owner
Copy link

I don't think it makes sense to track this downstream any more. Relevant stuff for a frontend rewrite and its direction can be tracked upstream at Gitea. I doubt Codeberg will be of any help for this topic if we have our own discussion issue here.

If someone is interested to step up here, please get in touch with the Gitea maintainers :-)

I don't think it makes sense to track this downstream any more. Relevant stuff for a frontend rewrite and its direction can be tracked upstream at Gitea. I doubt Codeberg will be of any help for this topic if we have our own discussion issue here. If someone is interested to step up here, please get in touch with the Gitea maintainers :-)
Sign in to join this conversation.
No Branch/Tag specified
main
No results found.
Labels
Clear labels
accessibility

Reduces accessibility and is thus a "bug" for certain user groups on Codeberg.
bug

Something is not working the way it should. Does not concern outages.
bug
infrastructure

Errors evidently caused by infrastructure malfunctions or outages
Codeberg

This issue involves Codeberg's downstream modifications and settings and/or Codeberg's structures.
contributions welcome

Please join the discussion and consider contributing a PR!
docs

No bug, but an improvement to the docs or UI description will help
duplicate

This issue or pull request already exists
enhancement

New feature
infrastructure

Involves changes to the server setups, use `bug/infrastructure` for infrastructure-related user errors.
legal

An issue directly involving legal compliance
licence / ToS

involving questions about the ToS, especially licencing compliance
please chill
we are volunteers

Please consider editing your posts and remember that there is a human on the other side. We get that you are frustrated, but it's harder for us to help you this way.
public relations

Things related to Codeberg's external communication
question

More information is needed
question
user support

This issue contains a clearly stated problem. However, it is not clear whether we have to fix anything on Codeberg's end, but we're helping them fix it and/or find the cause.
s/Forgejo

Related to Forgejo. Please also check Forgejo's issue tracker.
s/Forgejo/migration

Migration related issues in Forgejo
s/Pages

Issues related to the Codeberg Pages feature
s/Weblate

Issue is related to the Weblate instance at https://translate.codeberg.org
s/Woodpecker

Woodpecker CI related issue
security

involves improvements to the sites security
service

Add a new service to the Codeberg ecosystem (instead of implementing into Gitea)
upstream

An open issue or pull request to an upstream repository to fix this issue (partially or completely) exists (i.e. Gitea, Forgejo, etc.)
wontfix

Codeberg's current set of contributors are not planning to spend time on delegating this issue.
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
6 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
Codeberg/Community#288
Reference in a new issue
Codeberg/Community
No description provided.
Delete branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?