Yes! I was looking for a decent selection of single-page app SSGs for so long. This is only the second one I've found, the other being Lingon (https://github.com/spotify/lingon), and this one looks like the only one that can still work as a blog.
Does anyone have any feedback or alternatives for SSGs which build static single-page blogs?
The "app" in this case would be client-side logic (e.g. written in JS) which might then render the blog client-side by pulling down the text for the blog. Ultimately, everything on the server is unchanging until you do a rebuild with new content.
So long as the hosted content isn't dynamically generated server-side when you visit, it's static.
is there an ssg that is entirely web based? I don't want local files or to use a terminal. I would move away from Wordpress (and would like to) if something let me click a few buttons to set up a simple blog. I don't need anything fancy.. Let me make some basic choices and post my blogs.
Jekyll recently got a first-party admin plugin that might meet your needs[1]. You'd still need to use a terminal to set it up. I'm not quite sure what you mean by not wanting local files, but your files would be wherever you're hosting your site from.
I've used prose [0] with a few clients. Its just a web interface for messing with Jekyll, hosted on GitHub. So you might have to upload the Jekyll site to GitHub once, but after that you can edit it as you like.
It also adds some configuration that you can add to Jekyll's config, letting you decide how each menu in the admin console should appear. [1]
A number of these (Jekyll, Octopress and Hexo) are disappointingly similar. I wish they offered novel solutions rather than the same Liquid templates + YAML front matter + Markdown/ReStructuredText.
I've used lektor and pelican but not nikola. Lektor provides a nice gui where pelican does not (ime). They both work well and pelican seems to have more themes due to it being older.
The problem with Lektor is that it looks semi-abandoned, even though it's pretty young. Last I looked, the repo has a bunch of PRs that have gone unreplied-to for months.
A local web GUI for easier "content management", and a flat-file storage scheme of the content (without needing a database to store the content); that's what makes lektor different from other static site generators (SSGs). (The dev team behind this platform is great by the way!) Beyond these benefits, the rest is very similar to what other SSGs offer - including both the good and the bad that comes with any/all SSGs.
While lektor ultimately didn't meet my needs, I suggest that you give it a try, and see if perhaps it fits your use-case.
This statement caught my attention in the article:
> It is optimized for speed (Hugo sites can be built in milliseconds)
Is that true, or does it just happen to be fast? It seems to me that the performance of a static site generation is irrelevant, and thus time spent on this is really wasted effort.
I don't care if it takes several minutes to build.. it'll happen on the CI server in the background, and so long as the actual deployment is atomic, it makes no difference.
A site that has time-sensitive content or update requirements of more than hundreds of times per day seems to be a poor candidate for use with a static site generator.
1. During development. Having instant builds running whenever you save is great for the development experience
2. For really large sites. Being able to build many thousand pages in about a minute instead of 20 minutes or way more is a huge difference for the authoring experience.
Number two is why I use it. My site has about 2300 pages and regenerating the whole thing when I tweak one part or another of the basic template or change themes is less than two seconds. Extraordinarily fast and encourages experimentation at least for me. Maybe folks with better front end skills wouldn't care but it's great in my experience
Yea gonna agree with u:bobfunk here that it's really about local development where it matters. And yes it is very fast in my experience, although I don't push it as much as others do.
It's also amazing to just have a single binary (or go get -u command) to get going unlike jekyll or the gems to run github's jekyll environment locally. I can't tell you how many times I'd just not blog in a while and need to setup this whole crazy setup for local jekyll and I'd just never write the post because of it. Hugo makes things simple, fast, and extensible.
edit: also I usually do the build locally and commit that to a specific repo which has the final rendered version for easy deployment to github and other places. I've made a `Makefile` just to do this easily as `make publish` to get any changes I have build, commited to the rendered repo, and commited to the source repo.
I've just migrated to Hugo, and agree with the comments that it really does matter. Between the near-instant compilation and the live reload, the Hugo development server can update a local copy of your site in the browser faster than you can switch tabs. In effect, you get genuinely instant preview anywhere, out of the box.
In every respect, Hugo is a really good site generator (not just a static blog engine), but this is the feature that makes the competition near-irrelevant to me.
> It is optimized for speed (Hugo sites can be built in milliseconds)
I suspect it's based on a minimal set of test cases, not a full site. With hundreds of pages mine takes anything from 30 seconds to a couple of minutes to build.
As with everything, this is a huge oversimplification (i.e. Go = faster than scripting languages). I'm dubious if the algorithmic part of static site generators dominates. Would have though it's I/O bounded to some degree, in which case Go isn't going to be faster than anything else.
Besides, caching solves this issue better, unless you change the underlying templates.
> It seems to me that the performance of a static site generation is irrelevant, and thus time spent on this is really wasted effort.
Another consideration is pages which take a long time to render. When I'm writing about code (which is a lot!) I use a literate programming style, so that code snippets on a page can be executed and have their output embedded in the HTML. This ensures that the code I'm discussing actually works as claimed, and keeps everything self-contained; but it can make rendering arbitrarily slow!
As long as the build system is incremental (I use GNU Make) the cost only has to be paid when changing those pages (either their content, or a template), so it doesn't slow down the edit/build cycle for other pages.
The process I use is very simple: shell commands are written as attributes of code blocks, and during rendering the content of the code blocks will be piped into those commands. Hence we can run a bash script by giving its code block a pipe="bash" attribute, python scripts by using pipe="python", haskell by using pipe="runhaskell", and so on for anything that can be called from a shell.
This is all powered by a couple of scripts based on Pandoc.
If you want to see some examples, click the "View Source" links at the bottom of my site. The pages I linked to above are quite complex, but some simpler examples are:
I also just started using and am really liking it so far. Relatively easy to set up, nice modern themes, and as others have said, the live reload and fast generation are awesome. My first post[0] explains how I use it with GitHub Pages to track commits and host.
We've been testing out Cloud Cannon on our website - www.cloudcannon.com. Different approach from forestry - definitely going to check that one out as well.
I've wanted to make a static site generator generator for a while. Run the script and out comes another script with a wicked cool name that uses one of the many markup options, header formats, and templating engines (either manually or randomly selected).
Haha. I did this with kung fu styles, wrote a little script that chooses a name, theme, and logo description. It'd be funny to see one for static site generators.
I've been working on Formingo (https://www.formingo.co), a form processing service for static sites so you can receive your form submissions directly to your email without the need for server side code or your own backend.
I've actually had a couple people ask me about comment systems that were an alternative to (and more simple than) Disqus, so it's cool to see someone working in that space.
Not sure at this point. If you need more than the default 500 submissions per month, shoot me an email (andrew@ the Formingo domain) and I can hook you up ;) (same goes for anyone else reading).
I'm working on expanding the service a bit before I get into paid plans or anything. The drag and drop form builder is coming soon, which will also work with static sites (using JS to embed the form, and eventually have a couple other options such as just generating the HTML for you so JS isn't required for your visitors)
Your API is exactly what I would expect to see from such a service. Your pricing is also exactly what I would expect to see, so props.
I only need a POST endpoint that will accept a few parameters and redirect back to my success page, and I will definitely keep your service in mind for that.
Although, how do you keep everyone from sending spam from you?
Right now there's domain and email verification so that you don't get spammed from people taking your form and embedding it into their website, but I have some upcoming plans for spam detection.
In fact, the first parts of this system is in place already-- if you have an account and create a pre-validated form, you can go into your dashboard to see the responses and mark them as spam. This will become the training data for the spam filter at a future point in time.
Ah, I more meant "how do you make sure people don't send spam to arbitrary destinations sending your form", but I see you're doing email verification of the recipient first. I thought "put this form on your site" was literally all there was, at first, hence the question.
I see-- yes, when you embed a new form, you receive a verification email for the page URL-email combination. Meaning if you change the email address or use the form on another URL, you get another verification email.
If you register for an account, however, you can bypass this and pre-register your domains and verify your email address and get a special URL without your email address in it (it's an arbitrary token).
This is our solution to this problem. Our service is a general purpose "sql database over cors and https", posting forms with captcha is the archetypical use case. It is more low level and requires some coding. Let us know, we're happy to help out!
Formingo looks good. But one thing I'd like is the ability to hide my email address so it doesn't get picked up by spammers. The current setup shows the address plainly in the page source. Could the action field take some sort of identifier number or hash, as in:
/submit/12345
Then your system looks up 12345 and sees it means john@example.com.
You can sign up (https://www.formingo.co/register) for a free account that lets you create forms that hide your email address (along with pre-verify your email address and domains so you don't have to click a verification link every time you add a form to a new URL/email address combo) :)
Thanks Andrew. I was just looking at the intro example on https://www.formingo.co/create-a-form and didn't dig deeper. I'm glad I asked. I'll give it a try.
This looks nice. Disqus placed ads on our sites for the second time recently, which was the last straw. I've already got a backlog task in place to find an alternative, and I'm adding Remarkbox to the list.
S3 works really nicely. I'm building my Octopress-based site using snap-ci (free for public builds). It was fairly straightforward to configure for use with S3 and you can run just about anything you want on it.
I rsync the files to a server where nginx serves them. The smallest server option at your VPS of choice will be plenty, particularly if your site is reasonably lean or less than mega-popular.
Github Pages can serve any static files, so I don't understand what you mean by "css being severely limited"?
If you meant the Jekyll support build into GitHub, you could use a free CI service to run any other SSG, and push it to GitHub pages or any of the other suggested solutions. If you want everything from one service, GitLab uses their CI service for GitLab Pages and have prepared templates for many SSGs already.
I have a CloudFront distribution sitting in front of S3, secured with a free SSL certificate powered by Amazon ACM.
I like S3 for its flexibility. My site is in both English and Dutch and I want to serve English content on .io and the Dutch content on .nl. With S3 I just create two buckets, associate the bucket with a different domain and welcome page (index_en.html and index_nl.html) and publish the same site to each bucket.
I really, really like Netlify. While it's probably not the cheapest option I think the pricing is fair and the ease of use, workflow and performance are great.
Amazon S3 + CloudFront here, for several websites and it works wonderfully. I recently set up attensee/s3_website as a pipeline on my BitBucket repo, so now when any team member pushes their HTML/CSS updates to BitBucket, it automatically deploys the site to S3 and invalidates the CloudFront caches automatically. Instant website updates using only `git push`.
Netlify (https://www.netlify.com/) themselves offer hosting and deployment for static sites, with included add-ons like CDNs, form handling, SSL, etc.
GitHub Pages (https://pages.github.com/) is another popular option but it only supports Jekyll, and if you wanted a CDN, form handler, redirects, and other features then you'd have to tack on other services.
I've been using wintersmith (http://wintersmith.io) to power my blog for years and am very happy with it. It's incredibly flexible, is hackable at just about every level, and has no problem if you just want to dump some html/css/js into a directory and serve it. So I'm able to "host" several of my projects right within my blog.
Are there any real differentiating factors or are there so many because they're so easy to do? I built a custom one for a client once for no real reason.
I think one reason there is so many is there tends to be at least one for a given language. That way you can fire up npm, pip, cargo, whatever you're most comfortable with and have one installed.
When I reviewed a bunch of SSGs looking for the one for me, the differentiators were:
* What language it's in (assuming you want to be able to hack around issues if you need to)
* What intermediary formats it uses (EJS/jade/stylus/LESS/SASS, etc. - assuming you don't want to publish a site that looks like the SSG's demo page)
* How opinionated it is about its output pipeline. Some SSGs have fully-formed plugin systems, so you can choose your favorite minifier, add a transpiler, etc., which is powerful but more work. Others just do what they know how to do and if you want to add steps you'll have to post-process the output.
That said, running through the "publish a hello-world page with default theme" was pretty much the same for every SSG I tried. You have to really start futzing with things to see the differences.
Cross-platform support and dependencies would be one: hugo shines for me because every modern *ix, OS X, and Windows are all first-class golang environments, so it Just Works anywhere, and you don't spend years waiting for a package manager to churn through a dependency tree to install or update.
Ruby or node? Not so much.
Also, depending on who you are, how many out-of-the-box themes, and how sane/easy it is to create or customise.
I just use emacs + org mode -> org-publish to generate my site [1] from org-mode with some customizations; it's been the most flexible and fun way to build a site I've had across all my attempts so far, particularly given that I can go meta and also publish the htmlized raw org files at the same time [2].
I'm a vim user, but org mode is one of the things that I really like the sound of from emacs.
For vim, I use vimwiki[0] in (github flavour) markdown[1] mode, and also publish the entire site to HTML. I really just use it for notes, rather than an entire website, but still, one could.
Nobody's mentioned Hexo yet (edit: here), so I will. A while back I reviewed the top 5-6 Node-based SSGs and hexo seemed like the best tradeoff between simple and flexible.
I am a long time WordPress user. I tried a few but didn't like them much. WordPress is the nice middle point of internet publishing. A well designed web, desktop, and mobile interface, themes, plugins, and commenting system. Cost of hosting is a little prohibitive but it works pretty well.
I am currently trying out Hexo which seem to work just time too.
240 comments
[ 3.2 ms ] story [ 255 ms ] threadDoes anyone have any feedback or alternatives for SSGs which build static single-page blogs?
How does that work? Isn't "single-page app" the exact opposite of a "static site"?
So long as the hosted content isn't dynamically generated server-side when you visit, it's static.
I like this 'serverless' approach.
Or dozens of other? You are not in a cave.
Here so you can try http://bfy.tw/7nJE
[1]: https://www.smashingmagazine.com/2015/12/reimagining-single-...
[1] https://github.com/jekyll/jekyll-admin
https://github.com/Malcx/DamnSmallBlog
[1] http://en.staticpress.net/, https://github.com/megumiteam/staticpress [2] https://wordpress.org/plugins/simply-static/
It also adds some configuration that you can add to Jekyll's config, letting you decide how each menu in the admin console should appear. [1]
[0] http://prose.io/
[1] https://github.com/shakna-israel/haddonRevamp/blob/gh-pages/...
There were also a few mentions of Phenomic on Gatsby's discussion from a while back [1]. Search for it on that thread.
[0]: https://phenomic.io/docs/faq/gatsby/
[1]: https://news.ycombinator.com/item?id=12128989
1: https://www.getlektor.com/
I ended up with wordpres (shrugs).
While lektor ultimately didn't meet my needs, I suggest that you give it a try, and see if perhaps it fits your use-case.
I think it's just the context of it being used mostly for API docs and tutorials that it's overlooked.
https://haunt.dthompson.us/
One favorite part is the ability to create content of different types.
> It is optimized for speed (Hugo sites can be built in milliseconds)
Is that true, or does it just happen to be fast? It seems to me that the performance of a static site generation is irrelevant, and thus time spent on this is really wasted effort.
I don't care if it takes several minutes to build.. it'll happen on the CI server in the background, and so long as the actual deployment is atomic, it makes no difference.
A site that has time-sensitive content or update requirements of more than hundreds of times per day seems to be a poor candidate for use with a static site generator.
1. During development. Having instant builds running whenever you save is great for the development experience
2. For really large sites. Being able to build many thousand pages in about a minute instead of 20 minutes or way more is a huge difference for the authoring experience.
It's also amazing to just have a single binary (or go get -u command) to get going unlike jekyll or the gems to run github's jekyll environment locally. I can't tell you how many times I'd just not blog in a while and need to setup this whole crazy setup for local jekyll and I'd just never write the post because of it. Hugo makes things simple, fast, and extensible.
edit: also I usually do the build locally and commit that to a specific repo which has the final rendered version for easy deployment to github and other places. I've made a `Makefile` just to do this easily as `make publish` to get any changes I have build, commited to the rendered repo, and commited to the source repo.
In every respect, Hugo is a really good site generator (not just a static blog engine), but this is the feature that makes the competition near-irrelevant to me.
I suspect it's based on a minimal set of test cases, not a full site. With hundreds of pages mine takes anything from 30 seconds to a couple of minutes to build.
Besides, caching solves this issue better, unless you change the underlying templates.
Another consideration is pages which take a long time to render. When I'm writing about code (which is a lot!) I use a literate programming style, so that code snippets on a page can be executed and have their output embedded in the HTML. This ensures that the code I'm discussing actually works as claimed, and keeps everything self-contained; but it can make rendering arbitrarily slow!
At the moment, the longest wait is a few minutes for the graphs on http://chriswarbo.net/blog/2014-07-23-fib.html and the images on http://chriswarbo.net/projects/procedural/cantor.html
As long as the build system is incremental (I use GNU Make) the cost only has to be paid when changing those pages (either their content, or a template), so it doesn't slow down the edit/build cycle for other pages.
The process I use is very simple: shell commands are written as attributes of code blocks, and during rendering the content of the code blocks will be piped into those commands. Hence we can run a bash script by giving its code block a pipe="bash" attribute, python scripts by using pipe="python", haskell by using pipe="runhaskell", and so on for anything that can be called from a shell.
This is all powered by a couple of scripts based on Pandoc.
If you want to see some examples, click the "View Source" links at the bottom of my site. The pages I linked to above are quite complex, but some simpler examples are:
- The blog post listing comes from a `find` command http://chriswarbo.net/blog.html
- Images can be embedded using base64 URIs http://chriswarbo.net/blog/2015-06-06-more_git.html
- Code snippets can be checked, and we can even include real error messages http://chriswarbo.net/blog/2015-11-12-calculating_arity.html
[0] http://www.getup8.com/post/blogging-in-hugo/
Using Algolia for search.
Somebody, please make this.
It does support multiple input formats and at least Jinja2 and Mako for templating:
1. https://getnikola.com/Check it out here: http://www.remarkbox.com
I've been working on Formingo (https://www.formingo.co), a form processing service for static sites so you can receive your form submissions directly to your email without the need for server side code or your own backend.
I've actually had a couple people ask me about comment systems that were an alternative to (and more simple than) Disqus, so it's cool to see someone working in that space.
I'm working on some Jekyll landing pages and I need form options for people.
I'm working on expanding the service a bit before I get into paid plans or anything. The drag and drop form builder is coming soon, which will also work with static sites (using JS to embed the form, and eventually have a couple other options such as just generating the HTML for you so JS isn't required for your visitors)
I only need a POST endpoint that will accept a few parameters and redirect back to my success page, and I will definitely keep your service in mind for that.
Although, how do you keep everyone from sending spam from you?
In fact, the first parts of this system is in place already-- if you have an account and create a pre-validated form, you can go into your dashboard to see the responses and mark them as spam. This will become the training data for the spam filter at a future point in time.
If you register for an account, however, you can bypass this and pre-register your domains and verify your email address and get a special URL without your email address in it (it's an arbitrary token).
https://www.lite-engine.com/blog/post_form.html
/submit/12345
Then your system looks up 12345 and sees it means john@example.com.
For people who like Jekyll but want multiple sites with the same code base:
https://github.com/sumdog/jekyll-multisite/
It's pretty alpha and I'm currently working on a full set of test cases so I can merge in some incoming pull requests. But I use it for all my sites.
https://github.com/callmeed/jekyll-image-set
* https://github.com/skx/e-comments/
Seems mine is more basic than yours, due to lack of registration and lack of threading though.
Then if your site becomes famous - drop cloud flare in front.
https://www.joyent.com/pricing
If you meant the Jekyll support build into GitHub, you could use a free CI service to run any other SSG, and push it to GitHub pages or any of the other suggested solutions. If you want everything from one service, GitLab uses their CI service for GitLab Pages and have prepared templates for many SSGs already.
I have a CloudFront distribution sitting in front of S3, secured with a free SSL certificate powered by Amazon ACM.
I like S3 for its flexibility. My site is in both English and Dutch and I want to serve English content on .io and the Dutch content on .nl. With S3 I just create two buckets, associate the bucket with a different domain and welcome page (index_en.html and index_nl.html) and publish the same site to each bucket.
GitHub Pages (https://pages.github.com/) is another popular option but it only supports Jekyll, and if you wanted a CDN, form handler, redirects, and other features then you'd have to tack on other services.
Integrated with Bitbucket, git push deploy, Docker auto-builds of static generators, wildcard SSL custom domains, CDN, etc.
disclaimer: I work at Aerobatic
* What language it's in (assuming you want to be able to hack around issues if you need to)
* What intermediary formats it uses (EJS/jade/stylus/LESS/SASS, etc. - assuming you don't want to publish a site that looks like the SSG's demo page)
* How opinionated it is about its output pipeline. Some SSGs have fully-formed plugin systems, so you can choose your favorite minifier, add a transpiler, etc., which is powerful but more work. Others just do what they know how to do and if you want to add steps you'll have to post-process the output.
That said, running through the "publish a hello-world page with default theme" was pretty much the same for every SSG I tried. You have to really start futzing with things to see the differences.
Ruby or node? Not so much.
Also, depending on who you are, how many out-of-the-box themes, and how sane/easy it is to create or customise.
https://staticsitegenerators.net/
[1] Publishing config: http://explog.in/config.html [2] Org Source: http://explog.in/config.org.html
For vim, I use vimwiki[0] in (github flavour) markdown[1] mode, and also publish the entire site to HTML. I really just use it for notes, rather than an entire website, but still, one could.
[0] https://github.com/vimwiki/vimwiki/ [1] https://github.com/patrickdavey/vimwiki_markdown
https://hexo.io/
I also wrote up all the stuff I learned migrating and existing Wordpress blog to static:
http://aphall.com/2016/01/migrating-wordpress-to-static/
Hexo is #2 in the list in the article...?
I am currently trying out Hexo which seem to work just time too.
(Can make user-editable wikis as well.)
Besides Bricolage (ancient, abandoned?, never got it to work – even the VM image they provide as a demo) and Movable Type (expensive), of course.
I've been used it for over 4 yrs and still surprising.