I’ve been using gitea for a number of years - before GitHub started letting people have private repos for free it was about the only option for a self hosted private repo with a GUI. It’s written in Go which makes it very convenient to run from a usb stick. It also has a feature to mirror other repos and I use that to keep local copies of projects I follow - and has saved me a couple times when the project authors decided to delete their repos or YouTube decided to not host them. Today I use gitea to host my private development server as a Tor hidden service which makes it easily accessible from almost anywhere - though many major hotels chains will ban your MAC address locally if they see you connecting to Tor servers, but never had issues while at an AirBNB which is where I spend most of my time these days.
> as a Tor hidden service which makes it easily accessible from almost anywhere
I have a wireguard with the server running on a small VPS, which is useful for both ignoring filtering on public wifi and getting into my home network from wherever.
You can lock down a wireguard vpn server pretty hard, because wireguard itself is essentially invisible unless you know it's there. It doesn't respond to anything but well formed, correctly signed (in the case of connection initiation) or encrypted (for the actual network itself) packets. So conceivably, you can have your vpn server not respond to public icmp, not expose even ssh without wireguard under it, and be essentially invisible to the internet.
If you are not replying to ICMP you let everyone know that you are there. If you we're not there, the error would be 'no route to host', but there is a route, so you must bei there
The VPS is running sshd (pubkey auth only) and Wireguard, and I also see bound UDP sockets for dhclient and ntpd. And that's it, at least for the public interface.
Also, things I want to look at on my home network mostly work fine over ssh (console stuff, git, etc). So I haven't actually gotten around to setting up full routing yet, and use the wireguard endpoint box as an ssh jumphost / bastion (and can forward ports if I do have something to get at that doesn't like to play nice).
I have a similar setup and I was also quite paranoid at first. Wireguard is a very solid solution that does precisely what it claims to do and allows you to layer extra network controls on top of it, so the vpn clients only get routed where you allow them to.
A bit less hands-on solution could be something like tailscale.
One of the benefits to Tor is you don’t need to open any ports, the Tor acts as a reverse proxy for onion services. A lot of Tor services run over port 443 because it gets passed through with little to no issue. With Wireguard you have to deal with all the networks, particularly airports and businesses, that don’t allow UDP. I’ve had a good bit of luck using the dns and ntp ports for wireguard but if your on a network that has something filtering/monitoring dns or only wants you to use their time server, those can stop you also. Once http/3 is official that should make things better for everyone using wireguard.
Plus tor hidden services -or whatever the current nomenclature is- offer a fairly robust and painless story for authentication in this "sorta VPN" scenario. Generate a couple extra keys and invite a friend and his bots.
I do the client auth feature. The chances of someone stumbling across my hidden service is pretty low I think, but it’s not zero. With auth set up I don’t think a Tor client can even get the Id of the rendezvous server without having the correct key.
I think headscale/ other mesh vpns would be better choices so you can get direct connection to your home instead of passing everything through the VPS.
I didn’t leave my apartment for two years because of Covid and decided a change of scenery would be nice, so my family and I have been bouncing around rural AirBNBs for about six months. Though we’ll have to go back in another month - my son really wants to go back to in-person schooling, that is starting soon. But back to the woods as soon as he gets tired of high school life!
Personal choice but indeed Trac is very nice and is still used by high profile projects like Django (especially supporting ticket triage) and Twisted Matrix.
Indeed fossil-scm [1], has same interface as Trac (in my view partly inspired by it). Have used Trac for a long time, so can't complain, it works well, its simple and flexible.
I mean, if we're counting Trac as the same, despite the drastically different UI and project-first rather than code-first focus, then we also need to count Sourceforge, which was open source in its first (2000) and third (2009) incarnations.
Yes, that's when it was included to Trac 1.0 as a built-in plugin. Before that, it was a 3rd party plugin you have to install yourself. I remember using it before 2010 and I'm pretty sure the plugin pre-dates github.
Gitlab is great, but it also is pretty resource hungry. I opted for Gitea for that reason, so it would be viable on the cheapest Linode server option, and I've mostly been satisfied with it, thus far.
Same, there were a number of GitHub like services you could self host but gitea stood out to me as the easiest to install and maintain. A lot of the other options I looked at required multiple daemons, a full database, etc. Gitea can use a full database but works great with SQLite also.
Not sure about Github but Gitlab does. It just creates a new repo under your account when you push to a non-existing one. Seems like a very basic feature to me.
I dislike organizations that take open source things like git, and then extend them to add features making them propriety work flow lock in making it hard to move to a new platform
Another company was famous for this, they used to call it Embrace, Extend, Extinguish
Not sure if doing it that way will create a private repo or not (at the airport and I can’t check), but you can use the GitHub CLI to do it. I’m a huge fan of the CLI, but obviously being able to do it without that is nice.
Gitlab does, as well as gitolite (which is a very lightweight, repository-only solution without a GUI or any of the fancy features like merge requests but it's perfect for my personal needs. Repo creation on push it the main feature that made me choose it. It is administered through git as well which I think is nice).
I recently moved over from self-hosting GitLab to instead having Gitea, Nexus and Drone, because the burden of keeping GitLab up to date was cumbersome, given how it's such a large and complicated software package.
That said, I still find the UI of GitHub and GitLab to be a bit better than Gitea's (the whole organizations/groups navigation feels better), though Gitea is immeasurably more performant when compared to GitLab, especially when the available hardware resources are limited - in the case of 4 GB of RAM being all that I could afford, it's the difference between a really snappy and annoyingly laggy UI.
Admittedly, now it's Nexus that loves eating my resources, though for the most part having software like it for managing most of my container images and other packages is pretty cool and worthwhile, though one might also want to explore the alternatives, such as Artifactory or something else.
Also, personally I find Drone to be a bit less capable than GitLab CI and its documentation isn't quite as good in comparison - though that's a given, since it's an external tool developed by another company. Though I guess even Jenkins would also be a viable alternative (despite it having certain issues with plugin stability etc.), or many other CI tools, given that Gitea is actually decently supported!
In summary, even if there still are a few challenges here and there, the whole setup is a lovely way to self-host your own projects and everything around them in a cost effective manner and whilst also staying in control over your own data. Gitea is an important part of this and overall I'm really glad that we have cool software like it nowadays!
At the same time, I'm more than happy to use GitLab or something like it at work, as long as keeping it working nicely, up to date (and paying for the servers) is someone else's responsibility.
You'll probably be happy to see the 1.17 dev version of gitea (which should be the next major release) actually has an artifact repository built in and it can even host docker images: https://docs.gitea.io/en-us/packages/overview/ You have to build the branch yourself right now though, despite being in the docs it's not in the release downloads yet. You might be able to get rid of nexus and just use this built in registry.
Though a problem that I ran into with GitLab Registry was that sometimes the Docker image cleanup wasn't done properly and old layers kept lingering around and eating a lot of space. I sort of fixed it with some cleanup scripts and the occasional manual actions, but it still was a bit problematic since running out of space was a very real risk.
Nexus does appear to have similar issues, should you use it as an intermediary for CI image builds (e.g. tag it with branch-date and tell your cluster to redeploy the image), but at least it has instructions for cleaning it up that work most of the time: https://help.sonatype.com/repomanager3/nexus-repository-admi...
Personally, I think that using the same software package for storing build artifacts and the source code itself is a bit risky, but maybe Gitea will be able to tackle those challenges with no significant issues!
It probably depends on the scale of your builds, but I’d agree that it seems like a generally better idea to separate your docker image repositories from your source control.
By Drone do you mean the `0.8` open source version? If you've not tried Woodpecker it built upon the `0.8` code and added lots of nice functionality, has better documentation, and is in active development.
Of course, the point about their license is a good one, which definitely has some limitations on what you can do with it: https://github.com/harness/drone/blob/master/LICENSE (I wish I earnt 5 million $ and this would be a problem I'd have to think about).
Thanks for bringing up Woodpecker, though, it also seems like a nice project and the two CI solutions haven't diverged far enough for migrating over from one to another to be too problematic, should that become relevant in the future: https://github.com/woodpecker-ci/woodpecker
Of course, as I said, some folks might also prefer something like Jenkins or another CI solution. I'm yet to explore most of the packages out there!
I wanted to self-host a git server, and because I use gitlab at work, that was my first choice. But the system requirements for gitlab were too heavy for the linode I was running, so I went with gitea. Linode also had a handy install-script to set everything up painlessly.
Mind if I ask how you're hosting this setup, are you using something like k8s or swarm? If so how are you handling persistence, just normal volumes? I imagine if you were to lose data, that'd be pretty bad.
Currently using Docker Swarm with bind mounts instead of volumes, because they're a bit easier to work with, backup-wise.
Infrastructure wise, there are a few VPSes from a local provider (https://www.time4vps.com/?affid=5294 affiliate link), though I've also used DigitalOcean, Hetzner, Scaleway and others in the past, AWS, GCP and Azure would work as well, though would be much more expensive. For executing CI tasks and backing up the data, i have a few servers on my desk (though regular towers with passive cooling, instead of the rack mounted kind), since those are more cost effective, especially storage wise.
The actual files are backed up with BackupPC over the network automatically, at a set interval, to another server: https://backuppc.github.io/backuppc/ Then, of course, the backup server data is occasionally sent to another server in my local network, just to spread it around more, in case of disk failures or one of the servers shorting out.
Admittedly, it's a lot like using regular rsync with cron, although the benefits of BackupPC are being able to really easily restore files, as well as having incremental backups with compression.
Alternatively, one might also achieve the same result with something like Bacula, Kubernetes with either hostPath or maybe even just a NFS mount. Other folks might prefer something like GlusterFS or a similar distributed storage solution, or something like Longhorn for Kubernetes in particular.
Thanks for this, it's interesting to see how others are hosting these kinds of setups. Been wanting to move to it for a while but kube (which I know best) is quite large and the idea of ensuring really solid data backups often has me on edge a bit when not using something like AWS (I have a small server at home I'd use).
> Been wanting to move to it for a while but kube (which I know best) is quite large and the idea of ensuring really solid data backups often has me on edge a bit when not using something like AWS (I have a small server at home I'd use).
One option would be opting for a more lightweight Kubernetes distro, such as K3s https://k3s.io/ or k0s https://k0sproject.io/ both of which have comparatively smaller resource requirements whilst still being certified and compliant.
Personally, I'd also use something like Portainer, Rancher or Lens, but that's just because I like UIs alongside my CLIs that are nice to look at.
You get access to the organizations in which the user is, which is really nice to provide access to other company services based on this information.
A small example, we create users for our customers in gitea and they are only part of the "customer" organization. This automatically get them access to the "customer" worklog as they access the customer area. So gitea is for us the central identity management.
I don’t feel that “Git service” is quite doing it justice. If it were just a Git service, I don’t think it’d have the social features: repository namespacing, user accounts (at least to the extent it has them), issue tracking, pull requests, release management, wiki, watching/starring/forking…
Now as it happens, I actively don’t want any of that stuff for something I’m hosting for myself for my own projects only. I pretty much just want the parts you’d get in gitweb or cgit, but done better (since neither of those is very good; I run gitweb because I wasn’t impressed with either, but gitweb was easier to patch into a more acceptable shape). Is Gitea capable of being pared down to just this? Is there anything else that fills this niche?
Sure Gitea does a bit too much for a single individual, but you don't have to use the additional features. Honestly, the UX of gitweb is pretty bad so even if Gitea has too much, it's still better than gitweb. Who knows, maybe someone will clone a Gitea and rip out all the social features from it.
As regards features, git.sr.ht is certainly lighter than Gitea, but still suffers from various of the same problems because it’s designed to run the show with social operation, rather than just doing read-only publication of repositories that it finds at such-and-such a location. It doesn’t have as much extraneous and undesirable functionality (e.g. no issue tracking), but when setting it up requires PostgreSQL and Redis (which latter I think you may be able to skip, but it’s hard-required in the systemd units I see) and more… yeah, this is not what I’m looking for. Operationally, Gitea is considerably lighter than git.sr.ht, as you can get it going with only Git and SQLite installed.
I've been thinking of making Yet Another Git Repo Browser™ from scratch these last couple of years, with features I've been missing in gitweb and with a cleaner/more familiar UI. Maybe it's time to revive that old prototype.
What issues did you have with gitweb? And what stuff did you patch up?
I like it a lot better than NW/Electron that I've used plenty before. Smaller packages and faster startup but way longer build times, which is a bit of a hassle but it's Rust, so not sure you can expect otherwise.
There are still some bugs around that are a bit of a hassle to deal with, but only one that is a showstopper for me personally (the back button on the mouse doesn't navigate back), otherwise it works out well for me.
Gitea is very easy to use, but I find the Activity feature is a little slow.
I experienced the "Try Gitea" service and migrated our TiDB repo https://github.com/pingcap/tidb to it. When I clicked the Activity tab and selected "1 year" period, I found the page loading was so slow, nearly 90s. And I also found that this Activity doesn't have a Cache, I re-selected "1 year" again, and the page loading was nearly the same time.
I guess Gitea uses git command to traverse all the logs for the period every time. Maybe it can use a database to speed up, or like Github only provide at max "1 month" period.
Could just be because the "Try Gitea" service is just a test deployment, staging environment if you will. I don't think it's optimized in any way at all.
Trying to same on Codeberg, which is a production environment of Gitea, the loading time of the "Activity" page for Codeberg/gitea seems to take ~5 seconds for me. It still seems to lack any sort of caching, but at least it's relatively fast. See https://codeberg.org/Codeberg/gitea/activity/yearly (people might want to be careful hitting that URL over-and-over, in case we ddos the Codeberg folks :/ )
I’ve been running local Gitea for about 4 years. It works great, no complaints here. I mirror my GitHub repos (and sensitive repos I don’t want to trust on GitHub) and back up the hard drives with BackBlaze.
One of my previous companies use their self-hosted Gitea. That's all good and stuff, but they don't have a dedicated DevOps person, so we actually have to spend extra maintenance on it.
Moreover, we were going through SOC-2 auditing at that time and it is much easier to just store our source code in one of the SaaS option like Github/GitLab/Bitbucket for our auditors to check without having me to screenshot everything for them.
I've been happy with Gitea. It's very fast, and upgrades cannot be simpler. Just download the new binary and start it. The migrations run automatically.
If you need a git hosting service but "hosting git" isn't your day job, then the alternatives are way more complex than necessary IMO.
No fan of Discord but from what I remember the functionality is opt-in and if the webhook is not configured it does nothing.
Among all the possible things to get worked-up about this seems like nothing (unless you are purist that considers including optional functionality to interface with a proprietary-service to be harmful).
I've enjoyed using git-ssb (https://scuttlebot.io/apis/community/git-ssb.html), which allows me to save and share git repos using the scuttlebutt gossip protocol. Makes for a nice decentralized solution where I can back up between my machines, and those that I'm working on a project with.
The only problem that I've found is that my github repo now shows very little activity which make job hunting harder.
I have some personal projects on my own public git server that hardly anyone knows about but I still have a second remote for that stuff which goes on my github for the jobs.
Is it possible to hide users listing[1] on Gitea via configuration?
On Gogs it's not configurable and to stop publishing names of all users, including admin account username, it's necessary to either close down the whole service (disable public view of all repos and disable signup) or block certain addresses on proxy level.
I found the Auth bit a bit difficult to parse. I wanted to used Firebase for it but didn’t quite know how. How are people handling user registration and SSO?
How do those Docker-based CI systems support Windows and Mac builders? Aren't you constrained to just Linux? Seems like quite a crippling constraint in a huge number of situations.
At a company I worked at, for security reasons we used gogs. Boss didn't want some random NPM-downloaded javascript anywhere near our source code, which was something which handled enormous piles of money. Gogs doesn't bother with any nodejs at all.
Personally I like even MORE basic than gogs or gitea and use this at my own company:
In the beginning after the fork, gitea added features which I didn't need. Nothing against gitea just thought I'd also mention gogs, which hummed along here fine and if possible I prefer the code from the original author. (Edit, mmh, not always true, I use neovim...)
Can Gitea be configured behind an AWS Load Balancer? I'd like to have the ALB to do OIDC authentication with Azure AD, and also take care of the SSL offloading (so that we can use ACM certificates).
Considering codeberg.org is a productionized deployment of Gitea, I'm guessing deploying a HA version is possible, and you can bet that an LB can be put in front of it. As for SSO, I'm not sure if Azure AD is supported, but some SSO configurations are supported directly in Gitea[0].
For SSO the idea we have is to configure it at the LB ("Authenticate" in the LB rule for an OIDC source which would be Azure AD) and then Gitea would have to look at the JWT in the header to get from there the authenticated user email.
So Azure AD and the AWS LB handle authentication whilst Gitea only handles authorization.
It appears as if the main repo along with issue tracking and pull requests is hosted on GitHub: https://github.com/go-gitea/gitea - At least it looks that way, are issues/pull requests mirrored across to GitHub?
I have to admit, if the GitHub repo is the main source for issues/PRs, it's a bit of a yellow flag that they're not dogfooding it.
That being said - if I didn't need easy CI support I'd probably be using Gitea instead of GitLab CE - GitLab CE is great but it's a resource hog and feels like it's getting slower over the years.
I was curious about this so I searched and found that they started using Github before all the necessary features were ready in Gitea, and they are in the process of moving. The only thing left now to do is actually implement a feature to import content from Github.
I don't think it's a yellow flag. It's hard enough to get contributors for FOSS as it is. Adding the additional hurdle of creating a new account would be counterproductive. Everyone already has a Github account so it's much easier to host it there.
What they really need to do first is copy Gitlab and add support for logging in with Github. Then they could move their repo to gitea without locking out a bunch of contributors (or keep a copy on github and mirror issues/PRs)
Edit: looks like you already can login with github and they're working on migrating their repos to gitea!
is there a way to sync gitea/gitlab issues to github? i contribute to a project that is on gitlab but there is no discoverability. my idea was, if we had a mirror on github, at least people could look at issues, suggest fixes without having them to login to gitlab.
I know gitea can mirror a github repo, not sure about issues or PRs though.
If you're using gitlab or gitea you should be able to allow people to login with github accounts. I used that to raise issues about borgmatic[1] and it was very painless. I believe it's also mirrored on github but issues aren't enabled. Not sure how the maintainer set it up.
That's not a Git web interface, that's a completely different source control system altogether!
And from a quick bit of web searching, it looks like most IDE's out there either lack a plugin for fossil, or else have a plugin that's outdated and doesn't keep up with the current version of the IDE.
I realize that all of these "I Like X!" silly HN threads invite a lot of "I Like Y!" silly replies, but there sure are a lot of caveats on "better" here. You could make a much stronger case for recommending Subversion or CVS, lol.
yes, thank you.But light and self Hosted version control,I have to recommand fossil.Git is not gods,we can blame it and recommand other more better software for special case.
been using it for 4+ years, no complains and it keeps getting better. each upgrade is super simple: just stop the service, replace that one single binary, and start the service.
edit: to clarify. It’s fine for a one man show or a small company. Once you get bigger, you start hitting the various issues quite often, and wish for github again.
It would be generally be a good idea to migrate away from this to something else, I use gitbucket, and it works very well for me.
Yes it is an open source project, but the entire team that works on it is based out in China, and that's really not something you want to play games with.
In that vein, as a European I'm generally more afraid of US. How they can force anyone to give up my secrets. Or the power of Google, MS, Facebook to screw me over.
Has there been any issues because of that, or is this just speculation on your part? The codebase is open source so it's not like they can hide anything.
I am no Sinophobe but I think the pragmatic concern is by being under P.R.C jurisdiction 'certain parties' could either force abandonment of the project by (some of) the original team or compel certain code changes that may not be in the users interest.
No offense to anyone and do not want to imply anything nefarious is about but from what I remember Gogs was even worse in that only a single maintainer inside P.R.C had merge access to the main branch. Also a concern because I might remember something about known vulnerabilities having been outstanding on the issue-tracker when the maintainer was busy.
It's not so much about the issues, but the potential for issues down the line.
For tools like this the aim is always to lay low and expand to reach as far as possible, then once you have a lot of control and trust you can abuse it, often you can abuse it without much loss, because once you have institutional momentum it's very hard to screw it up.
You can't operate on If there's a history of abuse of power, only if there is an incentive. I believe there's a very strong incentive in this case.
All you need to do is sneak in something in an update that gives people access to your server, or creates a vulnerability that allows them to get access.
The fact that itself hosted is actually a really huge concern, because this thing is sitting on your local network with no firewall between it and everything else that you run.
It takes very little to put a vulnerability in a piece of code, and unless you have a person combing every commit with a fine tooth comb, even the fact that it's open source cannot prevent that.
No single security measure is bulletproof. Being open source does not counteract the misaligned incentives.
If it's the entire team or not doesn't really matter, what matters is is that the locus of control, the people who really own the project and commit most of the changes are all based in China.
But you are correct, they do get commits from outside of the country
> Yes it is an open source project, but the entire team that works on it is based out in China, and that's really not something you want to play games with.
China is a country that has been well well known for theft of intellectual property for a couple of decades now, and when the majority of the people developing the project live inside of the borders of China their state has an incredible ability to control the direction of the project and sneak in bad changes over time should they want to.
The fact that it's open source helps a little bit, but I do not believe they number of eyes on the project is enough that they couldn't sneak something through if they wanted to. This isn't Linux with worldwide attention, it's a relative niche.
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.
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.
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.
> 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.
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.
> 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.
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.
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.
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.
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.
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.
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...
https://nlnet.nl/project/Gitea/