Well, it is orders of magnitude larger than nano, so...

Seriously? We're going to complain about a couple megs in a text editor in the year 2025?

Yes, couldn’t use on my router because of its size. No reason for a TUI to be so big. Advanced features outside of syntax highlighting not useful. Should have a light version.

I installed nano with CUA keybindings instead.

Like my mother say. Small stream makes huge rivers.

Not caring about a couple of megs here and there is what makes some modern systems so bloated.

Isn't the relatively large binary just because it's written in Golang? Go executables each ship their own copy of the Go runtime. That alone accounts for a big chunk of small programs like this.

Nano also links against ncurses, which is about as big as the compressed tarball for micro. I'm looking at the dependency closures of each right now in nix-tree[1], and micro's closure's total size is 15.04 MiB while nano's is 12.78 MiB-- not really "orders of magnitude" (as a sibling commenter suggests) when you look at it like that.

Admittedly, nano's dependencies (`file` and `ncurses`, on my system) are likely to ship as part of the "base system" of any Linux distro anyway; the real size it adds to any distro is negligible. But there's no indication to me that micro is meaningfully "bloated", as the meme goes; it seems like what is required to run it is reasonable and comparable to other tools that serve the same purpose.

--

1: See: https://github.com/utdemir/nix-tree ; Try `nix run nixpkgs#nix-tree -- $(nix build --no-link --json nixpkgs#nano | jq -r .[0].outputs.out)`

The reason may help understand why but it is not really interesting from the point of view of the user or those packaging it with their OS.