It’s pretty nice, and open source, and hosted. Not perfect, but it’s very fast because it’s mainly JS and rarely hits the server.
I can see the appeal of using Github issues, since it has more ways of organizing and searching. Although I like the side-by-side view of Stackedit.
Tangent: I need to write a blog post about how “Github Actions” and Gitlab runners and Sourcehut are basically a new style of “container-based shell scripts” (which I like), and written in YAML (which I don’t like).
They’re adding a useful concept to shell scripts – containers and full VMs – but writing them in a really bad syntax…
I really like the idea of stand-alone markdown editors, I have a pretty good setup with my nvim that has a live preview side by side. My biggest blocker with these is drag ‘n drop and copy/paste images don’t work. Just checked stackedit, seems it suffers from the same problem.
That’s one thing that Github Issues gives me “for free” which I appreciate. Ultimately I’d love to end up with a standalone markdown editor that has built-in image handling–not just for drag/paste but also for quick in-line editing like cropping and annotation.
Tangent: I need to write a blog post about how “Github Actions” and Gitlab runners and Sourcehut are basically a new style of “container-based shell scripts” (which I like)), and written in YAML (which I don’t like).
Agree with both of those sentiments! I ran into several subtle YAML-syntax bugs while working on my Action, as is tradition.
Ah interesting, didn’t realized Github drags and drops. Actually I didn’t even know the browser supported that!
But an advantage of StackEdit over Vim is that I can copy and paste links. It turns a rich text link into markdown like:
[anchor](https://example.com/url)
Similar to what github does with images.
Interestingly I just checked, and Github does NOT do that. They only paste the anchor.
Some blog posts are full of links, more than text, so I find this very convenient about StackEdit. But if you have a blog post full of images, Github would be more convenient! (Although I don’t want to rely on it for image hosting)
Yeah the YAML thing is really bugging me. I spent all this time “fixing” shell syntax, making it statically parseable, being annoyed by the 70’s style macro processing of shell-in-make, etc.
And then the new trend seems to be 70’s style macro processing of shell-in-YAML. Making the same mistakes all over again.
And to make it even worse a lot of times you have to push across the network to get your config validated???
Even the creators of these systems are sorry:
I want to go on record: the amount of yaml required to do anything in k8s is a tragedy. Something we need to solve.
(Although I don’t want to rely on it for image hosting)
Agree!
Part of my frontmatterify preprocessing script I mention in the post is to download the Github-hosted images and commit them to the repository so that it’s replicated locally. Admittedly the repo is hosted on Github for now, but ultimately the images are served by Netlify and the source of truth is replicated on all of my development machines.
I’m generally happy with TOML for config files, but I’m keeping a keen eye on https://cuelang.org/ for the future. Statically-checked configs are very appealing.
That’s cool, I like what you’ve done with reusing entire services with shell scripts! I think of Unix and shell in particular as opportunistic reuse!
For example you can reuse “grep” (Boyer Moore), diff, ImageMagick, an entire browser, an entire VM, etc. in a shell script.
But you can also reuse the whole Github UI and file hosting service for your own purposes :) I like to keep things under my control but reuse where it saves effort.
I sort of mentioned this in the last part of my blog, I started “reusing” Travis CI and builds.sr.ht with a portable shell script:
Although it is a very different language, the roots of CUE lie in GCL, the dominant configuration language in use at Google as of this writing. It was originally designed to configure Borg, the predecessor of Kubernetes. In fact, the original idea was to use graph unification as used in CUE for GCL.
I think there is something to making it as easy as possible to write and publish. It seems like devs are very prone to setting up their own custom (ish) workflow, and if publishing is outside of that workflow it’ll happen less.
Oh cool! I think I actually saw Chris (or maybe someone else using it?) present the reverse-engineered Notion Go library doing this exact thing at a Notion meetup.
Has the markdown generated from Notion been fairly reliable for you?
One thing that’s nice with Github’s markdown is that it basically became the de facto standard (commonmark), so Hugo is very happy to consume it and render it properly.
What’s the point of Netlify when GitHub Pages works for static content? Just curious, I have a normal .md files setup with Actions and it works wonders. I like the idea of using issues, I just don’t get the Netlify part.
One thing that caught me when using a custom domain on GitHub Pages is that Hugo needs to deploy a CNAME file that contains the domain name along with the rest of the content. Otherwise, it works.
You’re totally right, and I did use Github Pages for many years. I mainly switched to Netlify for the pull request previews, and to try some of their other cool features like form handling.
I make heavy use of Github issues in my blogs repository for drafting posts; you have gone one step further to use them as a rudimentary CMS. I love it.
This is interesting. I started using Stackedit to draft blog posts:
https://stackedit.io/
It’s pretty nice, and open source, and hosted. Not perfect, but it’s very fast because it’s mainly JS and rarely hits the server.
I can see the appeal of using Github issues, since it has more ways of organizing and searching. Although I like the side-by-side view of Stackedit.
Tangent: I need to write a blog post about how “Github Actions” and Gitlab runners and Sourcehut are basically a new style of “container-based shell scripts” (which I like), and written in YAML (which I don’t like).
They’re adding a useful concept to shell scripts – containers and full VMs – but writing them in a really bad syntax…
I really like the idea of stand-alone markdown editors, I have a pretty good setup with my nvim that has a live preview side by side. My biggest blocker with these is drag ‘n drop and copy/paste images don’t work. Just checked stackedit, seems it suffers from the same problem.
That’s one thing that Github Issues gives me “for free” which I appreciate. Ultimately I’d love to end up with a standalone markdown editor that has built-in image handling–not just for drag/paste but also for quick in-line editing like cropping and annotation.
Agree with both of those sentiments! I ran into several subtle YAML-syntax bugs while working on my Action, as is tradition.
Ah interesting, didn’t realized Github drags and drops. Actually I didn’t even know the browser supported that!
But an advantage of StackEdit over Vim is that I can copy and paste links. It turns a rich text link into markdown like:
Similar to what github does with images.
Interestingly I just checked, and Github does NOT do that. They only paste the anchor.
Some blog posts are full of links, more than text, so I find this very convenient about StackEdit. But if you have a blog post full of images, Github would be more convenient! (Although I don’t want to rely on it for image hosting)
Yeah the YAML thing is really bugging me. I spent all this time “fixing” shell syntax, making it statically parseable, being annoyed by the 70’s style macro processing of shell-in-make, etc.
And then the new trend seems to be 70’s style macro processing of shell-in-YAML. Making the same mistakes all over again.
And to make it even worse a lot of times you have to push across the network to get your config validated???
Even the creators of these systems are sorry:
https://twitter.com/jbeda/status/833408476437110784?lang=en (2017 ! )
https://twitter.com/jbeda/status/1306358044247298049
Previous comment on Oil as a better config language, integrated with shell: https://lobste.rs/s/6oxpe3/s_lot_yaml#c_mje209
Agree!
Part of my
frontmatterifypreprocessing script I mention in the post is to download the Github-hosted images and commit them to the repository so that it’s replicated locally. Admittedly the repo is hosted on Github for now, but ultimately the images are served by Netlify and the source of truth is replicated on all of my development machines.I’m generally happy with TOML for config files, but I’m keeping a keen eye on https://cuelang.org/ for the future. Statically-checked configs are very appealing.
That’s cool, I like what you’ve done with reusing entire services with shell scripts! I think of Unix and shell in particular as opportunistic reuse!
For example you can reuse “grep” (Boyer Moore), diff, ImageMagick, an entire browser, an entire VM, etc. in a shell script.
But you can also reuse the whole Github UI and file hosting service for your own purposes :) I like to keep things under my control but reuse where it saves effort.
I sort of mentioned this in the last part of my blog, I started “reusing” Travis CI and builds.sr.ht with a portable shell script:
http://www.oilshell.org/blog/2020/11/fixes-and-updates.html#buildssrht-and-toil
(Also it seems like frontmatterify should run under Oil… if you have any ideas for improvements in shell, I’m interested as mentioned in the README )
Cue seems interesting, and it looks very familiar because I have a ton of experience with GCL too, the predecessor they mention.
Although the unification angle is interesting and I’ll have to check it out!
https://cuelang.org/docs/about/
Thats a cool way of using Issues and GitHub Actions. Never thought issues as the data source/content management system in Hugo.
I did something similar, but with notion as the backend instead of github issues! I wrote about it here: https://borick.net/articles/my_notion_powered_blog/
I think there is something to making it as easy as possible to write and publish. It seems like devs are very prone to setting up their own custom (ish) workflow, and if publishing is outside of that workflow it’ll happen less.
Oh cool! I think I actually saw Chris (or maybe someone else using it?) present the reverse-engineered Notion Go library doing this exact thing at a Notion meetup.
Has the markdown generated from Notion been fairly reliable for you?
One thing that’s nice with Github’s markdown is that it basically became the de facto standard (commonmark), so Hugo is very happy to consume it and render it properly.
Great post! I’ve been thinking of doing something similar – this seems like a neat approach.
As a meta question, does your site have an RSS (or similar) feed?
Thanks! Yes, it’s buried in the HTML metadata: https://shazow.net/index.xml
I should turn off the reformatting by Netlify so that it’s more readable.
What’s the point of Netlify when GitHub Pages works for static content? Just curious, I have a normal .md files setup with Actions and it works wonders. I like the idea of using issues, I just don’t get the Netlify part.
One thing that caught me when using a custom domain on GitHub Pages is that Hugo needs to deploy a CNAME file that contains the domain name along with the rest of the content. Otherwise, it works.
You’re totally right, and I did use Github Pages for many years. I mainly switched to Netlify for the pull request previews, and to try some of their other cool features like form handling.
Fair enough :) Thanks for the info, I use them as well for a different website.
I make heavy use of Github issues in my blogs repository for drafting posts; you have gone one step further to use them as a rudimentary CMS. I love it.