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.
> 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 =)
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..
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.
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?
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.
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.
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.
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.
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..
(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.)
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
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.
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!
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
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).
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.
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.
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.
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.
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...
2011 wants its memes back. PHP has changed, if you still have the opinion PHP is a bucket of suck give it another try the tooling around php has changed so much not to mention the language amnd speed improvements.
Geez, people get touchy about their tools. I wasn't attacking PHP. I pointing out in passing that some folks feel that way.
But no, I'm not going to look at new 'n improved PHP, because I don't care about it and life's too short. I only ever used it in a past life when doing contract work fixing other people's messes.
But if you'd prefer to stick your head in the sand and keep espousing your negative experience with PHP from many years ago despite numerous people advocating the many improvements that happened over the years then that is your prerogative.
Wow, what a bundle of assumptions and arrogance, all wrapped around abysmal reading comprehension.
I might worry about responding again after you write something that replies to what I actually wrote, not whatever you apparently imagined. But honestly, likely not, given your attitude.
I read everything you said and I didn't assume anything. It is fine to have no desire to learn modern PHP.
Just don't then make opinionated statements in an abusive manner and expect to be able to contribute anything to a discussion on PHP as a development platform. I would have tried to address the points you brought up but the only thing you said was that PHP is a "bucket of suck" and something about dependencies.
> but the only thing you said was that PHP is a "bucket of suck"
I feel like this is turning into a bad Monty Python sketch.
This is precisely what I have repeatedly pointed out: I did not say that I think PHP is a bucket of suck. I said some people hold the view while I was making a particular, different point. I was not making any sort of argument one way or the other about the quality of PHP or its fitness for any purpose, my technical-aesthetic preferences, or anything even vaguely related to your strangely aggressive misunderstandings.
You can read this, in context, by scrolling up a little. If you are incapable of reading and comprehending the plain meaning of my words upthread, I don't know what else to say.
After reading the little thread you were involved with, the lasting impression I come away with is that you were the only who needs an attitude adjustment, and that you see almost no value in any comments that others make that don't mirror your quite narrow views.
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.
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?
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.
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?
> 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.
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.
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 :)
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
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).
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)
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.
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.
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.
Shameless self promotion but my static site tool Static-Fire is based off Git. Everything from the config to the python source to the articles you write is all in the same repo.
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?
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.
[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"
Not to mention the Rust toolchain!
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.
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?
http://themes.gohugo.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.
It's the ultimate Magpie progression.
Ruby -> Go -> Rust
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.
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.
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.
Example:
{{ if and (or (isset .Params "title") (isset .Params "caption")) (isset .Params "attr")}}
[0] https://github.com/gohugoio/hugo/issues/140
...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.
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/)
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.
For sites which are closer to books, gitbook is an option as well. https://www.gitbook.com/
However, if your data is coming from an API/database something like Gatsby (https://www.gatsbyjs.org) would be better.
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/
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.
Would you please describe the data model you have in mind a bit more?
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.
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...
https://en.wikipedia.org/wiki/Baby_Einstein
https://trademarks.justia.com/757/49/baby-75749035.html
[1] http://www.adweek.com/digital/how-salesforce-snagged-einstei...
Still, terrible and unoriginal name choice:
https://github.com/search?q=gutenberg
https://github.com/search?utf8=%E2%9C%93&q=gutenberg+static+...
https://www.gutenberg.org/
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!
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.
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 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 is more annoying than something like Gutenberg would be though.
I wish GitHub would support other SSGs in the same manner that GitLab does.
[1]: https://blog.jvtrigueros.com/2017/07/12/jekyll-docker-enviro...
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.
But no, I'm not going to look at new 'n improved PHP, because I don't care about it and life's too short. I only ever used it in a past life when doing contract work fixing other people's messes.
But if you'd prefer to stick your head in the sand and keep espousing your negative experience with PHP from many years ago despite numerous people advocating the many improvements that happened over the years then that is your prerogative.
I might worry about responding again after you write something that replies to what I actually wrote, not whatever you apparently imagined. But honestly, likely not, given your attitude.
Just don't then make opinionated statements in an abusive manner and expect to be able to contribute anything to a discussion on PHP as a development platform. I would have tried to address the points you brought up but the only thing you said was that PHP is a "bucket of suck" and something about dependencies.
I feel like this is turning into a bad Monty Python sketch.
This is precisely what I have repeatedly pointed out: I did not say that I think PHP is a bucket of suck. I said some people hold the view while I was making a particular, different point. I was not making any sort of argument one way or the other about the quality of PHP or its fitness for any purpose, my technical-aesthetic preferences, or anything even vaguely related to your strangely aggressive misunderstandings.
You can read this, in context, by scrolling up a little. If you are incapable of reading and comprehending the plain meaning of my words upthread, I don't know what else to say.
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?
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.
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 :)
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.
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).
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.
https://github.com/cusiman7/Static-Fire
I could link directly to the installation page from the header, didn't think about it that much.
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?