[HN Gopher] Blog with Markdown and Git, and degrade gracefully t...
___________________________________________________________________
Blog with Markdown and Git, and degrade gracefully through time
Author : craigkerstiens
Score : 161 points
Date : 2021-02-08 18:16 UTC (4 hours ago)
(HTM) web link (brandur.org)
(TXT) w3m dump (brandur.org)
| jaredcwhite wrote:
| There is a problem in the CMS industry. Everyone wants to build a
| headless CMS to power Jamstack sites--only the content itself
| lives in databases and the CMS is usually a proprietary SaaS.
| Doesn't leverage Git for content in any way.
|
| This is deeply problematic. We should have dozens, if not
| hundreds of contenders for "the next WordPress" that leverage Git
| as a foundational aspect of content management. Instead we have a
| bunch of Contentful clones (no disrespect to Contentful) with
| REST and/or GraphQL APIs.
|
| It's bananas that if you search for Git-based CMSes you have
| NetlifyCMS, and...wait what? Is that all??? Forestry gets
| mentioned a lot because it's Git-based but that's also a
| proprietary SaaS. I just don't understand it. Is this a VC
| problem or a real blind spot for CMS entrepreneurs?
| lhorie wrote:
| One explanation comes from just looking from the content
| creator's point of view: they kinda don't care what previous
| iterations of the work really look like (draft-
| final-v5-oct27-FINAL.doc anyone?)
|
| The things a content creator might be more interested in aren't
| really core git strengths: SEO, publishing schedules, editorial
| back-and-forth, social media, etc.
| jaredcwhite wrote:
| "SEO, publishing schedules, editorial back-and-forth, social
| media"
|
| Hmm, not really core PostgreSQL strengths either. What am I
| missing?
| lhorie wrote:
| Wordpress isn't popular because of its choice of database
| or any specific technology, it's popular because it's
| feature set is user-centric.
| bobthebuilders wrote:
| Postgres can automatically optimize those things.
| pronoiac wrote:
| I worked on a wiki that fell off the web; I've thought about
| recovering it from scrapes, and rewriting entries so that search
| wasn't needed, so that the Wayback Machine mirror worked better.
| Maybe using Kiwix tools to make a self-contained, downloadable
| backup, too.
| w4rh4wk5 wrote:
| Something that I feel is missing here is the problem with dead
| links. Even if the same content is still available on the very
| same blog, links might change when you decide to change your
| stack.
|
| I might still be able to get around it, but it's still a pain.
| pjfin123 wrote:
| If you want something to live on the web long after you've lost
| interest in it static HTML/GitHub pages seems like the way to go.
| The chess board I built in high school to learn JavaScript is
| still going strong: https://github.com/PJ-Finlay/JavaScript-
| Chess-Board
| magicalhippo wrote:
| Some 15 years ago or so I made a PHP script that took a Word
| document, saved in XML format, and turned into a static HTML page
| as part of my blog. It would rely on the paragraph style, turning
| "Header 1" into <h1> etc, as well as extract images and such.
|
| Lately I've been seriously thinking of reimplementing that, as I
| just can't seem to find a decent static site generator. They all
| seem to require a bunch of plugins and configuration just to do
| the bare minimum a blog requires.
|
| I just want to write, add some code or images, have it look
| somewhat decent and publish it without worrying about getting
| hacked due to some WordPress security issue.
| kemayo wrote:
| Depending on what you think of as "the bare minimum", I'd think
| Jekyll or Hugo would work.
|
| E.g. the Hugo quick start guide is pretty much just "install
| Hugo, pick a theme, add your content" and gets you a barebones
| sequence-of-posts blog: https://gohugo.io/getting-
| started/quick-start/
| magicalhippo wrote:
| The issue with the quick start is that it's a bit too bare
| bones by the look of it, and the documentation for anything
| more complicated gets very confusing by someone new to it.
|
| I'll give it a whirl tho, thanks!
| tristor wrote:
| > I just can't seem to find a decent static site generator.
|
| Maybe you and I have very different ideas of what is required
| to write a blog, but it sounds like you should be able to use
| Hugo + the theme of your choice and just go with it. It's
| /very/ easy, and posts are all written in Markdown.
| magicalhippo wrote:
| Thanks for the input. For me a bare-bones blog needs to
| support simple-to-use images, that is auto-resizing images
| with link to full etc without a ton of hoopla, syntax
| highlighter for code and some tex-ish thing for math.
|
| From what I can see Hugo does seem to have a lot of that
| these days, so I'll try that.
|
| One immediate issue is the highlighter not supporting my
| language at work (Delphi/Pascal) but I assume it being
| Pygments-compatible means I should be able to add that
| without much fuss.
| misterbrian wrote:
| I agree with Markdown + Git. I recently migrated my personal tech
| blog from Jekyll to Nuxt with static generation and the
| @nuxt/content API. I had some difficulties preserving the
| /YYYY/MM/DD/slug.html routes that I had used for my markdown
| files. It is very nice to be able to mix markdown and Vue
| components, but this adds additional work for cross-posting and
| future site migrations.
|
| For example, I recently wrote an article about YC's Work at a
| Startup that contains some interactive visualizations embedded in
| the markdown file I used to draft the content as Vue components.
| If I want to cross post, I'll probably need to maintain another
| version of the markdown that either contains static images of the
| interactive elements and/or links back to my site (on GitHub
| pages).
| android2222 wrote:
| I actually follow this sentiment with my resume andyhablewitz.com
| calessian wrote:
| I run my blog using perhaps the most boring option - Wordpress,
| with close-but-not-quite the default theme (different fonts
| mostly). Outside of adding a cover image on every post and
| occasional footnotes, I don't really need much.
|
| However, that's pretty lightweight on decisions I had to actually
| make to publish, and all the alternatives seem to be more
| involved. I wouldn't mind migrating off WordPress, but just on
| the theming side that has a decent chance of involving a non-free
| theme, making the idea of hosting it on a public repo somewhat of
| a non starter...
| dfinr wrote:
| MkDocs plus Material theme on GitHub pages is pretty sweet.
| Automatic dark mode, useful plugins. I migrated from WordPress,
| no looking back.
| mfkp wrote:
| Do you have an example link of a site running mkdocs with
| material theme?
|
| Edit: I'm guessing it's this?
| https://squidfunk.github.io/mkdocs-material/getting-started/
| byhemechi wrote:
| yeah, that'd be the the one. Not too sure if mkdocs material
| is the best theme to go with for a blog, though.
|
| Here's a site using it: https://docs.libretro.com/
| CameronNemo wrote:
| I cut my teeth on Hugo and mdbook, and mkdocs was a breath of
| fresh air. No crazy templating, no pseudo-markdown index files,
| and lots of flexibility in the site and page structure.
| thebouv wrote:
| Never heard of this but now I'm in love.
|
| Now to figure out what I can write about.
|
| Though I'm definitely going to use this for internal docs at
| work probably. Very nice.
| m463 wrote:
| I wish emacs did markdown in native wysiwyg. I would use it 1000%
| more than I do now.
|
| I only know of emacs markdown where you run an external process
| to view it (and that requires and extra install or whatever)
| ljm wrote:
| This is pretty much how I do it. I built my SSG using Hakyll and
| host the resulting binary on my own Debian repo, that way I can
| write a post in any flavour of text that Pandoc supports (though
| I go with Markdown for simplicity) and within about 20 seconds my
| CI pipeline has built and pushed a new version of my site (using
| scp). Easily done by myself too but at least I know with the CI
| approach that I'm writing to git first and then publishing.
|
| I'm part way through the implementation of showing the commit
| history for each post and linking it to the commit hosted on
| sourcehut. It provides another view on the content the same as
| hosting a gopher or gemini version would: clone it and read the
| things in the posts folder however you want.
| fudged71 wrote:
| Maybe a naive question... But wouldn't it be great for Github to
| have a blog-specific type of repo? With functions similar to
| substack and medium.
| johnchristopher wrote:
| I wish people would stop using github as a swiss knife CDN (free
| hosting, hooks, history through git repo, etc) and build higher
| altitude solution that could leverage git/MD/whatever but with
| free/opensource/selfhosted/alternative tools (like gitea instead
| of github and minio instead of S3 for instance).
| jdsalaro wrote:
| > build higher altitude solution that could leverage
| git/MD/whatever but with free/opensource/selfhosted/alternative
| tools
|
| Not that I disagree with this, but that goes almost directly
| against "Mak[ing] that source public via GitHub or another
| favorite long-lived, erosion-resistant host. Git's portable, so
| copy or move repositories as you go."
|
| Any self-hosted service or solution is going to not be erosion-
| resistant by virtue of not being for-profit.
| johnchristopher wrote:
| Yep, it's just that so far a lot of those tools and solutions
| that hit HN are github centric and I don't see why it can't
| be a bit more generic.
|
| Of course the end-result is easy to move out but the build
| pipeline is more dependent on GH.
|
| Not that it matters but it could be cool too to pipe SSG's
| output through a managed VPS just to show you don't need
| Github to host your static files.
| snow_mac wrote:
| why?
| eevilspock wrote:
| "free/opensource" -> !M$
| chipotle_coyote wrote:
| Setting aside how weary I am of "M$" (it's just about tied
| with using "sheep" to describe Apple users), what on God's
| green earth does Microsoft have to do with the OP's point?
| _GitHub itself is not and was never open source._ It 's not
| like Microsoft bought it and closed off the source. Do you
| think using Microsoft tools demonically injects anti-FSF
| sentiment into your work? ("I started using VS Code, and
| now whenever I try to work on GPL 3 software, my keyboard
| becomes too hot to touch until I close the window!")
|
| Personally, I have a different take than the OP, although
| I'm not sure this is really a disagreement. I would argue
| _open data formats_ are more important in this context. If
| I write text in Markdown, it doesn 't matter whether I'm
| using Emacs or a closed-source, proprietary commercial
| editor; the text isn't tied in any meaningful way to the
| editor. Likewise, a Git repository hosted on GitHub isn't
| tied in any meaningful way to GitHub. It's... a git repo.
|
| As long as GitHub isn't doing anything that I particularly
| object to -- and "oh woe, it is owned by Microsoft" is not
| an objection I share -- there's a pretty good case for
| continuing to use it. I'm taking a calculated risk that
| it's both unlikely to go away anytime soon and to markedly
| change business direction in an unfriendly way, but if it
| does? As long as my local copy is up to date, I can re-
| publish it anywhere and just, well, _stop using GitHub._
| m463 wrote:
| github seems to have a nicer flavor markdown. Maybe it's
| just because github is code oriented.
| johnchristopher wrote:
| Not really, "free/opensource/selfhosted/alternative" [0] as
| in "here this minio bucket that behaves like S3 but you can
| play with it without an amazon bill of death that may or
| may not be coming".
|
| [0] Also, thanksnotreally for cherry-picking and putting
| words in my mouth with your use of `!M$`, screw you too.
| Smaug123 wrote:
| I used to have my blog source on GitHub, but then it turned out I
| didn't want my half-finished works-in-progress public. To use a
| private repository would rather defeat the point; using a private
| repo _and_ a public fork is inviting confusion. Now I just use a
| private repo on my own server, cloned to my dev machine. Does
| anyone have a usable solution for that problem?
| gglitch wrote:
| I have a branch and remote called "publish", and a branch and
| remote called "draft". I suppose if I ever accidentally pushed
| the draft branch to the publish remote, I'd just delete the
| branch from the remote.
| samatman wrote:
| You could set up an integration to automatically reject a
| branch called 'draft', if you really cared to.
|
| Edit: this is easy, in fact: you make a copy of your
| 'publish' branch on the publishing site, call it 'draft', and
| then protect it.
| codazoda wrote:
| I've been thinking about this a lot. I created Ponder so that I
| could quickly create drafts in my browser. Then I planned to
| move them to my blog (Markdown on GitHub) when I'm done.
|
| I need more than 10 drafts (the current limit in Ponder), but I
| feel like I'm getting close to a solution that works better for
| me. I also want to be able to edit across machines (Mac,
| Chromebook, Phone), so I need to make the app work online.
|
| Anyway...
|
| https://ponder.joeldare.com
| darekkay wrote:
| Using git submodules might work, but it's not very convinient
| in my experience. I'm now thinking about having a GitHub Action
| in my private repo that pushes all public posts into a separate
| public repository automatically
| approxim8ion wrote:
| I only keep the output on github. So the generator folder with
| my drafts, posts etc is on my local machine, and whatever
| output it generates is in its own folder that is a git repo.
| wereHamster wrote:
| Stop caring about unfinished, public wip. In the end, nobody
| but you is really bothered by its imperfections.
| Smaug123 wrote:
| I knew someone would say that. It's not about imperfections
| per se; more that I sometimes write stuff that I then
| reconsider and delete before it ever sees print. Admittedly
| nowadays I mostly self-censor that stuff before even starting
| to write it, but a few years ago I wrote a lot more stuff
| that, after reflection, I considered it would be unwise to go
| ahead and publish.
| vbernat wrote:
| I put my drafts in branches and only push the main branch to
| GitHub.
| teryyy wrote:
| going to start doing this!
| simpixelated wrote:
| I personally don't move anything into git until it's close to
| ready. WIP writing is kept on Bear (Markdown editor). But there
| are tons of other apps, including ones that sync to a cloud.
| habitue wrote:
| In terms of extracting the actual blog content from pages, there
| is a go library that implements the readability algorithm:
|
| https://github.com/mauidude/go-readability
|
| This is the kind of thing pocket/instapaper do to extract the
| main content from a page in a format that's easier to read (and
| also probably to programmatically modify)
| intrepidhero wrote:
| For all the (deserved) complaints people have about wordpress,
| it's been around since before git or markdown was even a thing.
| For all its faults, its been pretty resilient to time.
|
| The real reason most websites disappear is a much more human one.
| hobofan wrote:
| Yes, if you constantly update your installation, which is the
| exact opposite of what this blog post is about. Otherwise you
| run a pretty good risk of your installation being hijacked,
| overtaken by spam bots or similar after a few years.
| freedomben wrote:
| Yep. I run a few WordPress sites and the amount of
| maintenance with them is crazy. The plugin model makes
| maintenance brutal too since it's all independent devs with
| different release cycles, testing practices, etc.
| spurgu wrote:
| Following the philosophy of simple hosting + MD outlined in
| the OP then the WP equivalent would be something like a
| simple (official twenty*, or your own custom) WP theme with
| zero (or minimal amount of) plugins. Enable auto-updates on
| WP and you're done.
|
| The more plugins you use, the faster entropy kicks in
| without maintenance.
|
| With WP in general though I definitely agree.
| freedomben wrote:
| Agreed, if you stick with the twenty* themes and keep it
| simple, you can get pretty far with very little
| maintenance.
|
| For simple sites, especially where we don't do comments,
| I've started using Simply Static though to just generate
| pre-rendered pages. All the benefits of static site
| builder with all the conveniences of a CMS.
| hisfastness wrote:
| Wordpress can be configured to receive automatic updates as
| soon as they're available. Plugins are a different story...
| freedomben wrote:
| WordPress core yes, and it's pretty safe, but if you use
| many plugins (which most people do) that gets a lot
| riskier. Premium plugs are pretty safe but still I've had
| stuff break.
| juriansluiman wrote:
| > The real reason most websites disappear is a much more human
| one.
|
| So true.
|
| I have had a blog running since 2006, all was php based back
| then with (html) posts inside a database. The tooling shouldn't
| be a problem, I switched systems several times (once every few
| years).
|
| Currently on Hugo with markdown posts. As long as you treat
| your migration carefully and take some time to migrate, every
| tool should suffice. It's mostly about human effort and human
| error when things get lost.
| jerrygoyal wrote:
| that's exactly what I did for my blog and achieved 90+ on
| lighthouse audit. Google is considering core web vitals to rank
| pages from this year (may 21). I don't want to rely on an
| external hosting provider who usually loads tons of tracking
| code, analytics scripts, irrelevant scripts to hosted sites
| (looking at you Wix).
|
| blog: https://gourav.io/blog repo:
| https://github.com/GorvGoyl/Personal-Site-Gourav.io/tree/mas...
|
| Build with next.js, mdx, tailwind and deployed on vercel.
| Ericson2314 wrote:
| I hope with the IPFS and nix stuff I've worked on, we could
| someday have a world where you can distribute and archive the
| source of a static site, and the thing can be built and rendered
| on demand without tons of security and reproducibility issues.
| gitgud wrote:
| I use hexo, it's a simple structure (git + md) easy to publish to
| a CDN and the src lives on github.
|
| https://hexo.io/
| walterbell wrote:
| Your favorite static site generator can be used with free, no-ads
| hosting at indie https://neocities.org. Their $5/mo plan adds
| custom domains and higher disk/traffic quotas.
| pinjasaur wrote:
| Plug for Blot[1] which makes it trivial to have a directory of
| Markdown source files and supporting assets (images, mostly) for
| my blog[2].
|
| [1]: https://blot.im/
|
| [2]: https://paul.af/
| prepend wrote:
| I think this is an important "feature" but find that people
| either get or don't. When I describe how cool it is that the
| version and history of a post is included in git and therefore
| reliable, I get sort of pleasant nods. But then people will
| fixate on having bullet lists in tables or something and give up
| on markdown.
|
| Not that blog posts are life changing or anything, but having a
| format that's durable and reliable seems important.
|
| I lost my blog from college back in 95 when I got my first job
| and didn't think to archive my shell account. I wish I had, even
| as a memento.
|
| One thing I think that factors into it is that age is kind of
| nice for slowly removing stuff that's not used from existence.
| Posts from 20 years ago might not be good to keep around if no
| one is reading them. No the gradual degradation that comes
| naturally from new phones, computers, hosts, jobs might be a
| feature for some people who don't necessarily want everything
| around forever.
| tomcam wrote:
| At my age, degrading gracefully through time is about the best I
| can hope for
| staysaasy wrote:
| IMO the biggest barrier to blogging (and the cause of most blogs
| dying) is inconvenience, and minimizing that if the biggest
| advantage of Markdown + Git. If there's any inconvenience at all,
| it naturally drags on the process of writing, and writing takes
| enough time and focus that if there's any friction it's too easy
| to push things off to the next day.
|
| My co-author and I use Markdown and Git as the author suggests,
| and one of the best things is that between simple CI/CD pipelines
| and effortless scaling of a static site, we don't need to do any
| technical work so there's no friction on my lifestyle. We've been
| writing for almost a year now, 4+ posts a month, and 99% of that
| "work" has just been writing.
|
| Writing with a partner helps a ton as well.
| WorldMaker wrote:
| On the inconvenience front, I think that also makes it clear
| why so much stuff that would have been blogs, say prior to 2013
| to pick a pseudo-random date [1], is that the convenience of
| various walled gardens got _very_ convenient. It 's really easy
| to post an update to the walled garden social media site of
| your preference (Twitter, Facebook, TikTok, Tumblr, whatever),
| and with network effects really conveniently easy to have some
| sense of readership (even if it just Likes or Faves or
| whatever).
|
| There are some blogs that I realize will never "come back" so
| long as "everyone is on Twitter these days". Because Twitter is
| still so much more convenient that blogs (even ones in Markdown
| + Git).
|
| [1] Okay, not actually random, it was the Google Reader
| shutdown year. Google Reader provided a lot of convenience to
| RSS, including social media-like network effects, that almost
| brought blogs mainstream.
| yhoiseth wrote:
| Love your blog!
| ducktective wrote:
| Anyone have any experience with Hugo? It started out as a fast
| single binary static site generator but it seems it is now
| dependent on Go being installed on the host...
| tristor wrote:
| It's not dependent on Go being installed on the host... I'm not
| sure why you think this is the case. Like most Go applications,
| it's compiled into a single static binary.
| Arainach wrote:
| ....no, it's not? It still works just fine as a static
| generator.
| vhanda wrote:
| Self Promotion: You can use GitJournal [0][1] to manage the blog
| posts from your mobile. It's just a convenient git + markdown
| client on mobile.
|
| I'd built this for managing notes, but it seems that many many
| people use it for their websites. (Including me)
|
| [0] https://gitjournal.io
|
| [1] https://github.com/GitJournal/GitJournal
| allanrbo wrote:
| A bit morbid I know, but I've been thinking I would like my blog
| to outlive me. I have my blog on blogger.com, and while I've been
| tempted to switch to something more modern and fun in a container
| on a VPS, I've resisted, because I think blogger.com is not going
| away in my lifetime. A VPS and a personal domain on the other
| hand is going to get shutdown when someday I die and my credit
| card gets closed. At this stage Github Pages is probably also as
| likely to stick around as Blogger though.
| samatman wrote:
| This reminds me once more of a piece of the puzzle which we're
| still missing. Markdown + git is great, but leaving your blog up
| on Github is just another central point of failure; Github feels
| like a fact of nature right now, but it's just a website at end
| of day.
|
| Most broadly, it's called content-centric networking. Bittorrent
| is a piece of that puzzle, but too static, with no obvious way to
| connect disparate hashes together into a single entity. IPFS and
| Secure Scuttlebutt are groping in the right direction.
|
| There was a project called gittorrent which, as you might guess,
| was trying to be 'bittorrent for git'. It never really went
| anywhere, the crew at https://radicle.xyz are looking to revive
| it and I wish them the best of luck.
|
| What I want is a single handle, such that, if there are still
| copies of the data I'm looking for, out there on the network, I
| can retrieve them with that handle. And also, any forks,
| extensions, and so on, of that root data, with some tools to try
| and reconcile them, even though that may not always be possible.
|
| That would be really powerful. It would made information more
| durable and resilient, and has the potential to change the way we
| interact with it. Like I find typos in documents sometimes, it
| would be nice to be able to generate a patch, sign it so it has a
| provenance, and release it out into the world.
|
| When I browse old blogs which still exist, I routinely hit links
| to other blogs, video, and the like, which are just gone.
| Sometimes Wayback Machine helps, often it doesn't. This problem
| can't be fixed completely, when data is gone, it's gone, but we
| could do a lot more to mitigate it than what we're doing now.
| 0xbadcafebee wrote:
| The longest living websites are forgotten accidents. It's always
| some ancient webserver using _maybe_ a single RAID-1 array of two
| tiny spinning disks, running forgotten software that is never
| ever updated. The uptime on those boxes are not uncommonly
| measured in decades. Somebody 's credit card just keeps gets
| charged $40 a year ($10 for the domain and $30 for the website
| hosting), and the machine never gets touched.
|
| Typically it sits in the back of a dusty rack for a website
| hosting vendor (or, rarely, a colo provider) and the gear has
| long since paid for itself, but also is unmaintainable due to not
| even having the remotest semblance of a service warranty or
| service parts (other than what somebody might have ordered as
| spares years before). If it ever loses power, everything starts
| back up on boot time and it keeps on chugging, defying the usual
| laws of computer entropy.
| chubot wrote:
| This is how the Oil blog is made: it's markdown in git, and it
| renders fine in Github.
|
| I use a bunch of old Unix tools that will be around forever to
| make it look nice: http://www.oilshell.org/site.html
|
| The toolchain has changed significantly in 4+ years. It started
| as literally a shell script invoking Gruber's original
| markdown.pl. Then I switched to CommonMark, etc.
|
| But the core data hasn't "rotted" at all, which is good. Unix is
| data-centric, not code-centric.
|
| Previous thread that mentions that Spolsky's blog (one of my
| favorites) "rotted" after 10+ years, even though it was built on
| his own CityDesk product (which was built on VB6 and Windows). He
| switched to WordPress. Not saying this is bad but just
| interesting. https://news.ycombinator.com/item?id=25675869
| frenchy wrote:
| > The toolchain has changed significantly in 4+ years. It
| started as literally a shell script invoking Gruber's original
| markdown.pl. Then I switched to CommonMark, etc.
|
| Wouldn't switching formats like that break peoples pages?
| That's one concern I have with using markdown for a site like
| this. For anything non-trivial, you either end up using HTML
| (in which case, what's the point) or some dielect-specific
| feature.
| chubot wrote:
| CommonMark solves that problem! It's a precise standard for
| Markdown that multiple implementations are converging on
| (Pandoc, etc.)
|
| _CommonMark is a Useful, High-Quality Project_
| http://www.oilshell.org/blog/2018/02/14.html
|
| At the bottom of this article I note one incompatibility I
| encountered with the reference CommonMark vs. markdown.pl.
| But I just fixed those and have been using it for 3 years,
| and it's been great.
|
| ----
|
| The key point is to have a diversity of implementations, so
| you don't get locked into one, which may go away in 10-20
| years. In 10-20 years, I'm very confident that there will be
| CommonMark renderers available.
|
| (Even apart from the fact that the reference cmark
| implementation I use is extremely compact C with no
| dependencies. C will outlive Perl -- the Lindy effect at
| work! http://www.oilshell.org/blog/2021/01/philosophy-
| design.html#... )
| dharmab wrote:
| I'm using pandoc for my site (https://www.dharmab.com). It's a
| bio/profile, not a blog, but I think it's OK (other than I'm lazy
| and haven't auto-generated smaller resolution images for mobile).
| vitorfs wrote:
| I started my blog about python/django
| (https://simpleisbetterthancomplex.com) using Jekyll and hosting
| on Github Pages and it was pretty good to get started because
| back then I wasn't sure if I would keep it up or not.
|
| After a year or so I migrated to a 5 USD droplet on Digital Ocean
| (back then GH Pages didn't offer https for custom domains) and
| integrated with Github webhooks to automate the deployment when
| pushing new markdown to the main branch.
|
| Over the time it indeed started to degrade. The build time takes
| almost a minute, but after building the website is just a bunch
| of static html pages.
|
| Nowadays it is annoying to write new posts because I like to
| write locally and refresh to browser to check if it's looking
| good or not. So I would say it degraded for me but for the reader
| it's still as fast as it was when there was just a couple of
| posts.
|
| I thought about migrating the blog to something else, but because
| I used some custom markdown extensions for code highlight and
| other things, it would be painful to migrate all the blog posts.
| So I've been postponing it since 2019.
| z3ncyberpunk wrote:
| you do realize you can hot reload and preview in a local
| browser before deploying? pretty inefficient to deploy just to
| check your changes
| dopeboy wrote:
| Side note - big fan of your blog. You're killing it at SEO.
| vitorfs wrote:
| hey, thanks! :D
| Lammy wrote:
| Is it slow to regenerate a single post even with Jekyll's '--
| incremental' mode?
| vitorfs wrote:
| yes because of a bad design decision I made to create a
| custom "related posts", which is a code that searches all my
| markdowns to pick the best pages and add to the current page.
| so even with `--incremental` it take quite some time to
| regenerate
| lostapathy wrote:
| Not really fair to blame the performance on Jekyll, then.
| Presumably you could build yourself to the same issue with
| any other generator.
| Lammy wrote:
| I wouldn't call that a bad design decision if all it needs
| is a `if Jekyll.env == "production"` :)
| emj wrote:
| 20 years ago that was my first useful custom CGI script, it
| took the metadata of the current page and ran a grep for
| pages with similar tags. Running that was really fast and
| flexible until I published it and got my first ten
| simultaneous visitors.
|
| Then I learned about how hard it is to use a cache.
| hinkley wrote:
| There was a company on here the other day talking about their
| product, built on top of Docker. I wish I'd bookmarked it.
|
| Their secret sauce is, effectively, partial evaluation in
| Docker images. They run the code to detect if any of the
| changes in a layer have side effects that require that layer to
| be rebuilt (which invariably causes every layer after to be
| rebuilt)
|
| I mention this because if I'm editing a single page, I would
| like to be able to test that edit in log(n) time worst case. I
| can justify that desire. If I'm editing a cross-cutting
| concern, I'm altering the very fabric of the site and now nlogn
| seems unavoidable. Also less problematic because hopefully I've
| learned what works and what doesn't before the cost of failure
| gets too large. It would be good if these publishing tools had
| a cause-and-effect map of my code that can avoid boiling the
| ocean every time.
| CameronNemo wrote:
| Can't good old make do partial recompilation with ease?
| hinkley wrote:
| Correct me if I'm wrong, but don't you have to formally map
| out all of your inputs and outputs for partial
| recompilation to work?
|
| I believe the last time I touched make was to fix an
| exceedingly badly mapped out chain of cause and effect that
| would consistently compile too much and yet occasionally
| miss the one thing you actually needed.
|
| Partial evaluation works out the dependencies by evaluating
| all of the conditional logic and seeing which inputs
| interact with which outputs.
| jdotjdot wrote:
| Are you referring to LayerCI, possibly?
| themodelplumber wrote:
| Something similar happened to me when I was using static site
| generators. In fact one that I was really enjoying even
| switched programming languages between 1.x and 2.0.
|
| Since that time I look for the people and community behind the
| project, and try to find signs of stability and long-term care.
| After that I look at open formats rather than open and flexible
| architecture-chains. For example, I'd rather use my LibreOffice
| HTML template and simple PHP controller on a more monolithic
| (but open) platform than connect a bunch of technologies
| together to create a build process with a bunch of moving,
| quickly developing, interdependent parts.
|
| Not sure it's the best answer, but it has worked better to use
| more monolithic software, even blogging software that's been in
| steady, if slow development since the early 2000s...
| cpach wrote:
| Just want to chime in that one can use a static site
| generator without upgrading it. Or upgrading it infrequently.
|
| I'm currently on Hugo 0.80.0 and who knows, it might take
| years before I upgrade it.
| themodelplumber wrote:
| That makes sense to me. No dis on static site generators,
| it just so happens that those were the lessons I learned
| while trying them out.
| cpach wrote:
| Don't know about Jekyll but with Hugo you just run _hugo
| server_ in the Git repo and it will give a a live preview that
| you can view in the browser, served locally.
|
| It's very fast.
|
| I have a mockup blog with ~90 pages and it takes 190 ms to
| generate the whole site.
| input_sh wrote:
| Jekyll would probably handle that in a few seconds.
|
| But, once you approach two to four or five hundreds, it can
| quickly add up to a minute or two, making it impractical to
| say the least.
|
| One solution is to run `jekyll build`, which will just build
| HTML to a directory, and then just removing old Markdowns and
| serving those generated HTMLs directly via nginx or
| something.
|
| I've honestly given up and switched to Ghost, where I don't
| have to worry about that sort of stuff.
| wazanator wrote:
| If you use "bundle exec jekyll serve" you shouldn't have too
| much problems locally as it just rebuilds the pages that change
| on every save. A minute to deploy the finished version is not
| terrible by any stretch for a blog IMO.
| spockz wrote:
| I used to think the same until I tried Hugo and it generates
| my site in _milliseconds_. Deploying from there also takes
| less than a second.
|
| It is really astonishing what power our devices have and how
| little that power is utilised by many tool chains.
| ghoward wrote:
| You are spot on. I had the same experience. I wrote about
| it here: https://gavinhoward.com/2019/12/performance-
| matters-jekyll-v...
| bobbydreamer wrote:
| I am using Gatsby for my site https://www.bobbydreamer.com and
| saving the markdowns at git here
| https://github.com/bobbydreamer/bdv32
|
| I haven't setup CI pipeline yet.
|
| It true whats said in the post, I used to save links thinking it
| won't disappear. But most the links, I had saved, it's no more.
| simpixelated wrote:
| I have a similar setup for my blog and I'm using Netlify for
| both CI and hosting (free). It's been great! GitHub Actions
| could probably work well for you if you already have decent
| hosting.
| ketzo wrote:
| Any particular guide or set of docs you recommend for that?
| I've heard a lot of good things about Netlify as far as
| hosting, and I've been wanting to set up a blog; seems like
| as good a time as ever to start learning.
| asadawadia wrote:
| https://blog.aawadia.dev/2021/02/08/where-is-this-blog-
| hoste...
|
| Lmk if you need any extra details
| rendall wrote:
| Netlify is great! Just go to their site, sign in, drag your
| files to their upload window and boom! You have a site.
|
| When you feel you want more, you can link a git repo and
| point a domain name at it. When you update the repo, it
| automagically updates the site.
|
| It's my goto for all new projects.
|
| There is great documentation at every step.
| ketzo wrote:
| The easy git repo is what I was hoping for, that's
| awesome. Ty for the comment, I'll check it out.
| jdsalaro wrote:
| I've evaluated Netlify for my blog at https://jdsalaro.com
| and I'd advise against that unless you're missing a CMS on
| your static site generator. Other than that I personally
| felt it didn't bring much to the table. I do admit that
| their CMS is slick, but it wasn't really a feature I
| needed.
|
| Of course I'm not sure what other people are using them
| for, but in my case GitLab/GitHub covered all my bases
| pretty well since I wasn't looking for a pelican/hugo CMS
| and you still host somewhere else (not Netlify).
| jdsalaro wrote:
| The only middle-way sort of solution I found a long time ago,
| even before joining the company, while looking where to host
| https://jdsalaro.com was to use GitLab, they being open-source
| and quite public about their, now our, values.
|
| Nowadays I'm planning on writing again and have tried a setup
| that seems to be alright:
|
| - migrate from Pelican to Hugo since the community is more
| vibrant, responsive and the themes much more mature and well
| maintained.
|
| - Use a mature, well-maintained documentation-oriented template
| as base (I based https://jdsalaro.com off Pelican's bootstrap3)
|
| - Create an Obsidian vault out of the posts/ directory to
| improve note-taking and editing capabilities.
|
| - Host same as before on GitLab
|
| - Deploy via CI/CD copying the posts/ directory to a public
| repository
|
| - Probably mirroring to GitHub
|
| I'll be able to report back once I've gotten the above fleshed-
| out :)
| cbeley wrote:
| How does having the "BSD Zero Clause" with your content work? I
| open sourced my blog's software, but I still keep all the
| actual content in a separate private repo, since I don't want
| my written content distributed under the same license. Also
| works out well, since I have the github action automation in
| the private content repo.
|
| I can still easily change the private flag down the road if I
| were to decommission it (though, unlikely -- I'd just archive
| it somewhere).
|
| I'm also using Gatsby if anyone is curious
| (https://github.com/cbeley/beleyblog & https://chrisbeley.com).
| zoobab wrote:
| "or fun, I tried "de-archiving" an old colleague's blog from The
| Wayback Machine. Getting the first few pages was easy, but
| getting the whole thing, and with quality/precision, was very
| hard."
|
| Any good tool to extract a website from archive.org?
| gwern wrote:
| https://github.com/hartator/wayback-machine-downloader
|
| (I discuss it on my https://www.gwern.net/Search tutorial and
| use it every once in while eg to make my mirror of 'Climb Mount
| Improbable'
| https://www.gwern.net/docs/genetics/selection/www.mountimpro...
| or 'Hard Truths From Soft Cats'
| https://www.gwern.net/images/hardtruthsfromsoftcats.tumblr.c...
| )
| tristor wrote:
| I've found much the same. I hadn't touched my site in 2 years,
| and just started working on it again and was able to nearly
| seamlessly pick up where I left off thanks to it all being done
| in Markdown. The flip-side is that many of the resources I'd
| previously linked to are gone. I'm starting to take a more
| archival approach to source materials and references as I write
| about them in the future.
___________________________________________________________________
(page generated 2021-02-08 23:00 UTC)