Static Website Generators
netlify.com
netlify.com
[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
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.
```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```
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.
Examples: Contentful, Prismic.io, Built.io, CloudCMS
Full disclosure: I work for Contentful
https://www.contentful.com/developers/docs/tools/staticsiteg...
Unusual position - source access is quite rare for commercial software, isn't it?
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.
So long as your URLs are relative, it should work a treat with any CMS.
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.
Well, I guess that works if you have a VW Beetle ;)
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 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
If someone is prepared to accept this it's not that hard to accept generating the html page yourself and uploading that.
Or being greeted with a white page period if you're using a non-JS enabled HTML client (noscript, CLI browser).
Don't let the door hit you on your way out
Than spend time catering to outliers...
You're really better off using a static conversion tool, or using markdeep as a static conversion tool (with ?export)
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.
Not with any search engine that matters.
Somebody, please make this.
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/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.
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.
Redirecting them to the HN pit of cynicism and leave-no-stone-left-unturnedism sounds awful. :)
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.
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.
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.
One of the design goals is to _not_ be disqus.
Hard to put into words the things I don't want Remarkbox to be.
Only add useful features to keep user experience decent.
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.
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.
Btw, on LibHunt you can compare the projects by dev activity as well - https://selfhosted.libhunt.com/categories/1986-static-site-g...
I think it's just the context of it being used mostly for API docs and tutorials that it's overlooked.
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.
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
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).
/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/skx/e-comments/
Seems mine is more basic than yours, due to lack of registration and lack of threading though.
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.
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).
* 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.
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.
You really want to lay out web pages in in Markdown?
Using Algolia for search.
(Can make user-editable wikis as well.)
The only downside to static publishing to say S3/ABS is that you loose server-side analytics to some extent.
It had (has?) powerful wysiwyg for both developing site layout and mechanics as well as for writing content and can publish content to server.
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/
besides, mis-configuring a static site generator has way less security implications.
Then if your site becomes famous - drop cloud flare in front.
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
I've been used it for over 4 yrs and still surprising.
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.
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
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 also wrote up all the stuff I learned migrating and existing Wordpress blog to static:
Hexo is #2 in the list in the article...?
Does 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-...
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.
Sort of a "magazine theme" or a "newspaper theme" for a SSG.
EDIT: Maybe what I'm missing is that other SSGs are very opinionated, while Lektor is not.
[1] http://aosabook.org/en/500L/contingent-a-fully-dynamic-build...
I am currently trying out Hexo which seem to work just time too.
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.
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".
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.
[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/...
edit markdown -> push github --> server does a pull -> builds -> deploy ?
Made for a quick and dirty way of reusing my old code, and means I can still run the dynamic version for dev/testing.
There were also a few mentions of Phenomic on Gatsby's discussion from a while back [1]. Search for it on that thread.
Is there some competition for who can use as little of my screen as possible in a useful way?
http://ux.stackexchange.com/questions/3618/ideal-column-widt...
Previous thread: https://news.ycombinator.com/item?id=12401849