Which web framework should Gitea switch, Gin or Chi?

[lunny]

I have sent an expirement PR to switch from Macaron to Gin #7177.
But I know some body wants to use Chi (@tboerger @vtolstov).
So I think a vote is meaningful, but I have to say this will not decide which one we will use finally.

👍 Gin

❤️ Chi

[mrsdizzie]

If there could be a list of reasons why one is better than the other for Gitea from anybody who has an opinion/experience with them that would be helpful!

[tboerger]

For those who want to know the differences if they do not already know that: Please look at the code, look at the examples!

I personally prefer Chi because it includes lesser magic, is more idiomatic Go, is simple as the stdlib with some additional sugar. That's why I fell in love with it and using it for all my projects.

[vtolstov]

Agree with @tboerger chi is powerful like gin, but simple as stdlib.
About performance i think that both have good enough for gitea.

[appleboy]

See the all router benchmark results.

[zeripath]

Ok, I think we need to be clear about what we think are the problems with macaron, what we use in macaron and what we would like to use in future. There's a cost to every framework not just in terms of performance but in terms of refactoring and architecture and we should be careful about what we choose to do.

If it's just a case of macaron is dead so let's move off it then we should consider a fork or even drop to basic go. If it's a case of macaron makes poor architectural choices then that's a better reason to move but it will certainly cost and we should be certain that we want that architecture.

[zeripath]

Problems I see with macaron:

• One maintainer model
• Questionable escaping and previous security practices
• Panic in init if working directory not readable (!)
• routes.go is handwritten and has to be updated manually - it would be excellent if this could be generated
• Encourages manual URL writing - this tightly binds our URL structure to the current form.
• JSON encoder actually stores object completely in memory before generating response which is also stored in memory before being transmitted.
• i18n framework has a number of issues - the biggest being a requirement to list which languages are available and then panicking if you get it wrong.
• I had to rewrite the gzip handler
• I had to bodge the session handler
• Architecture likely caused template helper to become the monster it is today.
• Architecture likely caused the structure of our special rendering architecture to become the way it has.
• There is an intermittent bug with uploads that we have been unable to find or fix. This might be go related but is hopefully fixed in other frameworks.

[coolaj86]

Better URL Branding

While this is being reworked I'd suggest considering how to have personally branded URLs.

Project URLs

Instead of

• https://code.example.com/exampleco/my-project

Being able to have

• https://code.example.com/my-project

Forks

Instead of

• https://code.example.com/otheruser/my-project

perhaps forks could be handled as

• https://code.example.com/my-project/forks/otheruser (I think I like this the best for branding)

or

• https://code.example.com/forks/otheruser/myproject

or even

• https://forks.example.com/otheruser/myproject

Reasoning

I think the aspects of ownership and control are what draw a lot of people to platforms like Gitea - personal. However, it doesn't make a lot of sense to me to always have "organizations" in the traditional sense of what GitHub and GitLab do, for self-hosted git platforms. It should be possible to have more controlled branding.

Also, as a service offering, branded Git would be unique.

[tboerger]

I dislike changing the url schema, I'm organizing a lot based on orgs.

Beside that, this is not related to choosing one of the frameworks.

[coolaj86]

I'm not saying that it should be the default for everyone. I'm saying it should be possible.

If all of the URL routing is being rewritten, it's an absolutely perfect time make it flexible to allow for prettier URLs.

[lunny]

We should keep URL compatible on 1.x even if we changed a web framework. It will broken all the references.

[coolaj86]

I'm not saying that it should be the default for everyone. I'm saying it should be possible.

[sapk]

I would say gin because I have better experience with it and like it but the big deps for msgpack and protobuf are kind of bad currently. I haven't use chi so I can't comment on it.