Like the title says, this post was actually sourced from Github; I committed a markdown file to a repo based off this template, and Hashnode's Github integration then published that file as a Hashnode article. You can find a more complete guide to that process here. Conversely, you also have the option to publish from Hashnode to Github as a way to backup your articles.
This is not the first article I've published from Github, but it will probably be the last, at least for a little while. I chose Hashnode for several reasons; one of these was Hashnode's s more developer centric focus and it's more comprehensive suite of tools and integrations - like the Github integration - when compared to more generalist platforms like Medium. As such, I was initially drawn to using Github as a source for my articles; since I already have development tooling and infrastructure in place, the idea of bringing blogging into my already existing workflow seemed like a major productivity boost.
However, I've found that as neat this workflow is, it's not for me. In part, it's because Hashnode's Github integration has a few limitations, particularly when it comes to using Hashnode's other features. For example, if I want to add article tags when creating an article on Hashnode.com, there's a text box with auto-complete that usually several displays matching results, along with how many times that tag has been used (useful information when there are nearly identical tags). To do the same thing in Markdown, I need to refer to this unsorted json file, which doesn't give me any information on the popularity of comparable tags.
It's a similar story when adding a cover image to an article. The website has a modal where I can upload my own image, or search for free images from Unsplash. By contrast, to do that via Markdown, I need to provide a link to an image as part of the frontmatter of the file or upload my own image to Hashnode's CDN and link to the uploaded file. Lastly, if I need to edit a Github sourced article once it's published, Hashnode redirects me back to the source Markdown files.
All of the above issues just slow down my writing. More fundamentally, however, I'm simply accustomed to a graphical interface when writing serious prose. In particular, I like formatting text with a few mouse clicks, and I want to see the resulting look while I'm working in the document. In Markdown, by contrast, you're forced to lookup (or learn) a new set of commands, and when it comes to formatting, the best you can do is to view a live preview alongside the source text. And as sad as it is, I need spellcheck/grammar checking capabilities - try as I might, I still make typos and other mistakes in my writing, and there are probably more than a few I haven't caught in this article.
Essentially, I think it comes down to the fact that I've written a lot in my career, but it's always been in dedicated writing platforms like MS Word - or LibreOffice later - and I'm used to what these platforms offer. While I have some familiarity with markdown, and I'm comfortable writing documentation pages with it, I don't consider myself fluent, and I'm not comfortable writing anything longer.
In fact, I would go so far as to state that longform writing is not well suited to this kind of tooling; I think it's analagous to trying to write source code in Microsoft Word. You can certainly put the right words, characters, and symbols in the right places, but your tooling won't provide you any help with the content, and the end product will probably suffer.
That being said, I admit that everything I've written here is based in my experience, and I could be wrong on one or more points. I believe in choosing the right tool for the job, but maybe that answer is different for different people. And for all the issues I enountered with this type of writing process, I'm still glad the option exists - more options are generally better, and maybe this right for someone - and I'm still glad I tried it.