Closed swyxio closed 2 years ago
swyxio
commented
2 years ago Aaron Francis has a nice looking syntax highlighting API that seems to have a bunch of these features figured out: https://twitter.com/aarondfrancis/status/1561490579095273473?s=21&t=e9tGZTAVWD3LH-PHXsbHuw
sheldonhull
commented
2 years ago You know, this is why I've paused on any next steps, it's a big effort to migrate/choose, and not certain yet what route to take. My current Hugo blog works well, but maintaining over time is probably not the best use of my time as that theme is no longer actively developed.
I've considered doing what you are doing with GitHub issues, which I think is great! However, at the end of the day, despite my love for simple markdown, I've been reconsidering super[dot]so, or other alternatives despite being less powerful, because the authoring friction is reduced. Because Notion can export markdown, I feel it's a reasonable compromise to get my data back out, albeit with terrible naming :-) I'd eliminate clunky shortcodes to do special formatting, and just WYSISWG in essence.
I read that Blocks vs Markdown post in your article as well, and it was a pretty solid case! Thanks for sharing that.
My main concern is most of the stuff like Super.So how difficult it can be to migrate existing content, maintain backwards compatibility, and deal with missing features that seem obvious to a development audience. RSS, Redirects for renamed posts, front-matter/slug control to help ensure metadata correctly set.
Considering I don't make money on my blog, it's perhaps not as much of an issue as I'd think. The benefits of reduced friction might make up for it. I think it's serverless, and updating content is nearly live after editing in Notion, with seconds to your website being updated. If I'm willing to give up simple text and move to block based editing, I'd probably benefit long-term in writing with such low friction.
Obsidian is tempting, but sorta comes back down into role your own solution, unless you use Publish, which is way to expensive for a personal dev blog. They also have a separate licensing requirement if you use on a work system at all, which is a frustrating restriction.
I'm also experimenting with Front Matter as a VSCode driven way to make things nicer to author. Still prefer blogging with Typora, but it bridges the gap from cli driven blog actions to a nice dashboard.
I wish Gists as a blogging mechanism had become more popular. They are too hard to discover, and lack enough control.
However, GistLog/Gist oriented blogging seemed like a perfect solution for developers, if it had only been built on better.
sheldonhull
commented
2 years ago @sw-yx comment with headers broke your comment formatting, sorry! Also the heart/like reaction at the bottom near my name results in a hyperlink to the api json, not to the comment on github. 👋🏻
swyxio
commented
2 years ago whoops... @sheldonhull PR welcome, not gonna take a look at it right now but appreciate the report
tags: advice, writing category: essay cover_image: https://user-images.githubusercontent.com/6764957/185814244-3e698a67-0827-45bd-986d-0c1d419b0fbb.png
Bottom Line Up Front: You are probably underestimating how much goes into blogging technology these days.
Reader Experience
target="_blank"orrel="noopener"to linksAnd everything should look great on mobile devices and (at least not horrible on) ultrawide monitors.
Web performance is of course a huge part of the reading experience but I've put it in the section below for even spacing reasons.
Author Experience
Distribution/Reach
<img loading="lazy" />Developer Experience
This is often tied with the debate about whether or not the blog should be Jamstack - mostly statically generated and hosted on a CDN, or traditionally mostly generated on request and cached for some amount of time.
Misc
Context
It is often said that one of the best ways of learning a new language, from Ruby to Rust, is to implement a static site generator (fun fact - it was actually my take-home interview for Netlify!). Depending on the requirements, it forces you to learn everything from filesystem access, making network requests, parallelizing code, parsing configs, using libraries, creating plugin systems, injecting javascript, writing a CLI, and deployment.
Because there are accordingly so many static site generators, most people tend to devalue them, in the "I could build this in a weekend" sort of way, and end up building their own blogging platforms every few years as a way to "stay sharp". But that's a very 90's view of blogging technology - and the requirements of a modern Blog has diverged a lot from the basics of static site generation in the past 30 years. In the end, your readers have a poorer experience and your blog may not get the reach it might deserve.
I of course am no exception to this, being maintainer of my own small blog template for the Svelte ecosystem. I am intimately familiar with the modern dev blogging platforms like Dev.to and Hashnode, and these days spend plenty of time reading the many Data Engineering Substacks, and only appreciated how much they do for us that you should not handroll (or should consider building if DIY, because it is genuinely such a good feature).
This is an appreciation I only arrived at after ~5 years of constant blogging, so I figured I should write down what I see as "table stakes", for you to appreciate when considering your next great blogging platform, without trying to sell you any particular solution.
For what its worth, I do think most people, even developers, should not handroll their own blogs and should try to use Devto/Hashnode/Substack (Wordpress is of course an option) accordingly, because most people get so caught up in being PM + Dev for their handrolled blogging software that they never get to the writing. Try to do, say, 20 straight weeks of regular blogging, to prove that you are actually going to be a blogger, before you spend a bunch of time coding up blog software you end up not using.
The most important feature of a blog is its content - if you write good content, people will overcome almost any hurdle to come and read it. Don't forget that.
{% twitter https://twitter.com/markdalgleish/status/1108433814647300097 %}