Hacker News new | past | comments | ask | show | jobs | submit login
Static Website Generators (netlify.com)
307 points by gk1 on Sept 19, 2016 | hide | past | favorite | 239 comments



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].

[1] Publishing config: http://explog.in/config.html [2] Org Source: http://explog.in/config.org.html


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.

[0] https://github.com/vimwiki/vimwiki/ [1] https://github.com/patrickdavey/vimwiki_markdown


Ha, that's timely. I started writing an online tutorial just today and settled on org-mode. Reading your config is immensely helpful. Thanks!


The main problem for me is that the absolute majority of them target blogs and if you try to adapt them for a more complicated website you gonna dive very deep inside the code or continue constant search. Now I look at hugo as it seems to be a more general-purpose tool that allows to play with structure and content types.


If you want something that can do complex sites take a look at http://nanoc.ws: we created a very large multi-domain site using it, in 9 languages. Our tool chain includes linters, spell checkers, multi stage deploy scripts, and capybara tests for the Javascript parts. Admittedly we've heavily customised nanoc with rake tasks and ruby scripts, but it lends itself well for that.


Personally, the biggest issues is the CMS backend part of the process. I'm fine writing content for an SSG, but the marketing department is not. What I really want is a fast, open, and simple CMS BE that has a publishing workflow where the output is a static site. I've yet to fine the perfect candidate. The ones that are close are SaaS platforms and that is unfortunately unacceptable. I'm perfectly ok paying for software, at least if I get the source. If anyone has some suggestions, I'm all ears.

Edit: Just to add, I have multiple needs here that aren't enumerated, one of which is full translation support for the source content to support multi-linguale/multi-locale sites.


Funny you'd mention that. We're putting the final touches to an Open Source Jekyll CMS we've built for ourselves (called Jekyll+) that does just that; give a nicer interface for marketing folks and provide multilingual support out of the box.

Preview of my local copy we're prepping up for a release end of the week: http://i.imgur.com/1VyxGzqr.png

Happy to have you testing it out and give me feedback.


Feel free to send me an email, I'll test it out.


Will do.


It doesn't support translation AFAICT, but I've been playing with DatoCMS[0] and I've been happy with it for my needs. I suppose you probably could build a translation workflow on top of their API if you were feeling ambitious.

[0] http://datocms.com/


You might like contentful, it's a (paid) CMS UI & content API with plugins for a number of different SSGs.

https://www.contentful.com/developers/docs/tools/staticsiteg...


There are a number Content-as-a-Service offerings that can be used with static site generators. (Though not usually with GitHub's built-in Jekyll support as it doesn't allow for plugins)

Examples: Contentful, Prismic.io, Built.io, CloudCMS

Full disclosure: I work for Contentful


Yeah, I love the idea of Contentful, I just cannot use it unfortunately. If Contentful was available as a purchase option for self-hosting, then I'd be all over it. But it is exactly what I need.


> "I'm perfectly ok paying for software, at least if I get the source."

Unusual position - source access is quite rare for commercial software, isn't it?


That would be why I don't buy software that often, at least for things like this. There is nothing, beyond fear, that prevents a commercial software package from also providing sources.


Totally feel this pain too. A tool like prose.io can help with this a bit, but it's probably still not friendly enough for many non-tech folk.


Isn't https://www.getlektor.com what you're looking for?


I think the flat-file part is a breaker for my current needs unfortunately. But, being OSS I could perhaps fix that, so I'll add it to my short-list of possible solutions.


This very website we are on uses a flat-file structure (w/ millions of users). I'm curious why this is such a deal breaker for your current needs?


Not sure how HN works under the hood, so I have no real comparison. I also have no real reason to say it's not compatible beyond not thinking that locking primitives for a shared filesystem are likely inadequate. But I'm always open to being proven wrong. So, care to provide some good reading explaining why a FF system is more than adequate?


I don't know what you are trying to accomplish exactly, but it seems like you've convinced yourself that you need a more complex file storage mechanism. If you had listed any reason for this function, I might've understood. But, you didn't, so I had to ask. Here's 2 threads where this discussion has been had before:

https://news.ycombinator.com/item?id=5279440

https://news.ycombinator.com/item?id=7338923


Why using files is such an issue, if I can ask?


You should try Lektor (https://www.getlektor.com/). It has a flexible data structure with little assumption about the final product.


I used lektor for http://portfolio.stavros.io/ and it was very easy to make what I wanted. I kind of assumed Jekyll and everything else would be like that too, are they not?


Some of the most popular static generators, such as Jekyll, are explicitly designed for blog posts.


Ah, I didn't know that, thanks. Sounds like Lektor was a good choice for me, then.


FWIW, it's always possible to stand up a dynamic site, crawl it with `wget` in mirror mode, and get a static website as its output.

So long as your URLs are relative, it should work a treat with any CMS.


For more complicated sites I use Rails and a rake task to generate the html files, e.g.,

```ruby

namespace :app do

    desc "Generate static pages"

    task static: :environment do
        pages = {
            '/' => 'index.html'
        }

        app = ActionDispatch::Integration::Session.new(Rails.application)

        pages.each do |route, output|
            puts "Generating #{output}..."
            outpath = File.join ([Rails.root, 'public', output])
            resp = app.get(route)
            if resp == 200
                File.delete(outpath) if File.exists?(outpath)

                if app.response.body.empty?
                    puts "[ no content ]"
                else
                    encoded_body = app.response.body.encode(
                        'UTF-8',
                        {:invalid => :replace, :undef => :replace, :replace => '?'}
                    )

                    File.open(outpath, 'w') do |f|
                        f.write(encoded_body)
                    end
                end
            else
                puts "Error generating #{output}!"
            end
        end
    end
end

```


The Python equivalent is something like Flask-Frozen.


I found Harp.js pretty good for a general purpose static site gen. It's basically just a nice pre-configured jade/ejs/sass/less/coffeescript/browserify package. As long as you follow the 'rules' in terms of project structure, it just works as both a server and a static renderer for the above.

It can be as complex or simple as you like - you could use it for a blog even, you'd just need to write some of the logic yourself in your templates.

I have used it personally for simple 2-3 page sites, where all I want to do is use some simple templates, compile some sass and bundle my scripts, without having to faff with config and build pipelines.


This is all about to change, think of Github as a database, with a server side rendered page hooked up to it. There exist databases that work like git, and React/virtual dom does server-side rendering, so coming soon are frameworks that give you proper database apps, coded in javascript, that are CDN compatible. I've actually built this already but we haven't launched it publicly yet. If interested, you can give us your email at http://www.hypercrud.com


Assemble.io served me well for a number of projects, commercial and private. https://github.com/assemble/assemble/

I've not touched it in about 20 months, but when I was using it more often, I found the documentation a bit weak. Everything you'll need is there, but possibly not written in the way you'd hope.


Shameless plug: I created Zas [0] as a non-opinionated alternative to Hugo and Jekyll. It assumes nothing about your site.

[0] https://github.com/imdario/zas


Not wanting to dive deep inside the code but make a complicated website is like saying "I want to modify the engine of my car but I don't want to look under the hood a single time"

Well, I guess that works if you have a VW Beetle ;)


Well, hopefully an SSG is saving you time compared to just writing a quick crawler that saves each route of your local Express app into a deployable static folder.

If you find yourself credentializing in the source of an SSG because it turns out you're doing something it doesn't support, then there's a point where it might've been faster to build as a dynamic site (more general tooling) with a static site build step.

It's an easy place to find yourself since so many SSGs generalize around blogging.


I crave simplicity in my life right now and am using markdeep: https://casual-effects.com/markdeep/

I write my documents in markdown and add this tag at the end of my document <script src="markdeep.min.js">

I "publish it" by copying it to my server and renaming it .html

* note: To get started, here is the suggested starter document: https://casual-effects.com/markdeep/starter.md.html


I'm not sure if this counts as a "static website", since the page is not delivered exactly as stored. It requires JavaScript to actually renders the page, which seems like an overkill.


That's just client side templating. Which has the same problem they all do of being greeted with a white page until ALL the content is ready.

If someone is prepared to accept this it's not that hard to accept generating the html page yourself and uploading that.


> That's just client side templating. Which has the same problem they all do of being greeted with a white page until ALL the content is ready.

Or being greeted with a white page period if you're using a non-JS enabled HTML client (noscript, CLI browser).


In this particular case, wouldn't they see the plain text markdown? (which in many case is just as good the html)


Kinda, it looks like they add a bit of CSS (basically make everything monospaced & pre) so the Markdown text is visible when JS is disabled (noscript), but in a CSS-less browser (e.g. links) the file is received as HTML, and the Markdown code is directly interpreted as HTML, which makes for an unreadable mess (the whole thing is a single "line" with newlines collapsed to spaces)

You're really better off using a static conversion tool, or using markdeep as a static conversion tool (with ?export)


It's 2016, if you use a non-JS enabled HTML client you better be used to the breakage.


Sure I'm used to closing the page, because really screw you if you can't display half a dozen paragraphs of text without JS.


Well, most of those websites would rather say:

Don't let the door hit you on your way out

Than spend time catering to outliers...


I fully agree. Why render it in every client when you can do it only once on the server? This feels like a waste of CPU resources.


compared to all the other things your cpu is doing, and all the time your cpu sits there doing nothing, the "waste" in this case pales to total unimportance. you've got a supercomputer; you might as well use it.


An idle core will definitely use less power than one constantly processing. That is what drains the battery in your laptop. I'd rather not spend my battery power if it can be done on the server instead.


Thanks. That's a nice idea... but if it's that simple I might as well just use a static markdown to html converter, if I don't need the support for diagram generation (which admittedly looks like a killer feature). For example, pandoc supports that (or latex -> html or pretty much anything else), and the results are similar, e.g. (in this case, specifying a very small amount of additional css): http://pandoc.org/demo/example3.html

I'm currently using couscous (http://couscous.io/) to convert markdown to html but it's far more work to use, and does a whole bunch more than that, such as twig templates, so I'll consider switching to markdeep or pandoc.


Since the website is rendered with JS onload, doesn't this make your site a second class citizen in regards to SEO? If you want people to actually read what you write, static content from the server is still superior.


> doesn't this make your site a second class citizen in regards to SEO

Not with any search engine that matters.


That's impressive! It even has math support! I do wonder about generating the diagrams at every page load. Seems like markdeep might as well have been a static generator?


Yeah, but you can easily copy-paste the generated html into a file. Just append '?export' to the URL. I definitely would use it in that way.


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).

Somebody, please make this.


I probably failed to understand what you described but recently found out about Nikola[1] while looking for publishing solution supporting Org mode.

It does support multiple input formats and at least Jinja2 and Mako for templating:

  - https://getnikola.com/handbook.html#supported-input-formats
1. https://getnikola.com/


Hakyll supports anything that pandoc supports, so it does both org mode and markdown :-)


I've actually written this http://www.camoy.info/modoc/


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 have been eyeing Lektor[1] for a little while, it seems to have good documentation, and an interesting, opinionated dev behind it.

1: https://www.getlektor.com/


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.


What is the benefit of lektor over nikola and pelican?


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.

I ended up with wordpres (shrugs).


Lektor is based on a flat file ORM so you can structure your data as you like.


The main question for me is comments. I don't want to use something like Disqus, and to require something like Discourse would cancel the whole point of having a static site generator that I can host on Github Pages or Gitlab pages. Ideally, what I would like to do is to have an hackernews post automatically generated for each post, and to redirect people to the HN post if they want to comment, but I am not sure that HN allow this kind of use ?


Might be better to use Reddit. You could create a subreddit explicitly to serve as your comment section. This achieves the goal of outsourcing your comments to an established site without raising concerns of astroturfing.


No, the whole point of being linked to HN would be to have feedback from the community. If you prefer, if I was to use Reddit, I would rather like to be able to submit automatically all the posts of my "programming oriented website" to /r/programming , not /r/yannkempf.


I'm sure plenty of people blogging do that already even if by hand, I'd be weary of this approach.


There are ways to implement that kind of thing in a relatively straightforward manner. It does, however, require some kind of non-static element in the site if you want comments embedded in the site or page.

Most SSGs have some kind of plugin system (both Pelican and Lektor certainly do) that would allow you do something like what you want with the HN integration you're considering.

Alternatively, you could use something like Isso (https://github.com/posativ/isso), Kaiju (https://github.com/spf13/kaiju), or Hashover (https://github.com/jacobwb/hashover). I don't use any of these, so I can't really tell you how good they are, but they're options, and far from the only options.


That would be absolutely awful. Imagine if every site did that. Would this be a site you would want to visit?

Maybe what you want to do is have a link that sends you to the HN submission page with the fields pre-populated. That wouldn't be so bad.


The comments on my technical blog were always so friendly and encouraging. People telling me how my tutorial helped them or answering each others questions.

Redirecting them to the HN pit of cynicism and leave-no-stone-left-unturnedism sounds awful. :)


And then, when your site sees a HN post for the article, have it replace the submission link by a link to the discussion.


Check out the service I'm working on: http://www.remarkbox.com

One of the design goals is to _not_ be disqus.


"_not_ be disqus" is a very vague goal. What problems with Disqus are trying to solve?


I don't want: to serve advertisements, to force people to link to their identity, to cause friction to an already engaged user (no signups form / no captcha), to feel like a bolted on service / widget (I want to feel like part of the site), cluttered ui with to many options.

Hard to put into words the things I don't want Remarkbox to be.


Disqus started with a similar goal, but they had to make changes to make money. What will give you a different path?


Charge site owners for the value added. Stay small but still turn a profit. No investor money so not forced to grow and sell out user base (no ads).

Only add useful features to keep user experience decent.


Would putting together a comment form with something like https://staticman.net suit you better?


>> Ideally, what I would like to do is to have an hackernews post automatically generated for each post, and to redirect people to the HN post if they want to comment, but I am not sure that HN allow this kind of use ?

I would say it wouldn't be allowed as you would end up submitting to HN just 'because' and without direct regard as to whether that post contributes the community. Not all posts are HN related.


>> it wouldn't be allowed as you would end up submitting to HN just 'because' and without direct regard as to whether that post contributes the community

Yes, "Not all posts are HN related", but some of my websites always are HN related.

I don't have one general website for all purposes, I have almost "one website per purpose". One for cloud/infrastructure/k8s&docker/... posts, one for programming posts, one for business posts, ... All of those are quite likely to be "interesting enough" for the HN community.

Of course, for my personnal stuff, for my french stuff, for my music & video & photo stuff, and all the other stuff, I wouldn't even think one second of using HN as comment system.


i used isso (https://posativ.org/isso/) for some static websites. its like a self-hosted disqus.


I always thought it would be cool to have a comments service based on Hacker News. :-)


I've tried pelican, lektor, hugo, and even a cobbled-together flask-based (using frozen pages module) custom static site builder. One of the biggest challenges/time sinks/annoyances of adopting any of these types of platforms is the time spent on the initial wiring up of the templates. Maybe I'm lazy in this regard, but I'd rather use a GUI/WYSIWYG interface to do the initial UX (not talking about design here, only placement of site objects/elements) for the site within the context of the relevant template. I don't mind spending a few minutes on setting up the build environment, setting up any dependencies, because its a local app that's being installed, so I get it that it requires a tiny investment in time. But setting up the templates, boy, that annoys me; especially for small sites which only have few pages and infrequent additions.

Case in point: I really wanted to use lektor; it's elegant persistent storage mechanism (no database required, basically text files organized within folders), and its brilliant idea for use of a local web GUI were what attracted me to it in the first place. But setup - for example - was annoying as hell on Windows (hey some of us can't afford to keep buying Macs!), and then of course after the install/setup comes the wiring of the templates (ugh). I can not imagine a conventional (non-dev.) user - who I would guess is a good candidate to extract great benefit from using a web GUI - won't have the patience or inclination to dive into code to wire up the templates. I don't mean to pick on lektor (I highly respect the team behind this!!), but it is an example of what most of these static site generators do: they mean to simplify things but 1 or 2 aspects of the system seem like quite a time sink.


I've used Lektor recently and I think you're missing its main advantage: it does NOT aim to introduce web dev to non developers or to dramatically simplify the process of wiring up templates. In fact, its use of models is an additional step in the traditional process for static site generators.

BUT...once setup by a developer, Lektor's structure and Mac app allows a non-technical user to edit files and publish changes to a website, which can be hosted on S3 or other options for peanuts and has none of the security issues that afflict Wordpress.

So viewed through the lens of a potential replacement for Wordpress, I think Lektor is pretty phenomenal. The idea of a Static CMS--whether Lektor can pull this off or not--just makes so much more sense than our current CMS model.


Certainly good points. It is definitely headed in the right direction with relation to its use of a web GUI, and its content models (at least once one wraps one's brain around the model approach). Perhaps I should have not expected it to make template wiring easier. Please don't get me wrong, I'm actually a fan of lektor, and wish it to really succeed. ;-)


https://staticsitegenerators.net Boom.


OK, this list rocks! Thanks for sharing it.

Btw, on LibHunt you can compare the projects by dev activity as well - https://selfhosted.libhunt.com/categories/1986-static-site-g...


also https://www.staticgen.com/


I'm very surprised that Sphinx wasn't listed. It powers readthedocs.org and is generally very popular for software documentation.


huh...I would have never through to classify Sphinx as a static site generator, but it is.

I think it's just the context of it being used mostly for API docs and tutorials that it's overlooked.


I'm not so sure Octopress belongs on this type of list anymore.

I've been using it for about 4 years now, and I simply haven't had the time to convert it to anything else but plan to as soon as I can.

Over the last couple years I've dealt with countless type error issues, gem incompatibilities, etc. I have one single machine that Octopress generates my site from now, and it's an old Linux install that I refuse to update (because that will break OP). I believe the author tried his best to make what's essentially a clever Jekyll hack work as well as he could. He's tried creating a newer, smarter version but I'm not sure what the current status is. I'm guessing it's going slowly because most he, like most people, don't have time for such a huge project that isn't paying bills. I appreciate the attempt for sure, it worked great at first.

I don't want to sit and complain about a free product but would caution others about investing in it heavily like I did. I spent a considerable amount of time on overhead with this product as it sits. There are much easier (non Ruby!) solutions out there.


Same here, I appreciate the work that was put in, but it has become a major problem for me. My torment here: http://garfieldnate.github.io/blog/2015/07/20/hacking-throug.... Any time I want to write a new blog post, the release is a big ordeal, and all of the commands are very slow. It's a mess.


Same here. I am right in the middle of moving to metalsmith, it's much saner


I use Hugo for several websites and I enjoy it a lot.

One favorite part is the ability to create content of different types.


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.


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 tends to matter a lot in two cases:

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.


> 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!

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.


Do you have an example that shows this? I'm interested in bringing something like that into my own site.


I wrote it up at http://chriswarbo.net/projects/activecode

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


> 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.


Are you using the syntax highlighting (i.e. Pygments) feature? It significantly raises the generation time.


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.

[0] http://www.getup8.com/post/blogging-in-hugo/


Sort of related and shameless plug but I'm building a "comments as a service" application that isn't disqus. My first target market is static sites.

Check it out here: http://www.remarkbox.com


Also sort of a related, shameless plug--

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.


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.


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!

https://www.lite-engine.com/blog/post_form.html


For anyone comparing options, I've also been using formspree.io for this purpose for quite awhile and it's worked great for me.


This is cool. When do you plan to have paid plans available?

I'm working on some Jekyll landing pages and I need form options for people.


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)


I wrote a self-hosted static-comment system here:

* https://github.com/skx/e-comments/

Seems mine is more basic than yours, due to lack of registration and lack of threading though.


Since we're shameless pluggin', I have a Jekyll plugin that will display an image gallery from a folder (with a single liquid tag).

https://github.com/callmeed/jekyll-image-set


No online sample or demo?


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.


Tried it, liked it. How do you stop spam, link farming, etc.?


Can I tack on a shameless plug too?

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.


One complain about static generators is that they often require the use of HTML or any other markup language. Users just want a management system with a friendly WYSIWYG editor. They don't care if their site is static or generated on the fly by the server.


If you're inclined to eschew hosted comments a lá Disqus and want to own it yourself, note that Discourse supports comment embedding for static sites which I've used for a couple years and have been very happy with: https://meta.discourse.org/t/embedding-discourse-comments-vi...


Have really wanted to look at making WP into a static site generator. Have too many clients using WP that could be using it as a static site but won't move away from it... So the admin backend / familiar publishing interface but generating it out to something that could be dumped into S3z

Some people have done variations of it but not well or easy. Is easy enough to trap events that should trigger page regeneration. Just haven't taken enough time yet.

The AWS CLI has extremely amazing performance, having something that could leverage that kind of multithreading for publishing would be great. Especially for the initial site publish.

If anyone is interested in working on this project or taking it on (I'm happy to contribute ideas and/or money) feel free to reach out. mike503 at gmail.


Sandstorm lets you generate static sites with WordPress: https://apps.sandstorm.io/app/aax9j672p6z8n7nyupzvj2nmumeqd4...

It's a one click install and has additional security / isolation benefits provided by Sandstorm. There are currently a few limitations (e.g. plugin installation requires manual uploading of files).


Been a few years since I looked at WP, but isn't this essentially what the super cache etc. plugins used to do, i.e. generate static versions of pages?


Yes, but there is still a vulnerable (dynamic) WP backend sitting on the same domain name.


That is a great idea for a plugin.


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.


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.


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.


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.


Is there some way to use a static site generator with a flat file database utilising standard CRUD functionality?

To me, using a static site generator and handing off database to another service like firebase or other sas, although works really well and has many benefits is still an external dependency I would rather live without. It also somewhat defeats the point of using a statit site gen for my use case anyway.

This is the main thing stopping me from switching from php/mysql.


I used Lektor and that's what it does, and, AFAIK, it's also what all other SSGs do (Jekyll/Hugo/Pelican/etc).


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.


I'm still using Dreamweaver. WYSIWYG HTML generation.

You really want to lay out web pages in in Markdown?


well, if you are happy with it, stick with Dreamweaver. Markdown is not for layouting, it's more for writing and reading the source code without hurting your eyes ;)


There's also Haunt, written in Guile Scheme:

https://haunt.dthompson.us/


I recommend checking out https://forestry.io/


Co-creator of Forestry here (a CMS for static sites). We're big fans of Hugo and Jekyll (obviously). We use Hugo to power our blog and docs https://forestry.io/blog https://forestry.io/docs.

Using Algolia for search.


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.


Another one: https://ikiwiki.info/


Making static websites for over a decade, now.

(Can make user-editable wikis as well.)


Thanks for the ikiwiki link, I've been looking for a way to do a static wiki for awhile.


I think the future may be CMS-style applications that do static publishing. Either run locally (may be a great use for electron actually), and/or as a service. At least in this space competitively, the biggest complaints tend to center around the amount of manual configuration/changes... opposed to the overhead of say wordpress.

The only downside to static publishing to say S3/ABS is that you loose server-side analytics to some extent.


Dreamweaver seems kind of relevant again with the resurgence of static site generators.

It had (has?) powerful wysiwyg for both developing site layout and mechanics as well as for writing content and can publish content to server.


But then, couldn't you insert the google analytics javascript snippet within the html that gets loaded/served up from S3? Or did you mean something like piwik? I have to think S3 would not be a block here, as many users of static site generators also use some sort of analytics tool.


There are bits that JS based tooling will miss in terms of a bigger picture... they don't represent your real load when you run a site that is getting hit by a lot of different smaller search bots. Of course, once you're on s3 or a similarly cheap static delivery option (and/or CDN), you may not actually care.


I considered using one of these but then I realised all I needed was pandoc and a makefile.


Maybe I'm just oldschool but I've never understood the point of these. What's wrong with varnish + [any dynamic platform]?


Assuming the learning curve to use a static site generator is addressed, I would say simplicity and stability are key points the the users of these appreciate. For example, even though I'm technically savvy, I struggle with Wordpress (wordpress.com) and its unintuitive UI. Almost every other (major?) release changes the locations of items and starts having some new-age UI vs. classic UI differences. I'm guessing that many other dynamic platforms are also bloated a lot when one looks at the features that most people use. Of course, there are dynamic platforms like Ghost [1] that have made it simpler, but Wordpress is still very common (so are other heavy platforms like Drupal and Joomla).

For those who do use these, my best guesses on the benefits are, in no particular order:

1. The speed of transmitting and rendering the pages.

2. Flexibility to host the site anywhere where there's just a web server, even a low powered, low resource one (no need to look for mod_php or for a host that allows running rails or anything else).

3. Simplicity of having all content stored as plain text in files. There's no database to fiddle with or administer.

4. Flexibility to easily create their own templates (probably using a favorite templating engine).

5. Better and simpler control over security since the web server and the underlying OS are the main concerns (without adding several more layers on the server - this may be an oversimplification, but there are fewer things to worry about in general).

6. Better stability (fewer moving parts).

7. Version control of content, if one uses git or something similar.

[1]: https://ghost.org/


cheaper, less maintenance. dynamic platform still needs more setup than static site generator + cheap, html only hosting (e.g. github pages).

besides, mis-configuring a static site generator has way less security implications.


What are people using for hosting? I've thought about using github pages, but css ended up being severely limited.


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 use https://nearlyfreespeech.net. Pretty cheap and I leverage modrewrite rules quite a bit (which is why say github pages won't work for me).


GitLab Pages https://pages.gitlab.io/ it also supports private repos and nearly every static site generator through gitlab ci


I'd like to second Gitlab Pages, I'm using it with Lektor for http://portfolio.stavros.io/ and it's been fantastic so far.


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.


S3 + CloudFront, pushed via the s3_website gem. Free SSL (assuming you're okay with SNI), too.


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.


GitHub (source) => TravisCI (deployment) => S3 (hosting).

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.


I rsync mine to the smallest size of google cloud instance, in order to have control over nginx config and whatnot. It runs me about $4.50/month.


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`.


Check out Aerobatic [https://www.aerobatic.com]

Integrated with Bitbucket, git push deploy, Docker auto-builds of static generators, wildcard SSL custom domains, CDN, etc.

disclaimer: I work at Aerobatic


If you want to use sell hosted, use nginx on Joyent - you can get a 128M container for $2.16/m

Then if your site becomes famous - drop cloud flare in front.

https://www.joyent.com/pricing


Stout (http://stout.is) is a tool which will reliably push your site to S3, and setup all the CloudFront/SSL/etc. magic for you.


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.


https://branchable.com/


http://nodechef.com


Nobodu mentioned Hakyll, Haskell static site generator motovated by Jekyll.

I've been used it for over 4 yrs and still surprising.


Here's my experience: I previously used Middleman to build my blogshop and all was fine until I added more complexity. The codebase grew large and that's when I really hit the (Ruby) language's limits (too much type checking).

My intention is not to turn this into a language war, but I think using a good static site generator written a strongly typed language helps a lot. I considered Hugo, but eventually I decided to write my own in Scala and it has served me well.

A good static site generator should unleash a slew of goodies including code-reuse, viewing your website as a collection of functional components rather than just a bunch of partials. It's almost a full blown MVC project.

For example, my blogshop (not exactly 100% static) has 3 types of "Marketing" components - one of them is a widget asking for email subscriptions, the other is a popup for displaying offers, or email subscriptions based on the view it is used in, based on the parameters passed to it and finally the last one is a recommendation engine.

I don't trust Disqus nor Facebook especially after Facebook lost all my comments once (long ago, though). So, I host microservices for each of the components of my blogshop - One for recommendations, one for comments and so forth. They all live inside Appengine and I hardly hit the paid tier. The best part is that my blogshop can be written in any language I like and I can afford to write my other components in other languages. For example, I wrote my recommendation engine in Python, wrote my comments system in Scalatra. They all communicate with JSON APIs with each other.

For my authentication service, I use something called Apache Shiro. So, my static website is basically talking to each of my service through Ajax and injecting content using JS from the response from my microservices.

I know this isn't everyone's cup of tea, but it really works well for me and is much better than using Wordpress which is something generic that is forced to fit into my workflow/business model.


.. nanoc, http://nanoc.ws/


I made a somewhat unconventional static site generator in Powershell, as part of my Arkdata project. It produces flat HTML reports every minute, which IIS (or any other web server software) can simply serve. It calls a JavaScript file, as I was playing with sortable columns, but works without the file. I use a mobile CSS file for better mobile display too.

Github: https://github.com/Gilgamech/ARKScrape

Demo site (IIS up, but it's not currently generating reports): http://gilgamech.com/ark/PvP-Hardcore-OfficialServer92.html


And I guess, Lektor and Pollen are still the only ones with a (dynamic) web interface for writing articles and then exporting them (statically)?

Besides Bricolage (ancient, abandoned?, never got it to work – even the VM image they provide as a demo) and Movable Type (expensive), of course.


here is a better "article"

https://staticsitegenerators.net/


http://www.staticgen.com (hosted and maintained by Netlify, article's author) is similar although stats differ...


This is very handy, thanks for sharing


We are running a React based static site using https://instant.cm for content management. Works like a charm and Instant basically works on every static site.


For my website I have a custom python script, and I use RestructuredText for markup. If I started now, I would replace the script with a set of Makefiles... or better use any existing generator.


Hugo supports rst, for what it's worth. There's still time to make the jump :)


Thanks, I've never heard about Hugo, I've seen Sphinx mentioned by mixmastamyk. But... I wish I had enough spare time to do migration. My TODO list is getting longer and longer. :)


Sounds like sphinx.


Static site generators are easy to learn and host for free on Github pages but setting up TLS with a custom domain name is a pain. I currently have Cloudflare in front handling that for me.


Check out netlify (https://www.netlify.com) - we'll let you setup https with let's encrypt as a one click operation.


Stout can setup a static site for you using Amazon's free SSL: http://stout.is


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.

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/


> Nobody's mentioned Hexo yet

Hexo is #2 in the list in the article...?


Sorry, I meant commented on their experiences with it.


In my preliminary testing of Hexo I was immediately annoyed that it converted my single line breaks in Markdown to <br>.


For a client I built a custom one (~150loc) that uses react templates and builds files from markdown on contentful. By using react templates, the static website and frontend code can be written in the same manner and our designer can start with something then hand it off to our frontend eng without fuzz. The designer wanted to learn react so she's technical enough to write jsx (which might not be the case for everyone). Ping me if we should see about OSS.


http://www.staticgen.com/ seems to provide a more exhaustive (and searchable) listing


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?


> single-page app SSGs

How does that work? Isn't "single-page app" the exact opposite of a "static site"?


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.


Single page app uses .js to load page inside index.html w/ push state.

I like this 'serverless' approach.


It most certainly is not serverless.


Do you read? Ex: http://martinfowler.com/bliki/Serverless.html

Or dozens of other? You are not in a cave.


Who gave Badri Janakiraman authority to define what serverless is?


martin fowler is an authority.

Here so you can try http://bfy.tw/7nJE


Found this[1] site some time ago demonstrating an SPA-style static site with no javascript. You end up having to download every article/page though.

[1]: https://www.smashingmagazine.com/2015/12/reimagining-single-...


Jekyll has the significant advantage of support Asciidoc out of the box as Asciidoctor is written in Ruby. We really need alternative asciidoc implementations.


Please note that asciidoctor already is an alternative implementation. The original asciidoc tool (http://www.methods.co.nz/asciidoc/index.html) is written in python.

Both, the original and asciidoctor, offer a CLI tool to convert asciidoc to different formats (and there is always pandoc). Additionally, asciidoctor aims to integrate with JVM languages courtesy of JRuby. So you have multiple implementations callable (in one way or another) from any language imaginable.


Also, do you know any SSG which allow me to have a really complete home page like http://demo.tagdiv.com/newspaper/ , where I can clearly display separated category with last articles by category, and with a thumbnail automatically attached to the post ?

Sort of a "magazine theme" or a "newspaper theme" for a SSG.


I'm not sure exactly what you mean, mainly because I think all the SSGs can do it. I tried Lektor recently, and I don't see why you shouldn't be able to do exactly this. It's not even hard (unless I'm missing something).

EDIT: Maybe what I'm missing is that other SSGs are very opinionated, while Lektor is not.


For those thinking of writing a ssg as a challenge, I recommend reading Rhodes and Rocco's _500 Lines or Less_ [1] chapter about an incremental build system. It describes the general strategy behind tup.

[1] http://aosabook.org/en/500L/contingent-a-fully-dynamic-build...


Great link! I'm building my own SSG for fun and this is something I've been thinking about tackling for a while.


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.


"These days, speed and security is the name of the game." And it´s no problem to achieve both with WordPress. Maybe my mileage varies enormously from everybody else, but I am maintaining about 40 WordPress instances.

We have tools to manage updates remotely, make fully automated daily backups, all sites are rated with 85 or more points on Google Page Speed Insights (YSlow and Pingdom Tools don´t rate bad either), we didn´t have any breaches or hacks in the last two years (been in the company for that long) and our clients can easily manage their sites with the built-in tools from WordPress. We have locked the sites down, eliminating attack vectors as far as we can. All sites are using caching tools or even full page caching to improve the speed. No complains and complications at all. Oh, and we have comments and user registrations and more...

It seems most people just can´t handle WordPress the right way. It´s complex software and you have to know (and learn) what you are doing.

Installing the first plugin you stumble upon, ideally from a shady developer who sells it to a malware distributor 2 months later, is a pretty fine way to run you into "WordPress is slow and insecure". Free themes, always install several at once , you never know when you need one, are another great way, too.

But yeah, just throw some fancy JS framework and Markdown at the problem and then start to wonder how you could possibly get some commenting system up and running.

WordPress is quite fine software. For sure, it has flaws and some of them get fixed slower than you would wish, but it´s not bad in the end, if you know what you are doing. Finding people who know what they are doing is probably hard, but that´s the same for everything.


I don't disagree that wordpress is fine, but claiming it's easy to manage after saying you have a team to manage yours and have setup a load of software to handle its complexity for you is odd. And then you say "most people just can´t handle WordPress the right way", which is basically another way of saying "it's not easy".

And 85 points on Google page speed insights or yslow are generally useless metrics. They give as much weight to complaining about a 5kb image not being compressed properly as not having a cdn. It's automated dumb, they're stupid tools with quite often stupid rules. Like I just checked a site I'm responsible for and lost points for not compressing a js file that would save 524B. Yes, that's bytes.

That's not contributing to site slowness at all. And yet at no point did it say "hmm, you've got rather a lot of poorly optimized js there".


I am a one man army on that point, "we" is "our company", websites are not our main business. ;-)

The only software I use regularly is InfiniteWP to have a look for updates. Although it sends me a mail to my "status messages" slack channel, so no big deal on that end. Backups run automatically by BackWPUp Pro, caching and lock down are done when setting up/finishing a new site, so there´s not really much software involved at all.

85 points or A ratings or whatever alone are "just metrics" for sure. But I don´t think that I need to tell you that if you want to reach and keep a high value on those scales, you have to take care of compressed CSS and JS, auto-optimized images, caching, fast servers etc. pp.

Which in the end leads to fast(er), better accessible websites without dropping backend usability or features.


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.


If you like WordPress as a writing and management tool, it's worth noting that there are several static site generators for WordPress.[1][2]

[1] http://en.staticpress.net/, https://github.com/megumiteam/staticpress [2] https://wordpress.org/plugins/simply-static/


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.

[1] https://github.com/jekyll/jekyll-admin


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]

[0] http://prose.io/

[1] https://github.com/shakna-israel/haddonRevamp/blob/gh-pages/...


Shameless plug...

https://github.com/Malcx/DamnSmallBlog


You can just develop it on a Cloud9 web IDE.


What would be a sane deployment workflow for a static site generator, so that the static content ends up behind an Apache web server in my box?

edit markdown -> push github --> server does a pull -> builds -> deploy ?


I'm a big Gatsby fan.


Ive been trying to make Sandra.snow work for me but it seems to be so focused on azure and ssg-as-a-service that I can't figure out the simple parts.


Another good alternative is Grav https://getgrav.org


That's not a SSG, is it? Last I remember reading about it, it was still a dynamic site, just powered by a flat file DB.


What about using whatever engine you want, then extract static pages with a script using good ol' wget -r ?


I sort-of-but-not-quite did this when migrating my old dynamic site to static generation: I used my model API to build a list of all the pages and then faked requests by building my own request objects that I called my Sinatra app with.

Made for a quick and dirty way of reusing my old code, and means I can still run the dynamic version for dev/testing.


https://phenomic.io is missing in the list


Have you used Phenomic? What's the difference to Gatsby?


I was going to use it but stuck with Jekyll for now, but they have a FAQ page for that [0].

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


I've been using cactus and really like it. Really simple and uses the django template engine.


Why is that website only using the middle of the page, and has a blank line between every line of text.

Is there some competition for who can use as little of my screen as possible in a useful way?


It's to increase readability. An ideal column width can help users to scan through the paragraph effortlessly.

http://ux.stackexchange.com/questions/3618/ideal-column-widt...


Anything that supports .docx documents?


Sure. Just save it as the terrible HTML that Word generates on its own.


What why?


There are people who like it.


OP is a paid shill for Netlify.

Previous thread: https://news.ycombinator.com/item?id=12401849


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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: