Show HN: Gutenberg – A static site engine as a single executable(getgutenberg.io)
getgutenberg.io
Show HN: Gutenberg – A static site engine as a single executable
https://www.getgutenberg.io
155 comments
I'm aware of it, the majority of my static sites are still using Hugo since I haven't touched them for ages.
The two features I really wanted when I started Gutenbrg were Sass compilation and syntax highlighting built-in: a clean build of my blog with Hugo + Pygments was taking ~20s for ~20 pages at the time and needed virtualenv for Pygments, Node.JS/npm for gulp-sass and the Hugo binary. Hugo now has syntax highlighting in Go so that part should be better though.
Themes are supported in Gutenberg but there is only one so far as I didn't want to spend time on that yet. It is pretty fast to port themes though - took me about 10 minutes for Hyde: https://github.com/Keats/hyde - so I might port ~10 or so next week to get the ecosystem started.
The two features I really wanted when I started Gutenbrg were Sass compilation and syntax highlighting built-in: a clean build of my blog with Hugo + Pygments was taking ~20s for ~20 pages at the time and needed virtualenv for Pygments, Node.JS/npm for gulp-sass and the Hugo binary. Hugo now has syntax highlighting in Go so that part should be better though.
Themes are supported in Gutenberg but there is only one so far as I didn't want to spend time on that yet. It is pretty fast to port themes though - took me about 10 minutes for Hyde: https://github.com/Keats/hyde - so I might port ~10 or so next week to get the ecosystem started.
> with Hugo + Pygments was taking ~20s for ~20 pages at the time
That's long! Glad I wrote my own in Haskell (and I'm a Gopher! just did it to get my feet wet in Hs) --- 92 pages in 1s (full rebuild; incremental is of course just a fraction) feels good to me now. http://github.com/metaleap/haxtatic
No CSS magic tooling though. Just don't find vanilla CSS troublesome enough yet =)
Edit: I saw you do ~10k pages in ~60s so guess we can see the Rust bonus there now --- certainly beats my extrapolated expected ~5-6k for the same time-frame. (Though I hope you were talking there about complex layouts with component-like-sub-templates / programmatic sub-renderers and date-time formatting, not just dumping-inner-markup-into-outer-markup =)
That's long! Glad I wrote my own in Haskell (and I'm a Gopher! just did it to get my feet wet in Hs) --- 92 pages in 1s (full rebuild; incremental is of course just a fraction) feels good to me now. http://github.com/metaleap/haxtatic
No CSS magic tooling though. Just don't find vanilla CSS troublesome enough yet =)
Edit: I saw you do ~10k pages in ~60s so guess we can see the Rust bonus there now --- certainly beats my extrapolated expected ~5-6k for the same time-frame. (Though I hope you were talking there about complex layouts with component-like-sub-templates / programmatic sub-renderers and date-time formatting, not just dumping-inner-markup-into-outer-markup =)
I would expect lower timings, see https://github.com/piranha/gostatic/blob/master/README.md#sp...
In Go, sure. In Haskell, for some app use-cases (and I believe static-site-gen is one such) it takes endless patience and tweaking to reach on-par performance with let's say "systems languages". There's scenarios where Haskell's lazy-evaluation may save a running program a lot of unnecessary work theoretically, but in practice I found there's not too many, compared to any eagerly-evaluated program written by a not-a-total-newbie-programmer. Certainly not such batch text-file processing. Then you'd easily parallelize your Go program wherever it makes sense, which in Haskell I didn't do but relied on whatever magic the compiler sprinkles in (if any) via compiler-options =)
Also I'm having a rather excessive template system there!
As long as it doesn't take 20s for 20p.. or I have to manage 10-100k-page sites..
Also I'm having a rather excessive template system there!
As long as it doesn't take 20s for 20p.. or I have to manage 10-100k-page sites..
hugo has recently started using a go-based syntax highlighter that's built in, called chroma i believe (https://github.com/alecthomas/chroma), which is supposed to be much faster than pygments.
anyways, this project looks very interesting to me, i also currently use hugo for my static sites, but this looks much simpler, and the sass compilation is a nice feature too.
anyways, this project looks very interesting to me, i also currently use hugo for my static sites, but this looks much simpler, and the sass compilation is a nice feature too.
And Hugo is just a re-write of https://jekyllrb.com/
It's the ultimate Magpie progression.
Ruby -> Go -> Rust
It's the ultimate Magpie progression.
Ruby -> Go -> Rust
I'm not sure how that's true. Do you have a reference on why it's a rewrite of Jekyll, or is it just because Jekyll and Hugo do the same thing and Jekyll was there before Hugo?
More choices is not necessarily a bad thing
Most of the time is just wasted effort. Yes, more ideas features, use cases, but I usually prefer one thing which is very high quality instead of a lot of small things which are never complete.
Its free software, and I can definitely relate to Keats that there are a lot of software projects I'd look at and think about participating in and just concede I don't want to work in my free time in whatever language its written in.
Go is definitely one of those languages. My most definitions I have not given it the proper chance, but the lack of generics just turns me off as an avid user of C++ and Rust, in the same way Java has always turned me off for lacking functional features other languages have had for decades.
For example, I've often thought about contributing webrtc peer support to various torrent libraries, but when I dig into them (libtorrent, libtransmission, libktorrent, etc) they are all 15+ years old codebases of either C99 or pre-C++03 C++. Considering I'm coming from Rust in my free time I know I would just drop the project within a week because of frustrations with the tooling and language.
If I ever really wanted to go the extra mile, I'd use it as a learning experience for some of the Rust GUI bindings and write my own torrent library. Reinventing the wheel yes, but I'd rather spend right now a thousand hours in Rust than a hundred in a really old C code base. I imagine many of these developers like Keats feel the same way.
Go is definitely one of those languages. My most definitions I have not given it the proper chance, but the lack of generics just turns me off as an avid user of C++ and Rust, in the same way Java has always turned me off for lacking functional features other languages have had for decades.
For example, I've often thought about contributing webrtc peer support to various torrent libraries, but when I dig into them (libtorrent, libtransmission, libktorrent, etc) they are all 15+ years old codebases of either C99 or pre-C++03 C++. Considering I'm coming from Rust in my free time I know I would just drop the project within a week because of frustrations with the tooling and language.
If I ever really wanted to go the extra mile, I'd use it as a learning experience for some of the Rust GUI bindings and write my own torrent library. Reinventing the wheel yes, but I'd rather spend right now a thousand hours in Rust than a hundred in a really old C code base. I imagine many of these developers like Keats feel the same way.
But you're making the wrong assumption that effort is fungible. That if something new didn't exist, that the effort would have instead happened on the old thing.
I don't understand why people think this way since those same people certainly don't operate that way. It's just backseat driving how other people spend their free time. Just comes off as a circlejerk.
I don't understand why people think this way since those same people certainly don't operate that way. It's just backseat driving how other people spend their free time. Just comes off as a circlejerk.
> backseat driving how other people spend their free time
I like that phrase a lot, captures a lot about comments on OSS projects here in HN and elsewhere.
I like that phrase a lot, captures a lot about comments on OSS projects here in HN and elsewhere.
Just because you prefer other things doesn't mean it's wasted effort. Even if no one else used it (which isn't the case here), there's nothing wrong with working on a side project just to build your skills.
that's totally different. You can do whatever you want in your free time as a hobby, or whatever reason, but I mean if it's not just for joy, and anything, and you want to solve a real problem, it would be better for everybody if you would just join to an already existing community and improve the thing already exists.
So basically I don't find it a valid reason to make an entirely new thing because the existing solutions did not worked the way you wanted.
So basically I don't find it a valid reason to make an entirely new thing because the existing solutions did not worked the way you wanted.
The issue with that reasoning is that according to you, everyone should just work on the first popular tool and never create a new one. People like different things and cramming all opinions into one thing, if even possible, usually don't work out.
I mentioned it in another comment (https://news.ycombinator.com/item?id=15511028) but none of the things I wanted to change in Hugo could have been done.
I mentioned it in another comment (https://news.ycombinator.com/item?id=15511028) but none of the things I wanted to change in Hugo could have been done.
I kinda hate the template syntax, though.
Example:
{{ if and (or (isset .Params "title") (isset .Params "caption")) (isset .Params "attr")}}
Example:
{{ if and (or (isset .Params "title") (isset .Params "caption")) (isset .Params "attr")}}
Yeah, that's the worst part of Hugo by far for me. The default template engine is just terrible.
Are there non-default ones? I also don't love Hugo's template engine.
There are 2 others: https://gohugo.io/templates/alternatives/ but I don't like them either x)
Love Hugo but really wish it supported dynamic page generation like Middleman [0].
[0] https://github.com/gohugoio/hugo/issues/140
[0] https://github.com/gohugoio/hugo/issues/140
Still, it's bring your own asset pipeline to Hugo, which is a pain. Middleman used to have it, but now its moving away from it.
The general trend is to decouple the asset-pipeline and the site generators though... Except for the amazing jekyll-assets...
Even for jekyll-assets though, it's often faster to run stuff through node-sass first. Also with npm scripts and yarn, the pipeline is exactly what you need and nothing else..
Well title should be "Websiter generator No. 3487", so we wouldn't need to write such comments.
(You have no contact info in your profile, so this has to be a random comment: are you going to reverse the outcome of https://news.ycombinator.com/item?id=15189682 anytime? Was just curious, wanted to play and never got to.)
Huh. Interesting.
...and it's dead. Wow. :(
This really doesn't work. Hah.
Thanks for replying though.
I have a strong theory about what inspired this account's original owner's username choice. I wonder if you're aware...
...and it's dead. Wow. :(
This really doesn't work. Hah.
Thanks for replying though.
I have a strong theory about what inspired this account's original owner's username choice. I wonder if you're aware...
Hey, just took a moment to tell you it takes courage to post a Show HN about whatever it is that you built. I understand the tone of most of the comments about Gutenberg in here, but... stick to your plan and just ignore them, congrats for pushing something out of the door :-)
Could you suggest a more general purpose static site generator? 99% of them target blogs but most of times you need a bit more. Hugo looks like the most advanced of them but its documentation leaves much to be desired and doesn't include real-life examples of different projects.
I'd love to have a tool to generate a catalogue, a simple journal, etc.
I'd love to have a tool to generate a catalogue, a simple journal, etc.
Have you had a look at Lektor (https://www.getlektor.com). It's from the creator of Flask, and is a static CMS implemented in Python. It goes beyond just simple blogging, and allows you to define models for any entity you want to store. It's extremely flexible. It also has a pretty decent UI for writing things in, and is Dropbox-friendly for non-tech users, too.
The landing page explains the benefits quite well. Also, it has good examples of Lektor being used for a catalogue: https://www.getlektor.com/showcase/architekten-ronacher/ (direct link to the interactive version http://www.architekten-ronacher.at/projects/)
The landing page explains the benefits quite well. Also, it has good examples of Lektor being used for a catalogue: https://www.getlektor.com/showcase/architekten-ronacher/ (direct link to the interactive version http://www.architekten-ronacher.at/projects/)
If you want lots of customization and are friendly with Python I would suggest rolling your own project with Flask and Flask-Freeze. You get all the benefits of complete customization from URLs to templated pages and scripts. Really anything. While this isn't a canned solution, it is a really robust solution.
Just to continue on...
With this setup you can have anything (ANYTHING!) powering the data side. From CSVs to any SQL server local or remote, directories of markdown files, directories of ZIP archives, random (or deterministic) numbers or generable sequences.
Flask gives you so much freedom with the backend implementation you can draw from anywhere. You just need to define the URL patterns and supply the functions that respond with HTML. Flask-Freeze then crawls your site (or a list of pages you specify) and renders the HTML with whatever function you supplied. Couldn't be easier to understand and it is unbelievably flexible.
With this setup you can have anything (ANYTHING!) powering the data side. From CSVs to any SQL server local or remote, directories of markdown files, directories of ZIP archives, random (or deterministic) numbers or generable sequences.
Flask gives you so much freedom with the backend implementation you can draw from anywhere. You just need to define the URL patterns and supply the functions that respond with HTML. Flask-Freeze then crawls your site (or a list of pages you specify) and renders the HTML with whatever function you supplied. Couldn't be easier to understand and it is unbelievably flexible.
Metal. http://www.metalsmith.io/
For sites which are closer to books, gitbook is an option as well. https://www.gitbook.com/
For sites which are closer to books, gitbook is an option as well. https://www.gitbook.com/
You may be better served by Lektor: https://www.getlektor.com/
Middleman is still my favorite static site generator and it has exactly that in mind: General purpose website that may or may not feature a blog. If you're already familiar with ruby it's an obvious choice. If not, I'm sure there are countless alternatives.
Do you have an example of catalogue/journal that you would want to do? Gutenberg can do blogs but I originally built it for any kind of content: landing page, landing page + knowledge base, landing page + blog etc so it should work in theory.
However, if your data is coming from an API/database something like Gatsby (https://www.gatsbyjs.org) would be better.
However, if your data is coming from an API/database something like Gatsby (https://www.gatsbyjs.org) would be better.
Have you looked at the Hugo themes and the tags on the right side?
Here are themes tagged Portfolio: https://themes.gohugo.io/tags/portfolio/
I actually find many themes that are non-blog based in there.
Here are themes tagged Portfolio: https://themes.gohugo.io/tags/portfolio/
I actually find many themes that are non-blog based in there.
A theme isn't exactly what's asked... Themes are just... A lot of work put into making an unwieldy system meant for blogging look like something else.
From what I have seen, Hugo themes are a combination of visual makeover plus some even requiring a certain structure of site content. Here's an example theme DocDock[1] that is not just a blog made to look like something else.
Again, YMMW.
[1]: https://themes.gohugo.io/theme/docdock/content-organisation/
Again, YMMW.
[1]: https://themes.gohugo.io/theme/docdock/content-organisation/
Look into Wyam (https://wyam.io/). It has a concept of "recipes" which are in essence a custom static site generators themselves but which feed into the core Wyam engine.
I know I'm late to the party here, but I love Statik
(https://github.com/thanethomson/statik) for this.
Vote for Middleman.
I'm working one on, it's more of a static app builder though:
github.com/tmzt/isymtope
Working on a major push/update.
github.com/tmzt/isymtope
Working on a major push/update.
Genuine question: what does the term "static app" refer to? As I understood it, "webapp" explicitly refers to a site is not static.
Very good question, and one I've been trying to answer in a concise way.
Essentially it's "static" in the sense that it could be used to generate a fully rendered page that is also an interactive (javascript) application.
It can also process actions on the server and generate a new HTML page in response to that that will be hydrated in the client.
It's an attempt to give you the best-of-both-worlds with a SPA, but one that arrives fully-rendered so there are no delays loading content. It's an SSR approach but without using a javascript engine or framework on the server, the server-side component is completely developed in Rust.
As far as "static app", I would say it's closer to something like Disqus being used on a static doc site or Firebase used for storage when github pages are used to host a site. It means it doesn't rely on server-side rendering to function as a PHP or ASP.net site does, but it can use it if available.
Essentially it's "static" in the sense that it could be used to generate a fully rendered page that is also an interactive (javascript) application.
It can also process actions on the server and generate a new HTML page in response to that that will be hydrated in the client.
It's an attempt to give you the best-of-both-worlds with a SPA, but one that arrives fully-rendered so there are no delays loading content. It's an SSR approach but without using a javascript engine or framework on the server, the server-side component is completely developed in Rust.
As far as "static app", I would say it's closer to something like Disqus being used on a static doc site or Firebase used for storage when github pages are used to host a site. It means it doesn't rely on server-side rendering to function as a PHP or ASP.net site does, but it can use it if available.
> a catalog, a simple journal, etc.
Would you please describe the data model you have in mind a bit more?
Would you please describe the data model you have in mind a bit more?
One thing it would get people's attention would be how much time a compilation test of 150K or more posts / pages would take to finish with Gutenberg.
That is something we, users, have discussed with the Nikola team and it's something others have already discussed about it with other static website generators.
Here's the discussion in case you are interested in: https://github.com/getnikola/nikola/issues/2842
That is something we, users, have discussed with the Nikola team and it's something others have already discussed about it with other static website generators.
Here's the discussion in case you are interested in: https://github.com/getnikola/nikola/issues/2842
I haven't really looked into performance that much yet but it is rendering one of my bench site of 10k pages in 61s on my 4 years old laptop. Gutenberg does load all posts in memory as well though so it's likely to run into the same issue.
Pre-compiled binaries: https://github.com/Keats/gutenberg/releases
Didn't notice those at first. Read the "installation" page, but jumped straight to the subheading "mac os x" and thought it was unavailable.
Maybe you could have a"download for <Mac OS X/Windows>" button on the main page that would lead to the relevant binary for the visitor's platform.
Didn't notice those at first. Read the "installation" page, but jumped straight to the subheading "mac os x" and thought it was unavailable.
Maybe you could have a"download for <Mac OS X/Windows>" button on the main page that would lead to the relevant binary for the visitor's platform.
> download for <Mac OS X/Windows/Linux>
Corrected that for you Bemmu :)
Corrected that for you Bemmu :)
Good idea.
Hopefully someone will package it for Brew/Chocolatey (is that what is used on Windows?) but it's a good stopgap solution.
Hopefully someone will package it for Brew/Chocolatey (is that what is used on Windows?) but it's a good stopgap solution.
I think most people are still just running installers on windows
My first impression was that this was related to Project Gutenberg; that might raise trademark issues.
Can you even trademark the name of a historic person like that? He's been dead for 549 years.
Could I start using Einstein (dead for 62 years) or Galileo (dead for 375 years) as a trademark?
Could I start using Einstein (dead for 62 years) or Galileo (dead for 375 years) as a trademark?
Trademarks operate within a product category.
The USPTO lists 8 different categories where "Gutenberg" is currently used as a trademark and a further 13 "dead" categories where it was used historically.
If you wanted to use Gutenberg in a different category – e.g. The Gutenberg fruit smoothie maker – you'd probably have no difficulty trademarking the name.
http://tmsearch.uspto.gov/bin/showfield?f=toc&state=4810%3A1...
The USPTO lists 8 different categories where "Gutenberg" is currently used as a trademark and a further 13 "dead" categories where it was used historically.
If you wanted to use Gutenberg in a different category – e.g. The Gutenberg fruit smoothie maker – you'd probably have no difficulty trademarking the name.
http://tmsearch.uspto.gov/bin/showfield?f=toc&state=4810%3A1...
Yup. Baby Einstein is trademarked:
https://en.wikipedia.org/wiki/Baby_Einstein
https://trademarks.justia.com/757/49/baby-75749035.html
https://en.wikipedia.org/wiki/Baby_Einstein
https://trademarks.justia.com/757/49/baby-75749035.html
I'm pretty sure Einstein's name and image are managed by the Hebrew University of Jerusalem.
Salesforce actually licensed the Einstein name from his estate for their new AI push[1], so it would seem that you can...
[1] http://www.adweek.com/digital/how-salesforce-snagged-einstei...
[1] http://www.adweek.com/digital/how-salesforce-snagged-einstei...
Or, say, "Tesla"?
Steve Gutenberg would differ in opinion.
I believe the Stonecutters own the trademark on his name
I don't think that's how trademarks work.
Still, terrible and unoriginal name choice:
https://github.com/search?q=gutenberg
Still, terrible and unoriginal name choice:
https://github.com/search?q=gutenberg
"Terrible and unoriginal name choice" is probably a little dramatic:
https://github.com/search?utf8=%E2%9C%93&q=gutenberg+static+...
https://github.com/search?utf8=%E2%9C%93&q=gutenberg+static+...
I have a feeling the name will be drowned out with WordPress being in the same market and their new editor also being named Gutenberg
Wordpress? What about Project Gutenberg?
https://www.gutenberg.org/
https://www.gutenberg.org/
Not as new, not as likely to be in all the tech news
I do not honestly understand the negative comments, including the "Hugo did that already" since the dev points to important differences such as SASS.
I very much look forward to testing the binary (not knowing Rust I see no reason to try to play with the code). Just one preliminary feedback: gutenberg --help does not indicate any options. But if I could make a suggestion that might help set this apart a bit from other markdown-site-generators, it would be to have real support for footnotes. Most seem to use the GitHub flavor which is sorely lacking in that regard and it's unfortunate that most generators do not address this vital need for many of us.
Thank you for your work and for sharing this project.
I very much look forward to testing the binary (not knowing Rust I see no reason to try to play with the code). Just one preliminary feedback: gutenberg --help does not indicate any options. But if I could make a suggestion that might help set this apart a bit from other markdown-site-generators, it would be to have real support for footnotes. Most seem to use the GitHub flavor which is sorely lacking in that regard and it's unfortunate that most generators do not address this vital need for many of us.
Thank you for your work and for sharing this project.
Footnotes are supported, an example in Phil blog: https://os.phil-opp.com/multiboot-kernel/
Search for small hack and you can see one
Search for small hack and you can see one
The homepage misses how its different/better than all the other solutions. Rust ftw?
For my own usecase, Sass and syntax highlighting built-in are the things I wanted - Hugo now has highlighting built-in too though - and all of that in a single binary. I don't want to mess with virtualenvs or JS packages.
Compared to Hugo (which is what I was using until then), it has:
- the mentioned Sass compilation
- a much better template engine (I'm a bit biased there since I also wrote it)
- assets colocations: keep images etc next to the post
I also find it much easier to use than Hugo but I wrote Gutenberg for my own usecase so this point would need external validation.
I wrote a bit about the motivation when I released the initial version on my blog: https://vincent.is/announcing-gutenberg/ but I agree it should be better communicated on the landing page.
Rust is an implementation detail: it could have been done in any language compiling to a binary, I just picked the one I prefer.
Compared to Hugo (which is what I was using until then), it has:
- the mentioned Sass compilation
- a much better template engine (I'm a bit biased there since I also wrote it)
- assets colocations: keep images etc next to the post
I also find it much easier to use than Hugo but I wrote Gutenberg for my own usecase so this point would need external validation.
I wrote a bit about the motivation when I released the initial version on my blog: https://vincent.is/announcing-gutenberg/ but I agree it should be better communicated on the landing page.
Rust is an implementation detail: it could have been done in any language compiling to a binary, I just picked the one I prefer.
This is cool, and props for scratching your own itch, but this does seem like an incremental/niche improvement over Hugo. I'm curious if you talked to the Hugo community about supporting those features? I don't mean to imply that you should have done so--"I wanted to build my own" is a totally valid reason not to bother.
I don't really like the template engine available in Go (especially the godawful one in the std) so I would have needed to write one or use pongo2 but probably wouldn't have been accepted in Hugo: https://github.com/gohugoio/hugo/issues/1359
The assets colocations issue was raised in 2014 and it might come soon but I don't think it's there yet: https://discourse.gohugo.io/t/keep-images-content-together/5.... Same thing for Sass compilation: https://discourse.gohugo.io/t/support-for-html-css-js-prepro...
The assets colocations issue was raised in 2014 and it might come soon but I don't think it's there yet: https://discourse.gohugo.io/t/keep-images-content-together/5.... Same thing for Sass compilation: https://discourse.gohugo.io/t/support-for-html-css-js-prepro...
FWIW I'm glad you wrote this. Having looked at Jekyll alternatives before, the field is severely lacking especially in terms of static sites generators that don't immediately assume you're publishing a blog.
Cool! Thanks for the information. Good luck with Gutenberg!
Cobalt static site generator is quite popular with Rust developers:
https://github.com/cobalt-org/cobalt.rs
Just moved from Jekyll to Hugo and I'm planing to stay there. BTW it's nice to see more alternatives to Jekyll coming on the scene.
Ideally the perfect static site system should be a meta language, like one of the wiki languages, for which several solutions could be used to translate to HTML etc...
We shouldn't have to rewrite our blogs every time a new cool programing language comes around!
We shouldn't have to rewrite our blogs every time a new cool programing language comes around!
Is this what you mean:
I write my blog posts in Org mode. So I wrote this package ox-hugo that exports that to Markdown + the front-matter required by Hugo, in the folder structure for Hugo.
Now I just write in normal Org, and don't worry about manually setting up the post front-matter -- https://ox-hugo.scripter.co
(That site is generated by ox-hugo + Hugo btw :))
I write my blog posts in Org mode. So I wrote this package ox-hugo that exports that to Markdown + the front-matter required by Hugo, in the folder structure for Hugo.
Now I just write in normal Org, and don't worry about manually setting up the post front-matter -- https://ox-hugo.scripter.co
(That site is generated by ox-hugo + Hugo btw :))
Yes, although I'm not an emacs user.
I've been trying to pick a "meta language", eventually given up but I cannot remember why, I need to pick it up again.
I've been trying to pick a "meta language", eventually given up but I cannot remember why, I need to pick it up again.
I think that Liquid, the template language used by Jekyll and some other products, is designed to basically be that.
https://shopify.github.io/liquid/
The problem is that it's written in Ruby and therefore most implementations of it require you to have the whole Ruby dependency chain. That really increases its footprint on a cheap webhost, if you want the SSG to happen server-side (e.g. triggered by a Git hook).
https://shopify.github.io/liquid/
The problem is that it's written in Ruby and therefore most implementations of it require you to have the whole Ruby dependency chain. That really increases its footprint on a cheap webhost, if you want the SSG to happen server-side (e.g. triggered by a Git hook).
Liquid is just a template engine, I don't think this is what the OP meant.
The Website Meta Language has been around since 1996: http://thewml.org/. I used it to generate content years ago before more modern tools came out.
Why should anyone use this over Jekyll or any of the numerous other static site generators?
Jekyll doesn't work on Windows last time I checked, not without going through a long list of steps. It also needs a Ruby runtime.
It does work on Windows, but it's a pretty unpleasant process, particularly if that's your only reason for installing Ruby (i.e. you aren't doing any actual Ruby development and just want to run the site generator).
I was collaborating with a bunch of people on a website designed to use Jekyll and I got really tired of talking Windows users through the point of installing the whole Ruby environment just so they could generate content. It's a huge hurdle to have to get non-developer users over.
I was collaborating with a bunch of people on a website designed to use Jekyll and I got really tired of talking Windows users through the point of installing the whole Ruby environment just so they could generate content. It's a huge hurdle to have to get non-developer users over.
It does work on Windows, and is fairly easy. It's true that it needs an entire Ruby environment.
WSL at least makes it a lot easier to maintain the ruby environment and keep it up to date (especially for tracking GitHub Pages) as you can follow Ubuntu instructions. Jekyll is definitely my largest use for WSL.
That's true. I don't use the WSL anymore though, still works.
It is more annoying than something like Gutenberg would be though.
It is more annoying than something like Gutenberg would be though.
Yes, for now the lazy convenience of being able to use GitHub directly as my "CMS" makes it worth the hassle to work with Jekyll and Ruby in WSL for those rare times when I need to do larger changes and make sure that I preview them locally.
This is a huge advantage for Jekyll, as it makes it easy to add new content to my site from anywhere. I don't need access to my computer.
I wish GitHub would support other SSGs in the same manner that GitLab does.
I wish GitHub would support other SSGs in the same manner that GitLab does.
For one thing it is a single binary, which is much easier to handle than, say, jekyll, for people that do not use ruby
So is Hugo, and that's in Homebrew for macOS users.
Not one "binary" but one thing? https://github.com/jekyll/docker
That's essentially what I had to do[1], it's not ideal but it works. I was looking at switching to Hugo, but this static site generator looks promising.
[1]: https://blog.jvtrigueros.com/2017/07/12/jekyll-docker-enviro...
[1]: https://blog.jvtrigueros.com/2017/07/12/jekyll-docker-enviro...
Right. You still need docker for that, though
A couple small feature requests:
1) Can you add a guide to deploying on GH Pages, Netlify, S3, etc.?
2) A search feature, along with a theme/example showing how to integrate it
1) Can you add a guide to deploying on GH Pages, Netlify, S3, etc.?
2) A search feature, along with a theme/example showing how to integrate it
Both are definitely on the TODO list, I created https://github.com/Keats/gutenberg/issues/139 and https://github.com/Keats/gutenberg/issues/140 to track them.
I'll use the fact that people are watching this thread to ask for comments on how to handle i18n on the RFC (https://github.com/Keats/gutenberg/pull/111) as this is the next big feature I want to add.
As I'm familiar with PHP, I find it way simpler to just do `php somefile.php > somefile.html`, then I don't need to learn a new templating language and go around the quirks of a custom building tool. I guess it could make sense for somebody who doesn't know any other templating language.
Or for someone who considers PHP a bucket of suck and avoids it whenever possible. Or for someone who doesn't want the PHP dependency graph installed. Or who likes the conventions of this one better than coming up with their own or using some third-party PHP monstrosity with its own dependency graph. Or...
There are many reasons different tools exist.
There are many reasons different tools exist.
Is there any push to unify the way content is arranged so one could hop from one static site generator to another?
I currently use middleman but I find it quite slow I might be tempted to go somewhere else but I am putting it away because even the migration from v3 to v4 of middleman took quite a while.
I currently use middleman but I find it quite slow I might be tempted to go somewhere else but I am putting it away because even the migration from v3 to v4 of middleman took quite a while.
There's a lot of me-too software out there, and honestly I wish that developers would just be more candid about their goals.
What is this really? A state site engine with no dependencies... but is it? ...or is that just one of the things it is? If one had more plainly said "a static site engine written in Rust" then maybe it would be more compelling to at least one particular ecosystem.
I just don't understand the selling point unless you're completely candid. Hugo is; it doesn't even pretend to be something it's not. It directly sells to people who invest in Go. And Jekyll has a powerful stance as being integrated with platforms like GitHub. What's the pitch here?
What is this really? A state site engine with no dependencies... but is it? ...or is that just one of the things it is? If one had more plainly said "a static site engine written in Rust" then maybe it would be more compelling to at least one particular ecosystem.
I just don't understand the selling point unless you're completely candid. Hugo is; it doesn't even pretend to be something it's not. It directly sells to people who invest in Go. And Jekyll has a powerful stance as being integrated with platforms like GitHub. What's the pitch here?
Why would an end user care which language the tool is made with? The only times it matters is if they want to contribute or if it requires you to install their toolchain, which is not the case here.
It definitely has a larger impact with language ecosystems like Rust's and Go's.
This name is already an amazing typography library... http://matejlatin.github.io/Gutenberg/
I have to say I don't really understand the point of these projects. Faced with the problem of generating a static part for my website, I just used Django to "print" the static part. I'm not saying you need to use Django (although in my case it has clear advantages, namely that you write everything using a single tool), but.... left pad, anyone?
>Faced with the problem of generating a static part for my website, I just used Django to "print" the static part.
Because I don't want to spend too much time maintaining my site.
When I used Wordpress, it got hacked. I don't want to check every few months for security updates.
When I used Django, it would randomly "go down" when some library changed on my host. Then I'd have to figure out how to fix it. Which almost always involved upgrading to the latest Django, which was never straightforward.
But the static site generator I have? Runs on my machine and not on a server. I still have the same problems with it as with Django (upgrades breaking stuff). The important thing is that it breaks stuff on my PC and not on the server. People can still access my site while my generator is broken. I feel no pressure to fix it (and indeed, it is usually months before I do fix it).
And, finally, I think you don't really know what SSG's do for you. It's not about making one or a few pages static. It is about making it appear dynamic while being static (tag pages, categories, etc). In fact, I would invert the question. Given that a SSG can do pretty much anything a blog can do, why would someone use a server side process to write a blog? What's the point of having your blog in Django when a simple SSG will do the task for you?
Because I don't want to spend too much time maintaining my site.
When I used Wordpress, it got hacked. I don't want to check every few months for security updates.
When I used Django, it would randomly "go down" when some library changed on my host. Then I'd have to figure out how to fix it. Which almost always involved upgrading to the latest Django, which was never straightforward.
But the static site generator I have? Runs on my machine and not on a server. I still have the same problems with it as with Django (upgrades breaking stuff). The important thing is that it breaks stuff on my PC and not on the server. People can still access my site while my generator is broken. I feel no pressure to fix it (and indeed, it is usually months before I do fix it).
And, finally, I think you don't really know what SSG's do for you. It's not about making one or a few pages static. It is about making it appear dynamic while being static (tag pages, categories, etc). In fact, I would invert the question. Given that a SSG can do pretty much anything a blog can do, why would someone use a server side process to write a blog? What's the point of having your blog in Django when a simple SSG will do the task for you?
> When I used Django, it would randomly "go down" when some library changed on my host.
I haven't had that problem. Django is alright IMO, if a little "heavy" on machinery. I'm not crazy about it, but it gets the job done and I do have a soft spot for python :)
I haven't had that problem. Django is alright IMO, if a little "heavy" on machinery. I'm not crazy about it, but it gets the job done and I do have a soft spot for python :)
>I haven't had that problem. Django is alright IMO, if a little "heavy" on machinery.
It might help to keep in mind that I've had Django running on a server since around 2008. You can imagine that Django has changed a lot since then. Every year or two the site would go down as the host would change their Python libraries. So I'd need to update Django, which was always nontrivial if you're changing from a version that was a few years older.
Perhaps Django is stable enough now that you can upgrade Django versions every 3-4 years and have it go smoothly. But not in those years.
Arguably, you could say I should have had my own Python + Django + all libs installed in my user area and not have relied on my host's environment. Or used a Django friendly host that provides this to you automatically.
At that point I'd go back to my question: Given that a SSG gives you a blog right out of the box, why should I even consider Django? I don't want to be constrained by hosts, and I don't want to have my own custom Python install for each site I host.
It might help to keep in mind that I've had Django running on a server since around 2008. You can imagine that Django has changed a lot since then. Every year or two the site would go down as the host would change their Python libraries. So I'd need to update Django, which was always nontrivial if you're changing from a version that was a few years older.
Perhaps Django is stable enough now that you can upgrade Django versions every 3-4 years and have it go smoothly. But not in those years.
Arguably, you could say I should have had my own Python + Django + all libs installed in my user area and not have relied on my host's environment. Or used a Django friendly host that provides this to you automatically.
At that point I'd go back to my question: Given that a SSG gives you a blog right out of the box, why should I even consider Django? I don't want to be constrained by hosts, and I don't want to have my own custom Python install for each site I host.
>Faced with the problem of generating a static part for my website, I just used Django to "print" the static part.
Sounds way more involved compared to what you'd do with just a static site generator -- especially one that's a single binary.
Sounds way more involved compared to what you'd do with just a static site generator -- especially one that's a single binary.
The website is a commercial one which accepts payments and vends licenses (https://zenaud.io). So some kind of dynamic website is necessary. Printing to static html is a file (51 LOC) with a single function definition.
I'm pretty sure just reading the docs on the Hugo or whatever takes longer than it took me to write the it :)
I'm pretty sure just reading the docs on the Hugo or whatever takes longer than it took me to write the it :)
> but.... left pad, anyone?
Actually, unless you're committing the wheels in your repo left-pad is more likely to happen with your solution than with a binary since someone could login and remove all versions of Django from Pypi (unless it's just yanking them instead of completely deleting them, not sure).
On the other hand, you can just commit a binary in the repo and it will keep working assuming you don't change platform.
Actually, unless you're committing the wheels in your repo left-pad is more likely to happen with your solution than with a binary since someone could login and remove all versions of Django from Pypi (unless it's just yanking them instead of completely deleting them, not sure).
On the other hand, you can just commit a binary in the repo and it will keep working assuming you don't change platform.
Good starter project for learning a new language. You get to touch various interesting areas from IO to templating to a simple modicum of "dependency tracking" (for incremental rebuilds), many neat areas to learn/try optimizations, and now matter how hard it is at first or how deep down the feature-creep rabbit hole you go, at some point it's just gonna be done. Not a bad package
> left pad, anyone?
Crates.io is immutable (to the legal extent possible), and so that can't happen with this.
Crates.io is immutable (to the legal extent possible), and so that can't happen with this.
Sorry, that comment was a bit flippant -- I have huge respect for the Rust language and community and agree that the left-pad-debacle is pretty unlikely to happen there.
What I meant is that I consider static blog generation so simple that you should be able to do it yourself. I hope that doesn't come across as arrogant, above I allude to the fact that for my case, it took 51 LOC of python to get it done (admittedly harnessing the machinery of the existing, dynamic website).
What I meant is that I consider static blog generation so simple that you should be able to do it yourself. I hope that doesn't come across as arrogant, above I allude to the fact that for my case, it took 51 LOC of python to get it done (admittedly harnessing the machinery of the existing, dynamic website).
It's all good. Notably, it can't happen with npm anymore either, so maybe just not the best analogy to make ;)
Please tell me there's some love for pandoc... I'm very confused though... There's no mention of the markdown parser being used...
Pandoc is essential for cross-platform content (md --> doc, epub, pdf, html) and for MATH!!
Sadly, only Jekyll and Hackyll have support for it... (many other smaller projects also might)
Hugo with npm scripts does exactly thins...
Sadly, only Jekyll and Hackyll have support for it... (many other smaller projects also might)
Hugo with npm scripts does exactly thins...
I now prefer knocking stuff up in my pet chosen MVC web framework. I can be more more productive when I need to tweak thing that way.
With output caching performance should be on par with static. Or can use one of those programs that downloads a website to convert into static files if required.
With output caching performance should be on par with static. Or can use one of those programs that downloads a website to convert into static files if required.
Do any of these static generators keep configs and themes with wherever you happen to upload your static content "example: github"?
Just curious if moving from one machine to another if it's easy to download something like Gutenberg , clone your git and start working?
Just curious if moving from one machine to another if it's easy to download something like Gutenberg , clone your git and start working?
Once you get confident with your static site generator, you don't even have to download it or run it locally (not kidding).
I have my Hugo-based blog on Gitlab (content, themes, config, etc).
I just need to commit changes to my plain text content (Org/Markdown) -> Netlify sees the commit -> Runs hugo to generate the site -> Site gets published.
I have my Hugo-based blog on Gitlab (content, themes, config, etc).
I just need to commit changes to my plain text content (Org/Markdown) -> Netlify sees the commit -> Runs hugo to generate the site -> Site gets published.
Yes, they all work pretty similarly and the Git repo is fairly self contained. You (mostly) just point the generator software at the repo which includes your content, config and theme and it compiles it into HTML files.
Very nice, that is one of the most annoying things about Jekyll. I know i'm in the minority of users here who is on Windows, but setting up a Ruby in environment is a pain. Nice work, the site is also well designed.
Does anyone know why the page flashes when clicking "Docs" at the top, but not when moving to the "installation" link on the left hand side which is the same url?
Because the "Docs" link at the top goes to a blank page that then redirects you to the installation page.
The Docs link lands on the documentation section which redirects to the getting started section which redirects to the installation page.
I could link directly to the installation page from the header, didn't think about it that much.
I could link directly to the installation page from the header, didn't think about it that much.
I don't see a point right now, but just in case: how much of a hassle would it be to migrate my Hugo-based projects to Gutenberg, if it proves to be more useful somehow?
If you're using a TOML frontmatter it should be pretty painless for the content otherwise a bit annoying. Migrating the theme/template should be fast though.
No dependencies? Then what's all this?
You and I must have different ideas of what constitutes a dependency ;)
[dependencies]
clap = "2"
chrono = "0.4"
toml = "0.4"
term-painter = "0.2"
# Used in init to ensure the url given as base_url is a valid one
url = "1.5"
# Below is for the serve cmd
staticfile = "0.4"
iron = "0.5"
mount = "0.3"
notify = "4"
ws = "0.7"
You and I must have different ideas of what constitutes a dependency ;)
They just mean their releases come as a single binary file, so really it's "no installation dependencies".
This is remarkable in the static site generator world because many (jekyll, hexo, mkdocs) are modules installed via the language's package manager (jekyll is installed via "gem", etc). So you have to get the package manager working, then get any external dependencies working, THEN you can get started.
This is remarkable in the static site generator world because many (jekyll, hexo, mkdocs) are modules installed via the language's package manager (jekyll is installed via "gem", etc). So you have to get the package manager working, then get any external dependencies working, THEN you can get started.
The output binary has no dependency. The dependencies listed and Rust are only necessary if you want to build from source.
I figured that's what you meant :)
I apologize if I came off as dismissive or disdainful; I was in a sort-of playful mood when I wrote that, but moods don't usually survive internet transmission!
It's a neat project. I myself don't have much use for a site generator of any sort, but I am interested in Rust (though I haven't had much opportunity to use it in the last year or so). I wonder: how are you liking Rust as a language? as an ecosystem? For a project like this, what advantages has Rust afforded? what disadvantages?
I apologize if I came off as dismissive or disdainful; I was in a sort-of playful mood when I wrote that, but moods don't usually survive internet transmission!
It's a neat project. I myself don't have much use for a site generator of any sort, but I am interested in Rust (though I haven't had much opportunity to use it in the last year or so). I wonder: how are you liking Rust as a language? as an ecosystem? For a project like this, what advantages has Rust afforded? what disadvantages?
Yeah, based on the title I was expecting a single exe file (with themes and supporting directories) which would be more of a turn key solution.
I think it might be statically linked binary, so downloading and running the binary has no installation dependencies.
Are there examples of pages generated with Gutenberg?
The site is built with Gutenberg so you can open the inspector to view some.
However, it would be nice to have some at the source code.
It's on the repo https://github.com/Keats/gutenberg/tree/master/docs/template...
http://themes.gohugo.io