because desktop Steam is technically browser with specific website opened.

The Steam client does use Chromium Embedded Framework for its interface, but there's a lot more to it than just that. For example, Steam Input, Steam Overlay, Steamworks, and Steam Play (aka Proton) which itself is a collection of of nontrivial components.

If you just want an alternative launcher, there is Lutris, but there is no stand-alone Steam client alternative as far as I know.

It might be interesting to see how much functionality could be replicated in an open-source client. Some components, like DXVK and a web engine, are readily available. Others, like Steamworks, are not. SteamDB shows that it's possible to inspect Steam's game repositories, but actually downloading from them without Steam (or steamcmd) might be challenging. Goldberg Emulator shows that it's possible to fool some games into thinking Steam is running, but that's not enough to run games that include DRM.

Anyone attempting this would have to weigh the time they spend reverse engineering and re-implementing against the fact that Steam can always change its internal services, rendering all that time and effort wasted. And, of course, there would always be a risk that anyone using it (without explicit permission from Valve) might have their account banned.

I assume not, but there is a command-line client, steamcmd. I used it the other day when I wasn't near a machine that I had Steam installed on to remotely install FTL on a machine via ssh that I had Steam installed on so that I could copy it to a remote laptop, which I didn't have Steam installed on (FTL is one of the games that doesn't use Steam for DRM)

I'd imagine that one could theoretically slap an open-source frontend on that.

EDIT: Also, graphical frontends aside, it doesn't even have readline/editline support, so running it via:

$ rlwrap steamcmd

...is already throwing a minimal open-source frontend on it that rather improves the experience.

EDIT2: I don't care that much about most of Steam, but I do wish that the downloader portion of Steam were open source so that I could push a patch to let one cap the number of concurrent TCP connections open. Normally, a saturated network connection will tend to allocate bandwidth evenly on a per-TCP-connection basis, and because Steam opens a ton of concurrent connections, it gets the lion's share of the connection...for Steam downloads, which are very much low priority, and which I don't want trying to eat up all the bandwidth.

EDIT3: There's apparently some Linux ncurses-based client that uses library injection to take over the graphical client, but that repo last saw a change 6 years ago, and I'd bet that it hasn't worked in a long time. Looking at steam_injector.c, It looks like it prevents XMapWindow() from running, so it should keep the graphical client from actually doing anything graphical.

The only open source client that I know that worked with Steam is for bridging Steam's chats and notifications with IRC. It's called Bitlbee.

And i've stopped using it a few years ago because IIRC it was a pain to keep the authentication working with Steam. They thought hackers were accessing my account or something like that, and I kept having to disable security "features" just in order to stay logged in.

I assume an open source client not endorsed by Steam would have the same issue.

https://github.com/JosefNemec/Playnite

I do not remember the name, but there was one being developed and the UI was made with QT. I don't know if it used it's own method to download games or was just a GUI for steamcmd.