[HN Gopher] Why You Should Write Your Own Static Site Generator
___________________________________________________________________
Why You Should Write Your Own Static Site Generator
Author : abahlo
Score : 138 points
Date : 2023-11-03 09:10 UTC (13 hours ago)
(HTM) web link (arne.me)
(TXT) w3m dump (arne.me)
| aosaigh wrote:
| A fun experiment I'm sure but it's not a very convincing argument
| for writing your own generator. In the same way the author claims
| frameworks will change, so will the tools that power their custom
| solution and using a framework will take a fraction of the time
| to get going.
| BeefWellington wrote:
| This isn't really all that true and is highly dependent on the
| stack you want.
|
| You can run Java from 1.1 on modern JREs. PHP from the early
| 2000s can still work. It all depends on what your stack looks
| like. If you're using the highly unstable "everything moves
| fast and constantly breaks" newer stuff, then sure. It's hard
| to see Python 3 breaking within the next 5-10 years, after how
| well the 2->3 changes were received.
|
| I'd wager though even with newer languages, if you wrote
| something in Go, Rust, Kotlin, etc. today, it will still
| function in a decade.
| jslaby wrote:
| I have a .net 2.0 app still running with installs that I
| haven't touched in over ten years.
| mo_42 wrote:
| > [...] but most importantly you have to architect your website
| to match what the framework expects.
|
| I guess that's what a framework is about. You get some
| abstractions that make your life easier and you pay by buying
| into the concepts.
|
| > [...] some friends I've talked to where still on Next.js 12 and
| really felt the pressure to upgrade to not fall behind even more.
|
| If the current version is doing its job, why update? It's a SSG
| not a browser that connects to the internet.
|
| So I disagree. I'll not write my own and keep the existing one as
| long it's not too much hassle.
| imadj wrote:
| > If the current version is doing its job, why update? It's a
| SSG not a browser that connects to the internet.
|
| Because it's a hassle and you'll be left behind when you need a
| new dependency or there's a feature you like. By then, you have
| years of updates behind including depreciations, conflicts,
| etc. It might turn to a full-blown migration. All that is much
| easier if you update along.
| ramesh31 wrote:
| I've never understood the point of these things. Just use a solid
| CMS and cache to s3 or Varnish. What's the big deal?
| Manuel_D wrote:
| The deal is that a lot of static site generators are very
| complicated (perhaps needlessly so), despite the fact that
| static sites are technically very simple. Perhaps some people
| really leverage the power of Next.js, but when I tried it, I
| felt that it was super heavyweight when I just needed to
| template html files.
|
| Of course, that doesn't mean I need to write my own. I just
| used a simpler SSG. In my case Jekyll.
| robertlagrant wrote:
| NextJS is far more than an SSG; it's a general-purpose
| Java/Typescript app development framework for frontends and
| backends.
| WA wrote:
| Being able to deploy a bunch of HTML files to static hosting
| services, no runtime like PHP etc. required.
|
| If you use a CMS, it has to run somewhere. If you don't want it
| on a server, you probably don't have the same config on your
| dev machine. Most CMS require you to configure root domain
| paths etc. and they are different on your local machine. It's
| all a lot more complicated than using an SSG to transpile a
| bunch of markdown files to HTML on a dev machine and upload
| them.
| jonfk wrote:
| I prefer using markdown files in a repo and generating my
| website using a SSG, because I find managing plain text files
| and a simple CI/CD pipeline to deploy easier to manage. The
| tooling for writing is my editor of choice, deploy is a git
| push and I don't have to run a server or long running process.
| I can also easily migrate to any type of hosting more easily. I
| can see someone who is more used to Wordpress for example
| finding your workflow easier. It really mostly comes down to
| personal preference and what tools you are used to.
| hoofhearted wrote:
| How do you feel about this attempt at creating a better
| WordPress that we have been working on?
|
| It uses Git and Markdown for easy deployments to your
| serverless CI/CD pipeline just as you described.
|
| I'd love your feedback :)
|
| https://github.com/elegantframework/elegant-cli
| c16 wrote:
| I wrote my own one also. It's ~100 lines of Go, generates the
| raw html that I commit to Git and which CloudFlare Pages
| automatically then deploys from a sub-folder for me.
|
| I don't need to set up S3, Varnish, a server, a database,
| making sure my server + cms is up to date. It costs me $0, it's
| on a cdn and it's lightning fast + no headache. What's not to
| like?
| lawn wrote:
| Hosting a static site is simple and can even be done for free.
|
| Even though you can make a CMS fast, with a static site you can
| forget about performance altogether.
|
| Finally, it meshes very nicely with editing files in eg
| markdown locally, which for some people (like me who live in
| Neovim) is a much nicer experience than editing things in a
| webpage.
| jwells89 wrote:
| Cheap/free static hosting is plentiful, static sites don't have
| packages I need to keep up to date to avoid vulnerabilities,
| and writing posts/pages in a format like Markdown makes them
| dead simple to migrate between systems. Additionally, using a
| service like Netlify or GitHub Pages affords flexibility -- all
| I need is a git client, a text editor, and an internet
| connection that can manage to transmit a couple of kilobytes.
| Don't even need a browser.
|
| Aside from that, a CMS is overkill for something like a simple
| blog. I might consider one for a more complex site but for a
| blog there's no need.
| BeetleB wrote:
| No maintenance.
|
| When I had a dynamic blog (DB backend, etc), I got hacked
| because I wasn't updating the SW often. Not having to worry
| about things like that is a significant quality of life
| difference. I want to run my life, not have my tools run them.
|
| But frankly, let's invert the question. What exactly is the
| benefit of using a CMS vs an SSG like Pelican? After having
| used the latter for over a decade, it's dead simple. Open a
| file. Write your content. Run make. And publish. It's trivial
| to back up. I don't have to know what a cache is. I don't have
| to keep updating SW. What is the actual benefit of a CMS for a
| single user like me?
| h2odragon wrote:
| Did an SSG last month.
|
| I had used pelican before; but I wanted to get a better handle on
| using Markdown and Jinja libraries "from the other side" as well.
| I would have needed to adapt my file structure or write some code
| to let pelican scan my idiosyncratic hierarchy to generate the
| posts.
|
| Turns out Markdown is easier to use on your own scripts, than it
| is to tweak its configuration in pelican; and Jinja is quite
| simple too. Getting to use the "debug" feature to dump everything
| available to a template is nice.
|
| I haven't bothered with RSS or sitemap yet, but i did do a nice
| calendar view render of my archive indexes; which i don't think
| could've been easily wedged into pelican's notion of how sites
| work. https://snafuhall.com/news.html
| BeetleB wrote:
| I know people write SSGs because of frustration with their
| existing one, but did you consider writing a tool that
| "publishes" to Pelican? That's kind of what I do: I write all
| my posts in a single org file, and have Emacs process them and
| output rst files for Pelican's consumption.
| h2odragon wrote:
| I did consider that; but I had other nebulous project ideas
| that benefit from getting better hold of Jinja, especially.
| Those ideas have grown considerably now, I'm glad I did my
| SSG, its given me more confidence in those notions.
| abdullahkhalids wrote:
| I have used pelican for my website for a decade now.
|
| I also host my book-draft on my site. I initially tried to
| get Pelican to do it, or to write something that publishes to
| Pelican, but it just didn't work. I ended up writing a
| hundred lines of fairly simply python to do the same job.
| eatonphil wrote:
| I used various SSGs for a while but the SSGs kept having
| arbitrary breaking changes that took a while to debug. I switched
| to my own little Python script 6 years ago and have slowly
| evolved it since then. Hasn't broken yet.
| frizlab wrote:
| For Swift there's https://github.com/JohnSundell/Publish which is
| a framework to create a static site generator. It's really good.
| heeton wrote:
| I mean, really, you should write your own static site generator
| framework.
| adrianmonk wrote:
| > _Plus, you get to choose your own stack. Want to write your
| content in AsciiDoc? No-one can stop you!_
|
| I wrote a static site generator once. I used a Makefile and m4
| macros!
|
| Yes, it's true: nobody could stop me. It's much more debatable
| whether the "you should" part applies. I was just trying to get
| some common header and footer HTML into all pages of a site and
| do it with tools that were already installed on the hosting
| provider's machine.
|
| It worked. For some reason, the person who took over the site
| after me did not follow in my footsteps and keep using m4.
| johnchristopher wrote:
| > For some reason, the person who took over the site after me
| did not follow in my footsteps and keep using m4.
|
| Shame...
|
| Anyway, my first and only SSG was based on Atom for storage,
| PHP for backend and XSL for client side rendering.
|
| We called this flat file CMS which was the style at the time
| and...
| gorgonical wrote:
| This is presently how my website works. I'm no webdev so I'm
| probably committing all sorts of heresies, though. I use m4
| macros to build the header/footer structure with links and
| coloring and whatnot. Then the content pages are emacs Org
| files I publish to HTML and include with the m4 macros. You can
| do a surprisingly large amount with Org Export.
| hombre_fatal wrote:
| It's a fun project to try out new tech, but you have to
| acknowledge that you're doing it for fun rather than any sort of
| necessary reason. It's like when you build a game engine and
| never get around to doing the hard part: building the game.
|
| It's a procrastination time hole that mostly just distracts us
| from the harder, less concrete, less fun thing we supposedly set
| out to do in the first place. It keeps us from shipping real
| shit.
|
| e.g. Quit dicking around with your SSG and write the damn blog
| post already. The hard part of writing something worth reading is
| not your tech stack.
| ttymck wrote:
| Fun, learning something new, unlocking additional productivity
| in authoring posts from a customizable templating engine... I
| can easily convince myself of necessary reasons ;D
| swatcoder wrote:
| > e.g. Quit dicking around with your SSG and write the damn
| blog post already. The hard part of writing something worth
| reading is not your tech stack.
|
| Alternately, for many, there's more value to themself and
| everyone else if they grind on those technical skills rather
| than distract themselves with a hobby they seem inclined to put
| off.
|
| If you really want to write, you'll write. If you really want
| to hack, you'll hack.
|
| A lot of people think they _should_ write, but actually just
| want to hack. And that 's not a problem! The _image_ of writing
| provides some orientation to the hacking, but it 's the hacking
| itself that can be most fun and enriching for them.
|
| Do the hacking, and if you never get around to the writing,
| don't sweat it. If you're honest with yourself: it was never
| really about that, was it?
| imadj wrote:
| > The hard part of writing something worth reading is not your
| tech stack.
|
| This project isn't about blogging, you need to look at it from
| a side project pov.
|
| I think this is a common misconception, that these people want
| to write a blog post but are failing or procrastinating when
| they don't have to. When in reality, these people are
| developers and makers who look at their personal website from
| tech community's "little corner on the internet" pov.
|
| They feel frustrated with the solution and feel they can
| develop better-tailored one for themselves. Putting out blog
| posts isn't a priority or a concern for most of these
| developers. They're passionate about their tools. They make
| tons of side projects. They're not wasting time. They don't
| necessarily have a more important post to write about.
|
| If you're looking at it from a blogger/writer's perspective,
| sure that's wasteful, but, again, that's not what this is
| about.
| SoftTalker wrote:
| > It's a procrastination time hole
|
| Yep. You also see this often in small companies/statups that
| would write their own ticket systems and internal
| administrative intranets before they even had a product.
| Tao3300 wrote:
| My grandfather used to talk about most hobbies this way, until
| he got a little older and mellower in his later years.
| nextlevelwizard wrote:
| As long as you use a static site generator instead some bloated
| blogging platform with tons of scripts and a database.
|
| If you write about tech and your site doesn't load instantly
| why should anyone read your words since you obviously don't
| care
| matheusmoreira wrote:
| Thanks. As someone who's prone to getting hopelessly
| sidetracked in projects, I needed to read this. I ended up
| forking and customizing pug into my own templating language!
| icyfox wrote:
| I'm not sure I'd advocate for writing a static site generator,
| although I'm certainly guilty of writing a few myself.
|
| Instead I always encourage people who are trying to start
| blogging to do the writing first. Figure out a workflow that
| works for you - what time of day you prefer writing, what editor,
| do diagrams naturally come up in your thought stream, etc. It's
| way easier to get this workflow dialed in when you're doing
| things locally since the switching cost between solutions is that
| much lower.
|
| Only when you know that you A) enjoy writing and B) have
| something worth sharing should you invest the time in translating
| your workflow to something that can deployed. That might mean
| writing your own SSG - that might mean just spinning up a
| wordpress blog.
| deepspace wrote:
| > I'm certainly guilty of writing a few myself.
|
| So am I. My first one was written in C in 1995, and the
| resultant site run under NCSA Httpd. DIY-ing becomes tedious
| after several cycles, though.
|
| On the other hand, my experience with generally available SSGs
| has been miserable. They keep breaking my site after a few
| upgrades. At this point, I am very close to just spinning up
| wordpress for a new site.
| tlavoie wrote:
| Well, that gives you more opportunities to have to update
| plug-ins and dodge vulnerabilities. Maybe a ton of people are
| a good fit for core WP these days, but I can't imagine the
| overhead of knowing what to update beyond the auto-updating
| core if there are a bunch of extensions.
|
| I admin a local org's WP site, because someone has to, and
| thoroughly appreciate the SSG that I use personally.
| madduci wrote:
| Exactly. So writing your own generator doesn't differ from
| using a simple tool. At some point also this solution might not
| be robust enough.
|
| Surely you can learn a lot in the process, but how much time
| does it need?
|
| It was probably the author's fault to select NextJs for it.
| Maybe something simpler like gohugo might have been better: the
| tool is just a binary file, that doesn't require extra
| dependencies.
| miroljub wrote:
| But if you write a static site generator, you can blog about
| it. And that can be the first and the last post of your blog.
|
| If you don't write one, the chance is good, your blog would
| stay empty.
| valianteffort wrote:
| Why are you personally attacking me like this?
|
| In all seriousness does everyone and their mom write a static
| site generator? I did because its fun and easy. Off the shelf
| ones can be cumbersome and not work quite how I want them to.
| wormius wrote:
| I've thought about it only because I hate having to figure
| out someone's frameworks and way of doing things.
|
| I'm not a professional programmer and it feels like most of
| these are for people who already work with various
| frameworks professionally and know their way around these
| things. I am too old to spend time trying to figure out all
| the frameworks so I'd rather just whip up something with my
| half-assed skills and DIY.
| ReactiveJelly wrote:
| I made one for a single page that I wanted to template
| nicely without introducing dynamic pages (wasteful since
| it's always the same file anyway) or JavaScript (wasteful
| since the layout is always the same anyway)
|
| I'll probably do another one again soon, just so I don't
| have to rewrite my HTML / RSS by hand to publish another
| post.
|
| Lua is a nice data language, so I just put the data and the
| code and the HTML fragments into one Lua file, no more than
| 200 lines. No worries about injection since it's all my
| data with no backend code at runtime.
| lagniappe wrote:
| > Off the shelf ones can be cumbersome and not work quite
| how I want them to.
|
| This is why I wrote mine! You just put all your markdown in
| one folder, run it, then collect your HTML in another
| folder.
|
| https://github.com/donuts-are-good/bearclaw
| matheusmoreira wrote:
| > Off the shelf ones can be cumbersome and not work quite
| how I want them to.
|
| Yeah, that's exactly why I reinvent wheels!
|
| I ended up forking an existing templating language and
| customizing it into a static site generator. I'm not sure
| what's more difficult: changing other people's code or
| doing it from scratch.
| ozim wrote:
| You forgot 3rd option maybe hardest - just using other
| people code and understanding it instead of misusing it,
| calling it crap and going to write ones own broken thing.
| ;)
| ralferoo wrote:
| Also, every 2 years post "I've neglected my blog for a long
| time, but that's about to change now!" ... and then another 2
| year silence.
| mbajkowski wrote:
| Guilty as charged, many times over. Sometimes, to the point
| where I could not even recall the old workflow post login.
| arendtio wrote:
| Sounds like you are the visitor my blog had?
| kqr wrote:
| I agree. I also wrote two static site generators, two dynamic
| ones, and used a few prefabricated solutions.
|
| Then I discovered that for my writing style, org-mode with
| embedded scripts and plotting code really just works. I don't
| have to think much and I can focus on just writing. That
| particular authoring/publishing tool never gets in the way of
| what I want to express.
|
| So I ended up patching over parts of org-mode to make it my
| static site generator. Sometimes the best is somewhere in
| between the extremes.
| Linux-Fan wrote:
| Writing should certainly go first. But once you have passed the
| first iteration of your own self-built static site generator or
| website the "initial" content may already be there from the
| previous iteration.
|
| I certainly learned to keep the featureset of such a program to
| a minimum in order to have a chance to "complete" and publish
| it.
|
| Btw. the article lists five points that really come close to
| how such a generator may work. I think mine only leaves out the
| CSS compilation stuff and offloads the Markdown processing to
| pandoc...
| reidjs wrote:
| Also guilty of writing a few SSGs and blogging about them.
| Proud to share that now I rsync my half baked writing directly
| to prod!! No build step!
| onli wrote:
| I'd back you up there, and maybe go one step further: Blogs are
| the worst use case for a ssg and you should focus on writing
| first. It's the articles that make or break a blog, and you
| might actually want the comforts of a dynamic blog engine. Plus
| comments, trackbacks and pingbacks, so it is a real blog.
|
| Where static site generators shine are websites that are not
| blogs. Especially when generated from a data source. Then you
| can tailor your ssg to the data source, update the data and run
| the generator to update the site.
| schemescape wrote:
| I created md2blog[1] specifically for this reason: it prevents
| you from making design decisions, so you're forced to focus on
| writing posts instead.
|
| I'm well aware of the irony of building yet another SSG to help
| people avoid doing the same. But I'm addicted to building SSGs
| --this one was my fifth, and I'm considering making another one
| (insert facepalm here).
|
| [1] https://jaredkrinke.github.io/md2blog/
| ezekiel68 wrote:
| > it's way more work than using something that already exists.
| But it's also so much more fun.
|
| I'd say this person "gets it". We spend waaay too much time
| bickering about what people "should" do, in my opinion.
| LouisSayers wrote:
| I've written two static site generators... well one of them has a
| full blown UI (drag and drop, side panels etc), the other is a
| command line tool.
|
| For the WYSIWYG tool I used craftjs and lexical, and ran into
| issues with both - bugs, difficulty doing things like having
| different alignment for mobile vs desktop. It was very brittle
| and it would be troublesome migrating data structures down the
| track. I've put 1.5 years into this (added my own k8s hosting on
| GCP too - also with its issues)!
|
| The second command line builder took me a couple weeks to make a
| simple version of. I describe my pages, sections in JSON and
| render predefined erb templates. I scripted up deployment to
| Amazon S3, Cloudfront, and invalidate the cache after
| deployments.
|
| It's crazy I spent so long on the Saas version and didn't get to
| a working website, and with the command line version now have a
| couple sites up!
|
| It's a cool experience to make your own site builder, definitely
| learn something each time you do.
|
| Here are the sites I made:
|
| https://www.madebyhelena.com https://LouisSayers.com
|
| (Helena is my partner, I remade her site which she had created on
| a different platform)
| somat wrote:
| I agree.
|
| I don't mean to say you should not share it. You constructed
| something good, you feel pride in your device, by all means share
| it with the world.
|
| However static site generation is one of those simple fun
| rewarding types of program to make. The programing is straight
| forward, the results are linear with the input, that is, there is
| not a huge amount of boiler plate you have to wade through to see
| anything. Basic batch data transformation like this is the
| perfect environment to metaphorically "putter around in the
| workshop"
|
| Nothing wrong with using someone else's, but really, you should
| write your own.
| lxgr wrote:
| These are all good arguments why somebody _can_ write their own
| (unlike e.g. rolling your own crypto), but aren 't convincing
| me at all as to why I should.
|
| I've used a static site generator myself to host a blog, and
| I've been pretty happy with it, yet I've never felt the need to
| write one myself even for a single second.
| ciroduran wrote:
| I recently had to nuke the Linux environment where I had my
| Jekyll environment finely tuned (Ran it on Debian WSL). Then I
| realised I had to reinstall Ruby, but the current Jekyll version
| (or the gems I use) uses a version that needs to lock OpenSSL at
| a certain version because of some breaking changes. Tried to lock
| the version in Debian and I was having a really hard time.
|
| Then I realised I just could grab the latest Jekyll image from
| Docker hub and build my website with it. And just like that I was
| able to build my website without dealing with any ridiculous
| dependency.
|
| So yes, you should write your own static site generator because
| it might be a tad easier than trying to install from scratch the
| dependencies of whatever generator you have chosen.
| xena wrote:
| It's something worth doing at least once, but it's not likely
| going to cure cancer.
| cryptos wrote:
| I have experienced both sides. First, I've written my own
| generator in Python (about 300 lines) but the code was not
| exactly maintainable and adding features like tagging was hard.
| So, I looked around and picked up Hugo. While I don't like the
| template engine it was not too much work, to set it up and
| offered everything I wanted. But Hugo comes with braking changes
| all the times! Plus the Hugo developers don't know what semantic
| versioning is, so you have to figure out whether a new release
| works with your configuration or not.
|
| Now I'm on the verge to write my own generator again (probably in
| Kotlin or in Rust), because I'm tired of Hugo's breaking changes
| and because I still don't like the ugly Go templates.
| imagetic wrote:
| You don't have to update it either.
| karmakaze wrote:
| Hmm. If I were to write my own I'd probably make a CMS rather
| than a SSG.
| joelcares wrote:
| I've been very impressed with Eleventy:
|
| https://www.11ty.dev/
|
| I find my lingering desire to roll out an SSG slowly fading.
| OJFord wrote:
| Hadn't heard of Eleventy, I thought Zola was where you went for
| speed, which they don't even bother comparing too.
|
| Found this post comparing them & more, Eleventy (man that's
| annoying to type on mobile with autocorrect though!) for speed
| it says. https://mtm.dev/static
| joelcares wrote:
| Love the build times, thats for sure.
|
| I'm really attracted to the Eleventy approach on the whole -
| there's no bloat, they don't inject any of their own js, I
| can move fast and only add complexity where I actually need
| it.
| jereze wrote:
| And they emphasize on their stability.
| https://www.11ty.dev/blog/stability/
| lapcat wrote:
| Call me crazy, but for my blog I just write HTML and RSS manually
| in a text editor.
| SoftTalker wrote:
| If I ever were to start blogging, that's what I would do. Or at
| least that's how I would start out. I can't really imagine how
| a site for my own blog would need more than that. Learning HTML
| well enough to write a blog is not any more difficult than
| learning the ins and outs of another markup format, plus how to
| use the site generator and template system.
| intrasight wrote:
| I too had build my own static site generator. A buddy asked if he
| could use it to build some sites, so I invested in it being more
| polished. Put a REST API in front of the engine and file
| management, and then an AJAX SPA on top of the API. Over the
| years, it's been used by a bunch of web sites - large and small.
| The largest was Longwood Gardens - which had hundreds of pages.
|
| This was about 20 years ago now. Once it a while I consider
| refactoring/resurrecting it. But I've not found the time.
| forrestthewoods wrote:
| Disagree. Just write raw HTML. It's much much easier and gives
| you trivial control.
|
| It's _much_ easier to write raw HTML and HTML-to-Markdown than
| the other way.
| JaDogg wrote:
| This is why the static site generator I wrote support embedding
| raw html :p
| nicbou wrote:
| I built one. I run a content website for a living so it was worth
| it. I wrote about why here:
| https://nicolasbouliane.com/projects/ursus
|
| The short version: text files let you use powerful tools, not
| just the WYSIWYG editor supplied with your CMS. Navigating
| markdown files in Sublime Text is incredibly fast compared to
| clicking around in a PHP admin area. I can even write blog posts
| with Obsidian on my phone.
|
| It also means a very simple, very fast server that runs forever
| without maintenance. You don't need much to serve static files.
|
| Above all, it means source-controlled content and content
| branches. This is great for big changes that span multiple pages.
| Paul-Craft wrote:
| Nah. I'll stick with Pelican. It does what I want in a pretty
| straightforward way, and there are tons of themes and plugins
| available for it that _I don 't have to write._
| samuell wrote:
| I feel there's something to be said about a static site with a
| simple PHP-based search function thrown in there. Perhaps it
| could have even the full site content pre-generated as a data
| structure in PHP, for keeping in memory. Could be just
| word->pageId mappings, if you want to keep it simple.
| sbjs wrote:
| I wrote one and it's the only software I still maintain and am
| proud of. I'm kind of inventing a new React like thing in it.
| It's way cool.
| namegulf wrote:
| Just script it using any of your favorite tools, freemarker,
| jerkyl, etc..
| mrpotato wrote:
| Just like a bunch of us here, I also wrote an SSG.
|
| I setup a cronjob to fetch weather data and run the SSG to parse
| the XML and render a weather "website" on my VPS.
|
| But for the blogs I've had/have, I just use a pre-existing one
| (zola). There are hundreds of SSGs out there, why bother building
| yet another one if one already exists for transforming your
| preferred base doc (markdown, asciidoc, morse code, etc)
| imadj wrote:
| > There are hundreds of SSGs out there, why bother building yet
| another one if one already exists for
|
| It's really not that rosy tbf. I went through something like:
| SvelteKit, 11ty, Astro, Zola, hugo, and possibly others in-
| between.
|
| It's pretty easy to develop a preference where none of the
| mainstream SSGs fare well at. Some established large SSGs might
| do X but they have their own challenges too.
|
| You start migrating by filtering based on some criteria, and
| find a match that does a great job initially, only to get
| bitten later, when you've migrated and settled and start seeing
| the cracks.
|
| For example, Zola, and many others, doesn't support asciidoc.
| The handful that do have their own problems too. (I'm now with
| hugo which support asciidoc but I'm still determined to build
| my own ssg)
|
| It's not fantasizing about the perfect tool, as much as
| developing a setup where you're comfortable and happy.
| Especially in the case of SSG, where you're more exposed to the
| internals and by extension any errors/problems.
| schemescape wrote:
| The most commonly missing SSG feature for me is being able to
| transform relative links between Markdown files (which VS Code
| happily auto-completes for me) into relative links between the
| resulting HTML files.
|
| Similarly hard to find is tagging posts based on file system
| metadata (e.g. everything in "posts/linux/" should be tagged
| with "linux").
| im_dario wrote:
| I wrote too (and still maintain) a SSG, it's a fun exercise:
| https://github.com/darccio/zas
| superkuh wrote:
| Maybe don't write a static site generator. Maybe just make a
| normal website made of individual HTML and other files that
| doesn't require any "generation" at all. Static site generators
| are supposed to be for getting away from complexity but most of
| the time they just shift the complexity away from being
| attackable.
|
| There's no requirement for websites to be generated either
| statically or dynamically. The best websites are just files in
| folders.
| prewett wrote:
| That's a great start, but the problem comes when you want to
| have a site menu and breadcrumbs and then you want to redesign
| it. No problem for 5 pages, but if you have even dozens you'll
| start wanting to do something more automated.
| superkuh wrote:
| Use nginx (or whatever) and use server side includes for
| templating footers/menus/etc. It's extremely simple with the
| lowest possible attack surface for it's expressive
| power/utility. SSI should have never faded from the web dev
| toolkit; especially since it's actually still there in every
| popular webserver. Just, <p>whatever stuff
| here...lorem ispum, etc...</p> <!--# include
| file="/menu.html" --> <p>etc etc</p>
|
| I use it extensively and it's great. You're still just
| working with .html files in folders.
| LarsDu88 wrote:
| Not-invented-here-syndrome
| kderbyma wrote:
| I wrote mine a couple years back and have been using it for a few
| blogs and anything I want to make a landing page for. Even built
| a mini game engine for it that loads up zip file games. Also
| added an editor and a backend for dynamic blogging and live
| reload.
| 0xbadcafebee wrote:
| I know what you're thinking and you're right, it's way more work
| than using something that already exists. But it's also so
| much more fun. You can do anything with this, and you don't
| need to read documentation or try to understand other people's
| architectural decisions--just start writing code!
|
| Great argument for never writing your own SSG.
|
| Back in the day we didn't have SSG's. We just wrote the
| html/js/css by hand, and then used the existing browser and web
| server features to keep it DRY. No frameworks, no generators, no
| complexity. It wasn't fancy (or pretty) but it was simple and it
| worked.
| SAI_Peregrinus wrote:
| I maintain a web site for a small club I'm in. I use an
| existing SSG (Zola). My goal is that people can get information
| about when the club meets, about our events, etc.
|
| I _do not care_ about how "fun" it is to maintain, I care if
| people can get the information they need. It should take as
| little effort as possible, because extra effort maintaining the
| site has to be taken from something more valuable I could do
| with my time.
| neilv wrote:
| For over 2 decades, my personal Web site has been generated from
| one big Emacs Lisp file (plus a filesystem tree of image and
| downloadable files).
|
| Both the code and the text data were in the one file.
|
| The code included features like rich syntax coloring source view
| of files (fairly unusual at the time) that were also
| downloadable, and calendar-based blog navigation.
|
| Over time, the code changed a little, such as to convert from
| HTML tables to CSS with the same look.
|
| Just the one file, in Emacs, was a very rapid and lightweight way
| to work. Imagine a code file that includes simple function
| definitions, like that below, and calls to those functions,
| passed a mix of static and generated data for the pages.
| (defun web5-write-html-file-format-sideheads (root-
| dir subdir leaf-fname title-list sections) (if (stringp
| title-list) (setq title-list (list title-list)))
| (web5-write-file root-dir (concat
| subdir "/" (or leaf-fname "index.html"))
| (web5-page-html title-list
| (web5-format-sideheads title-list
| sections))))
|
| If I were doing it today, I'd probably do lots of Markdown files
| and a bespoke generator program, though that wouldn't be quite as
| rapid to develop as the Emacs single file one was.
| Derbasti wrote:
| I built my own on top of org-mode:
| https://github.com/bastibe/org-static-blog
|
| And also various others, for various reasons. The thing about
| static site generators is that they are fantastically easy.
| polivier wrote:
| I wrote one in elisp for publishing my blog directly from org-
| mode files in Emacs (because of course). It is super minimalist
| and works great for my specific use case.
| thenoblesunfish wrote:
| I did a very minimal version of this myself recently, and it was
| very fun! I don't even have Markdown - I just write HTML and have
| a couple of helper Python scripts to update headers, generate
| boilerplate for images, etc. It's nonscalable and not really for
| anyone else, but fun, easy to understand, and there is not much
| to go wrong.
| karurosu wrote:
| I didn't realize this was so common. In my crazy days I wrote a
| SSG using only XSLT, so you wrote a big xml with the content and
| it would output a full site ready to upload.
|
| It needed a specific XSLT processor as most couldn't generate
| individual files, but it was nice that it worked with off the
| shelf software, so technically I didn't write a single line of
| code.
|
| (XSLT is madness, don't attempt)
| schemescape wrote:
| I also did this, except the XML file itself was generated from
| a file system tree.
|
| XSL did eventually add multiple outputs, but yeah: do not
| attempt :)
| chasd00 wrote:
| a spreadsheet, word template, mail merge, then save-as html and
| you're there :)
| BimJeam wrote:
| This is so cool. I did the same last week with pure php without
| any dependencies besides icon, gd and rsync for deployment. Feels
| like I had sitting inside a LAMP prison for the last two decades.
| Now just some json files are my database. No fancy bullshit. Just
| handmade code and some templating. I feel freed like you.
| cobertos wrote:
| I use a hybrid approach. Next.js is the base for my site but I
| use next-sitemap and a hand rolled content compiler (md -> html
| -> jsx) for feeds, meta tags, and generating every page I dont
| manually specify as a .tsx file.
|
| I like having the flexibility to do either. Complete control in
| .tsx or just writing in .md. I would like to add .mdx eventually
| too
| xwdv wrote:
| Considering that a vast majority of people who decide to learn a
| static site generator never end up really developing their static
| site much beyond a few articles talking about their static site
| generation process, I think there is definitely more value in
| just going all the way and writing your own static site generator
| from scratch. The code is the true purpose, not the final output.
| And the thing about a static site generator is, once it works -
| you're done. You can put the project away and move on to other
| common things like building a tile map editor, etc.
| captn3m0 wrote:
| Another option that I've found worthwhile is to write a Jekyll
| Plugin, so you get a stable base for your SSG, and you can
| experiment with adding weird functionality on top.
|
| For my news website, I needed to scrape some news from a third
| party API, and I just moved it to a Jekyll plugin so it embeds
| neatly into the website. Works quite well:
| https://github.com/captn3m0/news
|
| Another place where it made sense to use SQLite as a data source,
| I wrote a Jekyll SQLite plugin.
| andrewstuart wrote:
| httrack converts websites to static I've had good success with
| it.
|
| It downloads the dynamic sites and converts to static pages.
|
| https://www.httrack.com/
| 6510 wrote:
| These never come explaining Why html is to hard. Basics and ftp
| can be explained to a 12 year old in 10-20 minutes? I'd even
| argue (based on decades) that everything learned beyond the first
| 30 minutes is probably something you should not be using.
| ehutch79 wrote:
| No one is saying HTML is hard. It is however, tedious to copy
| and paste your content into a blank template, update the meta
| tags, etc. Then update navbars and lists, etc. Now imagine a
| redesign, or a bug in that blank template thats now in all your
| pages...
|
| The SSR isn't to avoid HTML, it's for template purposes.
| JodieBenitez wrote:
| Lots of "don't reinvent the wheel" comments here. But if you're a
| developer, crafting a SSG for your own needs is a 2-3 hours
| project. Learning an existing one is roughly the same. But hey...
| it's a good opportunity to learn by doing, and even later
| appreciate other SSGs.
|
| My own SSG is Django+Distill.
| kennu wrote:
| It's 2-3 hours for the first version. Then you want to add
| something to the website, and you find you don't have the
| feature for it, and need to spend another 2-3 hours. This
| repeats every time you're adding something and becomes a
| massive time sink. But if you don't mind, sure it's okay.
| ivolimmen wrote:
| I did write my own static site generator. Used gulp and used
| nunjucks and streamed a json file for content into the gulp build
| system...was 61 lines.
| jdblair wrote:
| I once wrote a static site generator in m4!! This was about 2002,
| and I discovered m4 while picking apart GNU autoconf. It was
| anachronistic (to say the least) even then.
| olah_1 wrote:
| I made a website that does all the markdown to html conversion
| right on the client and it still has great SEO. Apparently google
| and stuff will just index the markdown itself.
|
| No compilation step needed.
| doublejosh wrote:
| I would ALMOST agree.
|
| Five years ago I dove into using an ultra-light-weight framework
| called MetalsmithJS. It's super minimal, but does what you need.
| I'd spent 10 years using the Drupal monolith, and did not regret
| the move. Yet it's open-source community dried up, but mostly
| because the framework does what it claims and then stopped
| expanding!
|
| Here's a blog post...
| https://doublejosh.com/post/186193119278/metalsmithjs-is-sti...
|
| Then two years ago I needed a more robust SSR system based on
| React, so I went with GatsbyJS. It's insanely mature and
| intuitive, but as we all know that community and business is now
| drying up too. But the framework is still great.
|
| Now everyone sings the praises of NextJS, which can be used for
| SSR but is intended for applications and active server endpoints.
| But more complexity doesn't mean better.
|
| I'm keen to try other simple frameworks when the result is a
| static site. I may give https://www.11ty.dev a shot.
| mp05 wrote:
| I built my own static site generator with Drupal 8 for a
| project. It was a good experience and made my company a lot of
| money.
|
| We went with Gatsby for our overhaul and honestly, not looking
| back unless forced to. I realize it doesn't scale all that well
| but we're at ~10,000 pages and our build time is about 8
| minutes without a lot of optimization. Given our refresh
| interval is 15 minutes, nothing to worry about from my
| perspective.
|
| People keep chattering that NextJS might suit our needs better
| but GatsbyJS sure ain't broke.
| civilized wrote:
| I see a lot of people building their own static site generators.
| There's probably a lot of common elements to the process, right?
| We should abstract those commonalities into a static site
| generator generator, so that everyone who needs to write a static
| site generator doesn't need to reinvent the wheel.
| schemescape wrote:
| There are a few that take that approach, but people usually
| want one in their preferred programming language/runtime.
| Examples:
|
| Metalsmith (Node/JS): https://metalsmith.io/
|
| Haunt (Guile Scheme): https://dthompson.us/projects/haunt.html
|
| I'm sure there are many more.
| tmarthal wrote:
| Such a strange abstraction layer.
|
| Thr author could have skipped a step and formatted using tags
| instead of markdown and published the html directly, with zero
| need for any generator. Using scp and html, like it was 1998.
| myco_logic wrote:
| I fully support the idea that writing your own SSG can be not
| only a great learning experience, but also a chance to make your
| SSG do exactly what you want it to (and nothing more).
|
| I've written a ton of little SSGs over the years, and every
| iteration I've learned what kind of features I really need, and
| which I don't.
|
| When I started working on the current version of my personal
| website (istigkeit.xyz), I also wrote a new SSG just for it. The
| program is called Hyphae[1], and it's written in Ruby using the
| Kramdown markdown gem, and pretty much nothing else outside the
| stdlib. It works perfectly for me, and that's all that matters
| (that being said, the code is up there, and licensed with the
| Unlicense, so anyone who finds it useful is free to use and abuse
| my clumsy code to whatever extent they want).
|
| I'm a big proponent in the idea of writing personal software:
| that is, programs that are made by you, for you, and with no
| expectation that they'll be used by anyone else. I think too
| often developers these days get caught up in trying to make their
| project be "the next big thing" in whatever domain it serves, but
| honestly sometimes it's nice to just write something for yourself
| :)
|
| [1]: https://gitlab.com/henrystanley/hyphae
___________________________________________________________________
(page generated 2023-11-03 23:01 UTC)