Lanyon, a Markdown web server in Go | Hacker News Reader

Lanyon, a Markdown web server in Go

github.com

54 pointsmarcuskaz19 comments

Instead of using a custom webserver, I just use an apache markdown handler[0] that allows me to view any markdown files over the web. So I can just clone any doc repo and browse it instantly without firing up anything or having to compile it.

[0]: https://github.com/sminnee/markdown-handler

> 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!

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.

I did something very similar last fall: a blog structure that you deploy as Markdown, the server compiles and serves HTML.

https://github.com/aybabtme/brog

I wanted to play with fsnotify, so not only will it compile your Markdown, it will also watch the blog path and reload/recompile the Markdown + Templates when they change.

Thus you can start the server once, make it watch a folder and then simply rsync/push your changes in that folder to see the change live. The deployment of a blog looks like this:

https://github.com/aybabtme/antoine.im

It's surprisingly fast; I've been working on a load generation tool at work and I use my blog [1] to try it out. It can handle quite a bit of traffic on a little 5$ droplet[2]!

[1]: http://www.antoine.im/

[2]: I do the load testing on the IP of the machine, since [1] is behind Cloudflare.

Nice! I'll have to check it out and see the fsnotify stuff.

That's one thing, it currently does not recompile the templates if there is a change.

You should consider renaming. There's a popular theme for Jekyll with the same name[0].

[0]: https://github.com/poole/lanyon

Also, they're both somehow related to Markdown.

It's an endemic problem in Go community. The language itself was named Go despite the fact that another language named Go already existed: http://en.wikipedia.org/wiki/Go!_%28programming_language%29

It's named "Go!", though. Must be an imperative language. What we really need is a third programming language named "Go?", the query language.

There is also Go, Thoughtworks Continous Integration Platform.

http://www.thoughtworks.com/products/go-continuous-delivery

(although it came later)

And also an ancient board game. Interesting that the author of Go! asked Go to change their name in one of the first bug reports, but they refused. Some people propose calling Go "Issue 9" to avoid confusion. It's probably more Google-able too.

https://code.google.com/p/go/issues/detail?id=9

A lot of derivatives of Jekyll have name conflicts since many are grabbing from the same source, the book Dr. Jekyll and Mr Hyde.

There is a character called Dr. Hastie Lanyon which is were I grabbed the name for both my projects.

Reply on news.ycombinator.com