IN DEFENSE OF MISSKEY
im sick of people on this godforsaken platform who have never as much as looked at a misskey codebase telling me that misskey is terrible for some bullshit reason
javascript on the backend is good
don't fight me on this, i will win. you are scared to use something beyond its original intent. i have a 3 year old straus milk container and it is damn good at storing liquids other than milk. as it turns out, javascript is damn fast at running web backends. its architecture suits well to event-driven glue layers - which is practically what activitypub instances are, wrappers that turn postgres rows into activitystreams-shaped json blobs, and vice versa. it's certainly more efficient than ruby, and way more easy to work with
mfm is good
yeah, it's not a strict superset of commonmark. it doesn't need to be, markdown isn't a real format, and MFM is simply a markup language for misskey. is the function call syntax unique? certainly. is the function call syntax bad? not at all. having to put double newlines between lines just because most markdowns require it would make no sense on a microblogging platform. sometimes, things are unique in a way that makes them specialized for a usecase
the frontend is reasonably efficient
mastodon's frontend is faster and smaller than misskey's, but it is also doing less. misskey has more features than mastodon, even beyond obvious stuff like emoji reactions. misskey hovers around 1.5x the memory usage of mastodon and 0.8x the memory usage of twitter. the time from an empty cache to a loaded profile page is twice as fast on mastodon compared to misskey, but we're talking about 0.5s vs 1s. sure, it could be faster, but it is already plenty efficient when compared to similar social media platforms (and especially when compared to platforms like discord and youtube)
multi-window is fine
misskey's ability to display multiple windows inside the browser is niche, but useful when you need it. from a technical perspective, the cost of having a window open with a note in it is the cost of showing a note on screen, which is to say, very light. opening a new misskey window does not have a noticeable effect on memory usage or performance because the window is just another component, the same as displaying one extra note on your timeline
the rpc system is fine
i swear you show someone the misskey api and they act like they've never heard of a remote procedure call before. yeah, it's all POST requests, so what? is tim burners-lee pinning you down and forcing you to use REST? the misskey api simply doesn't differentiate behavior based on HTTP verbs, it refers to endpoints entirely based on paths, because it is RPC and not REST. stop telling me it's "cursed" just because you've never worked on a slightly exotic production codebase before
redis persistence is normal
some people have claimed that misskey uses redis improperly because misskey expects redis to persist data, and that redis is not meant to persist data. this is incorrect. transient caching is only one of the many use cases of modern redis. persistent job queues are one of the most common use cases of redis, and redis built a whole AOF system in 2010 to ensure stable and reliable persistence
there are plenty of things about misskey that frustrate me as a misskey fork developer - especially one that forked off around misskey 12, before a lot of the refactoring we see in modern misskey - but every criticism i see of it is based on misunderstandings. please, if you are going to hate on something, at least be right about it
1