Show HN: Gutenberg – A static site engine as a single executable
getgutenberg.io
getgutenberg.io
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.
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 =)
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..
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.
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 like that phrase a lot, captures a lot about comments on OSS projects here in HN and elsewhere.
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.
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.
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.
It's the ultimate Magpie progression.
Ruby -> Go -> Rust
Example:
{{ if and (or (isset .Params "title") (isset .Params "caption")) (isset .Params "attr")}}
...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...
I'd love to have a tool to generate a catalogue, a simple journal, etc.
However, if your data is coming from an API/database something like Gatsby (https://www.gatsbyjs.org) would be better.
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.
github.com/tmzt/isymtope
Working on a major push/update.
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.
For sites which are closer to books, gitbook is an option as well. https://www.gitbook.com/
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/)
Would you please describe the data model you have in mind a bit more?
Here are themes tagged Portfolio: https://themes.gohugo.io/tags/portfolio/
I actually find many themes that are non-blog based in there.
Again, YMMW.
[1]: https://themes.gohugo.io/theme/docdock/content-organisation/
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
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.
Corrected that for you Bemmu :)
Hopefully someone will package it for Brew/Chocolatey (is that what is used on Windows?) but it's a good stopgap solution.
Still, terrible and unoriginal name choice:
https://github.com/search?utf8=%E2%9C%93&q=gutenberg+static+...
Could I start using Einstein (dead for 62 years) or Galileo (dead for 375 years) as a trademark?
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...
[1] http://www.adweek.com/digital/how-salesforce-snagged-einstei...
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.
Search for small hack and you can see one
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.
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...
We shouldn't have to rewrite our blogs every time a new cool programing language comes around!
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).
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've been trying to pick a "meta language", eventually given up but I cannot remember why, I need to pick it up again.
[1]: https://blog.jvtrigueros.com/2017/07/12/jekyll-docker-enviro...
It is more annoying than something like Gutenberg would be though.
I wish GitHub would support other SSGs in the same manner that GitLab does.
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.
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
There are many reasons different tools exist.
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.
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?
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.
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?
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 :)
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.
Crates.io is immutable (to the legal extent possible), and so that can't happen with this.
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).
Sounds way more involved compared to what you'd do with just a static site generator -- especially one that's a single binary.
I'm pretty sure just reading the docs on the Hugo or whatever takes longer than it took me to write the it :)
Sadly, only Jekyll and Hackyll have support for it... (many other smaller projects also might)
Hugo with npm scripts does exactly thins...
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.
Just curious if moving from one machine to another if it's easy to download something like Gutenberg , clone your git and start working?
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 could link directly to the installation page from the header, didn't think about it that much.
[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 ;)
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.
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?