4 ms·

I’ll go against the grain and say, Gitea is good but could use a lot of improvement. We use it at my company (startup) and find there are issues with migrations

I’ll go against the grain and say, Gitea is good but could use a lot of improvement. We use it at my company (startup) and find there are issues with migrations (up but no down), nonstandard web framework (go-macaron), and far too much logic implemented in go templates. There are also some strange issues with how errors are reported. Go is a fine language, but Gitea isn’t a great Go codebase. Of course, we/I understand open source software isn’t perfect and such. That isn’t my point, I’m just saying that Gitea could use a complete rewrite, ideally using NextJS (if SSR is that important) or moving most if not all view logic into the client side, ditching go-macaron and xorm for something more widely used, relying less heavily on go templates, and doing error handling a bit better. That said, Gitea does have a good excuse which is that it inherited many of these things from Gogs, from which it was forked.

muhehe 4y ago
I'll go and say a really don't like arrogant comments like yours. Shitting on someone's work you're using for free by recommending complete rewrite in technologies you currently like is absurd. Less used framework - so what. Logic in templates - yeah not great but still, so what? Etc... Doesn't really bother anyone using it.
- ironmagma 4y ago
  There’s nothing arrogant in my comment. Like I said, Gitea is good. Like all other software, iterations improve quality, and I’m just saying it’s time for the next iteration. I probably would have written Gitea the exact same way if I were in the developers’ shoes, but that doesn’t mean a rewrite wouldn’t still be in order. As for the so what, I think the answer is just that things can be better, so if someone is out there reading this thread who has some time, they can see this and know what kind of improvements can be made.
  - muhehe 4y ago
    Suggesting improvements is ok. Recommending complete rewrite in different stack and technologies is not constructive critique imo.
    - ironmagma 4y ago
      Elsewhere on the Internet, someone posted: > If it ain't broke don't fix it? Or is there some specific shortcomming that might justify a rewrite? I’m answering that question. The information is out there, so if people want to ignore it that’s beyond my mandate. But this is still constructive since someone out there wanting to rewrite Gitea will want to know what the pain points are before they do so.
- skrtskrt 4y ago
  Logic in templates is just a classic lack of separation of concerns that makes a project into a ball of mud as it grows
  - muhehe 4y ago
    Does it directly affect users?
    - ironmagma 4y ago
      No, but it indirectly affects users.
- ironmagma 4y ago
  I would also add that I don’t even like NextJS. I’m recommending it because it’s a better engineering choice. I’d much rather see it rewritten in Rust, but that’s irrelevant.
  - muhehe 4y ago
    I really wonder what makes you think nextjs is better engineering choice. (I really do want to know, I don't mean this question in any negative way.)
    - ironmagma 4y ago
      SSR is "fine", but it doesn't need to be this painful. Here's an example buggy piece of code: {{range $i, $file := .Diff.Files}} <div> {{ if $file.IsSpecialFile }} <div>Special file ({{$file.name}}) {{ end }} </div> {{end}} Because of the missing </div>, instead of a list of files, it produces a file listing inside of another file listing inside of another, etc. That's just something you'd never be able to accidentally do in NextJS, or anything that uses JSX-like structure. Then there are clerical things like where to put styles and presentation logic. Gitea uses a mix between jQuery and Vue, with CSS rules sprinkled in randomly. The result is that by looking at the template and the class names on each element, you have no idea whether a class name or ID is going to have significance to jQuery, CSS, or if it's just dead code. Something like styled-components, and use of a single stack (Next as opposed to jQuery+Vue) eliminates the fear and clerical aspect of development.
- kanonieer 4y ago
  It's not just arrogance, it's called being a "modern JS developer". The bubble some of these people are living in is so rigid, they can't simply accept when someone does things differently. Some quotes from the parent are as follows, accompanied with some sarcasm on my end: > nonstandard web framework (go-macaron)... The "standard" is React and Vercel offerings. Get with the times. > ditching go-macaron and xorm for something more widely used... You're only supposed to use libraries that are #1 popularity in their respective category, few weeks of no commits means the library is dead. > I would also add that I don’t even like NextJS. I’m recommending it because it’s a better engineering choice... Yes, you read that right. This is the advice for Gitea: Github, Gitlab, SourceHut all used server-side templates, so much so that latter two are quite useful even when JS is disabled- but the "better engineering choice" (citations sorely needed) is NextJS.
  - ironmagma 4y ago
    > few weeks of no commits means the library is dead. Xorm is so old and disused, it's been absorbed into Gitea and the Github repo is archived as read-only. You get much better capability out of something that's widely used, that's it. I don't care at all about how "modern" something is, if you can't roll back a migration because of your ORM then you have a nonideal ORM. > The "standard" is React and Vercel offerings No, I was thinking Gin or Buffalo. Something that a lot of people use and that's seeing a lot of love, you know... a standard. > they can't simply accept when someone does things differently. Yea, that's why I continue to accept Gitea as a good piece of software. Only people who cannot accept software packages as they are go out, call them "good", and try to get people to understand how it can become even better.
Zababa 4y ago
I understand how migrations issues could be a problem, but how is the nonstandard web framework and the logic in the templates a problem as a user? Maybe it makes it harder for you to contribute to the project (and probaably for other people), thus slowing down the rate of improvement? Maybe other framework have better performance? Not denying your experience, just curious about the consequences of stuff like go-macaron.
- ironmagma 4y ago
  Makes bugs harder to fix/diagnose and new features harder to implement. Yes, there is some UX and performance cost for certain actions if they require a roundtrip to the server. That isn’t my main concern, it’s just the speed of development. For migrations, if a migration fails, you have no way of rolling it back because they only go up and not down. This is just a specific instance of the problem of having less popular dependencies — the bug fixes and new features are less plentiful because there’s not as wide of a community. That applies to xorm and go-macaron.
solar-ice 4y ago
Can you show an example of excessive logic in templates? My experience of Go templates is that they're practically impossible to implement any interesting logic in, so that's certainly interesting.
- ironmagma 4y ago
  https://github.com/go-gitea/gitea/blob/368baf9e77606e5de8bbcda8b0348f1a6fba6d73/templates/repo/issue/view_content/pull.tmpl https://github.com/go-gitea/gitea/blob/368baf9e77606e5de8bbc... Here's a good sample file. The cyclomatic complexity is through the roof: note the variable assignments, function calls, string concatenation, large number of `if`/`else if`s, nested conditional expressions (line 254). I don't even want to know how many permutations of this page are possible...

muhehe 4y ago

I'll go and say a really don't like arrogant comments like yours. Shitting on someone's work you're using for free by recommending complete rewrite in technologies you currently like is absurd. Less used framework - so what. Logic in templates - yeah not great but still, so what? Etc... Doesn't really bother anyone using it.

ironmagma 4y ago
There’s nothing arrogant in my comment. Like I said, Gitea is good. Like all other software, iterations improve quality, and I’m just saying it’s time for the next iteration. I probably would have written Gitea the exact same way if I were in the developers’ shoes, but that doesn’t mean a rewrite wouldn’t still be in order. As for the so what, I think the answer is just that things can be better, so if someone is out there reading this thread who has some time, they can see this and know what kind of improvements can be made.
- muhehe 4y ago
  Suggesting improvements is ok. Recommending complete rewrite in different stack and technologies is not constructive critique imo.
  - ironmagma 4y ago
    Elsewhere on the Internet, someone posted: > If it ain't broke don't fix it? Or is there some specific shortcomming that might justify a rewrite? I’m answering that question. The information is out there, so if people want to ignore it that’s beyond my mandate. But this is still constructive since someone out there wanting to rewrite Gitea will want to know what the pain points are before they do so.
skrtskrt 4y ago
Logic in templates is just a classic lack of separation of concerns that makes a project into a ball of mud as it grows
- muhehe 4y ago
  Does it directly affect users?
  - ironmagma 4y ago
    No, but it indirectly affects users.
ironmagma 4y ago
I would also add that I don’t even like NextJS. I’m recommending it because it’s a better engineering choice. I’d much rather see it rewritten in Rust, but that’s irrelevant.
- muhehe 4y ago
  I really wonder what makes you think nextjs is better engineering choice. (I really do want to know, I don't mean this question in any negative way.)
  - ironmagma 4y ago
    SSR is "fine", but it doesn't need to be this painful. Here's an example buggy piece of code: {{range $i, $file := .Diff.Files}} <div> {{ if $file.IsSpecialFile }} <div>Special file ({{$file.name}}) {{ end }} </div> {{end}} Because of the missing </div>, instead of a list of files, it produces a file listing inside of another file listing inside of another, etc. That's just something you'd never be able to accidentally do in NextJS, or anything that uses JSX-like structure. Then there are clerical things like where to put styles and presentation logic. Gitea uses a mix between jQuery and Vue, with CSS rules sprinkled in randomly. The result is that by looking at the template and the class names on each element, you have no idea whether a class name or ID is going to have significance to jQuery, CSS, or if it's just dead code. Something like styled-components, and use of a single stack (Next as opposed to jQuery+Vue) eliminates the fear and clerical aspect of development.
kanonieer 4y ago
It's not just arrogance, it's called being a "modern JS developer". The bubble some of these people are living in is so rigid, they can't simply accept when someone does things differently. Some quotes from the parent are as follows, accompanied with some sarcasm on my end: > nonstandard web framework (go-macaron)... The "standard" is React and Vercel offerings. Get with the times. > ditching go-macaron and xorm for something more widely used... You're only supposed to use libraries that are #1 popularity in their respective category, few weeks of no commits means the library is dead. > I would also add that I don’t even like NextJS. I’m recommending it because it’s a better engineering choice... Yes, you read that right. This is the advice for Gitea: Github, Gitlab, SourceHut all used server-side templates, so much so that latter two are quite useful even when JS is disabled- but the "better engineering choice" (citations sorely needed) is NextJS.
- ironmagma 4y ago
  > few weeks of no commits means the library is dead. Xorm is so old and disused, it's been absorbed into Gitea and the Github repo is archived as read-only. You get much better capability out of something that's widely used, that's it. I don't care at all about how "modern" something is, if you can't roll back a migration because of your ORM then you have a nonideal ORM. > The "standard" is React and Vercel offerings No, I was thinking Gin or Buffalo. Something that a lot of people use and that's seeing a lot of love, you know... a standard. > they can't simply accept when someone does things differently. Yea, that's why I continue to accept Gitea as a good piece of software. Only people who cannot accept software packages as they are go out, call them "good", and try to get people to understand how it can become even better.

Zababa 4y ago

I understand how migrations issues could be a problem, but how is the nonstandard web framework and the logic in the templates a problem as a user? Maybe it makes it harder for you to contribute to the project (and probaably for other people), thus slowing down the rate of improvement? Maybe other framework have better performance? Not denying your experience, just curious about the consequences of stuff like go-macaron.

ironmagma 4y ago
Makes bugs harder to fix/diagnose and new features harder to implement. Yes, there is some UX and performance cost for certain actions if they require a roundtrip to the server. That isn’t my main concern, it’s just the speed of development. For migrations, if a migration fails, you have no way of rolling it back because they only go up and not down. This is just a specific instance of the problem of having less popular dependencies — the bug fixes and new features are less plentiful because there’s not as wide of a community. That applies to xorm and go-macaron.

solar-ice 4y ago

Can you show an example of excessive logic in templates? My experience of Go templates is that they're practically impossible to implement any interesting logic in, so that's certainly interesting.

ironmagma 4y ago
https://github.com/go-gitea/gitea/blob/368baf9e77606e5de8bbcda8b0348f1a6fba6d73/templates/repo/issue/view_content/pull.tmpl https://github.com/go-gitea/gitea/blob/368baf9e77606e5de8bbc... Here's a good sample file. The cyclomatic complexity is through the roof: note the variable assignments, function calls, string concatenation, large number of `if`/`else if`s, nested conditional expressions (line 254). I don't even want to know how many permutations of this page are possible...