Hacker News Reader

Comment by krat0sprakhar | Hacker News Reader

> Lanyon was derived from my static site generator, Hastie. I grew tired of the multiple steps for creating, generating and publishing. Plus, using a static site generator has a duplicate source tree and generated tree, with some assets in each. Lanyon simplifies this with one set of directories with content and assets.

Isn't the point of a static site generator to generate a static site and deploy the output to a simple file server? I'm not quite sure if I understand the use-case of this project. Also, if you're looking for generating binaries across multiple OSes try http://gobuild.io/

PS: Thanks for this! The source code will surely be invaluable to a Go noob like me!

View on HN

Also, most static site generators do include such a server to avoid having the second directory and rebuilding everything until you really want to release. Some generators also come with tasks to do "build&deploy" in one go.

Later in the README, the author suggests to put a reverse cache in front of the server, which seems to me far more elaborate than avoiding to put a bunch of files on a server.

Check out hugo, a static site generator written in Go: http://hugo.spf13.com

It has a built-in server with watch mode and regenerates the entire site upon file changes. It’s blazingly fast (as long as you don’t use the syntax-highlighting plugin which calles out to pygments and is rather slow).

Seconded hugo recommendation.

Aside: I have been using highlight.js[1] instead of pygments lately.

[1]: http://highlightjs.org

Nah, I am very happy with middleman, have no speed problems and as far as I see, hugo doesn't support sass (without shelling out, again).

Yep, I wanted to avoid building in a web server into the static site generator, since it complicates that product.

The cache server definitely adds complexity and more so than a static site. However the complexity is setup and done once on initial server setup. On-going, the multi-process of a site generator adds up. Granted its one small step which as you say most already have scripted tasks.

Answering the first comment, the use case was something to play with for my personal site which I wanted to share if others found useful.

It especially adds something that I have to run. Nowadays, I can just push a static site to S3 and am done.

Considering that most programming languages ship with a good webserver for serving static content already, I don't see how it makes the product that much more complex. Coming from another angle: now I have a webserver that renders markdown ;).

I had a look at your website and you write about interesting topics. I’d like to keep track of that.

It appears, before the rebuild, you had a feed @ http://mkaz.com/rss.xml — which is gone. I guess the Lanyon web server doesn’t generate atom or RSS feeds out-of-the-box?

That’d be a pity, while a Web based on Markdown+Git+WebSocket (or something alike) still is a long shot…

My personal use-case is to write documentation / logs while I develop / configure a system and have it in a very flexible and interoperable format I can also use to present to customers. A md-solution makes a good fit, it would even be better without relying on any configuration and instead work out of defaults.

Reply on news.ycombinator.com