Show HN: A dead simple static site generator – just two template tags
tags.brace.ioI'm not being facetious, but this "yet another static site generator" joins the list with 230+ other generators.
(see http://staticsitegenerators.net/)
Why do we need another one?
Static site generators are the new Fibonacci generator. When you learn a language it's a fun little exercise, and possibly even useful.
Also, everyone has slightly different requirements, so everyone likes to build their own.
I will most likely soon build my own static site generator, because none of the ones out there do exactly what I want. I will most likely borrow from at least a few of the examples out there and then post it on my github so there is yet another one.
I think we're seeing a proliferation simply because it is so easy to share code these days. Imagine how many Fibonacci generators would have been out there if it were as easy to share code when those were popular (I want to say 10 years ago but maybe it was longer).
Had the same problem ourselves while building Segment.io that every static site generator was a bit too opinionated in weird ways, so we made Metalsmith[0]. Check it out, and you might not need to make your own anymore :)
Ian how does it compare to gulp? Build tools with name-plugin-name are another proliferating area :).
> I will most likely soon build my own static site generator, because none of the ones out there do exactly what I want.
Why bother with the templating? Use Jinja2?
The templating is the easy part. It's all the parts that go around it that are the interesting/fun part.
The hard part is styling... I could even just upload a .txt file and be done with my blog.
def fib(n): x = ((1 + sqrt(5)) / 2) ** n x -= ((1 - sqrt(5)) / 2) ** n return x / sqrt(5)Try n=1000 or n=10000.
from math import sqrt from decimal import Decimal def fib(n): x = Decimal((1 + sqrt(5)) / 2) ** n x -= Decimal((1 - sqrt(5)) / 2) ** n return x / Decimal(sqrt(5)) print fib(1000) print fib(10000) print fib(1290309123) $ time python ~/fib.py 4.346655768693891359691727380E+208 3.364476487644307695949089018E+2089 2.879417086171668653426018537E+269658658 real 0m0.138s user 0m0.086s sys 0m0.026s
I've been looking at some of the options on that website, and this one seems to be less complex than many of the tools there. This isn't meant to be a blogging tool, but rather a simple way of emulating server-side includes or basic PHP includes in static HTML. I'm sure a few of those exist in that list, but when has "somebody built that already" become a gate for writing code?
Why do we need another one?
Because this one is much simpler to use than Jekyll and doesn't require you to install Ruby.
You could use server side includes instead, which have been a feature of web servers for about 20 years now...
Not if you host on S3, for example.
A legitimate problem we're solving by… inventing a new templating language.
Did we need a new one to do this? Absolutely none of the hundreds of existing languages could have possibly worked, so let's reinvent SSI with different syntax?
Or on brace.io (aka Dropbox)
Then just web spider SSI running on a local server.
Or someone should write an SSI static site generator.
A fine line, but static pages will be slightly faster than SSI.
Edit: Although what would be really nice would be the same kind of pre-processor that works with apache ssi directives
mod_disk_cache and mod_mem_cache make that pretty irrelevant.
http://httpd.apache.org/docs/2.2/mod/mod_disk_cache.html
re:edit hxincl uses a similar style as ssi but with a couple of enhancements:
http://manpages.ubuntu.com/manpages/trusty/en/man1/hxincl.1....
if you want exactly SSI syntax, ain't nuthin' stopping you from pointing curl at localhost.
They'll be infinitesimal faster for the server which will sit idle most of the time anyway... and much slower for you when you make a minor header/footer mod locally, and then you need to re-upload all pages that have a header (i.e. all pages).
I'm sorry, but this project feels more like "art" than a practical tool.
Plus, with a few basic lines of PHP (available on every shared host) you can pre-generate your site statically as well (and on the server, to save you the re-uploading).
Presumably the 're-upload all pages' bit can be automated. As far the reset, the trade-off depends on how often you're updating content versus the amount of traffic coming to your site; in many cases, a tiny saving on frequently-occurring page delivery is well worth a big delay on one-off page generation.
So basically, we've gone down a path of solving problems we've created ourselves.
rsync will easily handle a few lines changed in a large number of files.
Or you could just, y'know, run the static site generator on the server. What Linux doesn't have Python installed?
or you could just, 'y'know, run SSI. what web server doesn't have SSI? What problem are we actually solving here?
Serving pure HTML files off S3 is pretty popular. No SSI there.
https://news.ycombinator.com/item?id=7432097 also, which is it. are we on s3 or on a linux server with python?
>and much slower for you when you make a minor header/footer mod locally, and then you need to re-upload all pages that have a header
You should automate that with Grunt or Gulp. Static .html pages is best practise these days instead of dynamic templating.
It's best practice to not use the term "best practice" these days ;) (sorry, couldn't resist)
Not Invented Here syndrome, at all? Sure, I understand wanting to use Python for templates rather than relying on an external application. But why ignore the many, many existing template libraries? Some of those libraries have solved problems which you don't realise you have yet.
Case in point, are you planning to support this 'dead simple' template language for users of your hosting site? If so, what happens if I try to include something outside the site root, in a Dropbox area which I control? https://github.com/braceio/tags/blob/master/tags/tags.py#L13
Fair point. Python was chosen because it's an accessible language for new programmers. As for template languages, most are very complex. We wanted something minimal.
As for that case, it won't work and we'll try to help you reorganize your content so it does. :)
I've been using PHP to generate static HTML pages. It's usually as simple as `php somepage.php > somepage.html` and you have all the advantages of a full featured language.
Don't use easy_install.
We totally agree, and use pip and virtual envs for everything.
However we chose python, and easy_install because it's pre-installed all macbooks going back to snow leopard. (specifically python 2.6.1 which comes with distutils needed for our setup.py file) This means for many web designers, brace-tags doesn't require that you update your python install, or really know python at all. It's the simplest command line install experience we could come up with.
Then suggest pip first. If they need pip, they can easy_install it.
Intention is good, but anyone who wish to do serious development wouldn't mind that extra step.
Make my point clear: think about sudo pip install X vs advocating everyone to use virtualenv. The cost of cleaning up any mess from sudo outweigh the cost of getting pip and virtualenv.
Look. I agree that getting new package install is painful. Even on Linux, I often have to add PPA to get the latest version.
As a typical dev, I have no idea how to uninstall things that were installed via easy_install, especially when it was thrown into the places sudo lets it go. So every time I see `sudo easy_install`, I just close the page I'm on.
I wonder when pip will be considered old and outdated?
It won't, not for a long time. http://legacy.python.org/dev/peps/pep-0453/ and http://blog.python.org/2014/03/python-340-released.html
Reminded me of my go-to include method from back in the day: http://www.moock.org/webdesign/javascript/client-side-includ...
Stupid question: any major drawbacks to using this method?
Lots.
The "include" file is just a js file that document.writes your html, so its not easy to make edits because you would need to do it in a big stream of escaped code.
They won't work if user has js turned off.
They are awful for seo because the includes will not be there when the page is crawled
They are not semantic for writing things like <html><head> and will throw your browser into quirks mode because your page would effectively start with a script tag.
But I used the hell out of them back when dynamic hosting was hard to come by (geocities, tripod etc)
Thanks!
I'm in the fun position of essentially being a graphic designer made to be a web designer in a stingy startup environment where they don't want to pay someone to actually code things. Another designer and I put together a very sad website, and I wouldn't mind having a system for having includes for my header and footer, but even simple concepts like preprocessing scare me off. Heck, I run scared at the mention of the command line. I guess the only real answer is to bite the bullet and learn this stuff (I do frequent HN after all, you'd think I'd be more comfortable with some of these concepts).
Yeah, "biting the bullet" is probably a good idea. As someone with a graphic arts degree who's been a "web designer" for years, I can tell you the potential for making money at anything entirely with front-end and design skills seems vanishingly small. The days when having an ftp account and Notepad were all you needed are long, long gone.
I know enough git to be able to manage the basics (pulling and pushing) and a bit of command line stuff. If you ever get into working with web frameworks in just about any language, I think those are going to be kind of essential. It's probably not going to be as scary as you think though.
No problem, keep at it and keep reading hn! This might be a nice good look for you to try, I have heard good things: http://hammerformac.com/
What's the reason for this? Why don't you just build the website using standard HTML? Genuine question.
This allows you to include other html files from within your templates. Instead of writing out the same <nav> and <header> html in every single file, you can just `include 'nav.html'`
I was looking for something exactly like this just recently. Usually I use just php include when I want to just links some files together, but felt like I should stop using php as a preprocessor if possible.
However, everything else is so complicated if all you want is simple file inclusion.
What's the reason behind not using PHP?
Security: if you're mega-paranoid or unwilling to keep up with patches, going static reduces your attack vector. Performance: your web server will be able to handle more traffic without the overhead of php. Of course, if you need any kind of dynamic processing on the server, you'll need to move beyond static pages.
Ah ok, yeah now I totally understand :) Thought it was the whole 'Does any one even use PHP' getting thrown around again.
You need PHP installed and configured on your server/local. With this you can just use plain HTML.
In theory you could also use PHP as a pre-processor; install it locally, copy the sources to the webserver root, then use wget --mirror to extract a post-processed version of the site.
You'd still need PHP installed on your home machine, but then again, it's not like you don't have to install some pre-processor anyway.
> use wget --mirror to extract a post-processed version of the site.
or just use php file.php > file.html
Sure, but you'd need to process each file, or write a script to do it, when wget --mirror fetches the whole site at once.
and by plain HTML, you mean plain Python installed and configured on your server/local
The server doesnt need to have Python installed. Just your local machine. That is a simple one liner if it isnt already installed.
partials :-)
try to have 1 header in like 10 pages. That is a lot of copy pasting :-)
I remember discovering SSI back when I was writing pages using pico/notepad .. was only a short hop then on to rejecting js client-side includes and using PHP for templating.
Templating.
I like this very much. I used to do very similar with PHP, but I'm now a Python dev. Sometimes, just sometimes, writing plain old simple html is easier, and having a basic include would save a ton of heartache for maintenance.
I'm willing to bet that it took more time to write and setup the homepage than to write the generator itself.
I haven't read everything but why isn't the source like 10 lines if that's all it does?
Reading the source, it also has a built-in web server (based on Python's SimpleHTTPServer) and a file watcher to automatically rebuild the site.
So the watcher only writes files that have been edited unless there is a change to one of the repeated tag files?
I think it rebuilds the whole site - I don't see any logic for identifying the changed file and rebuilding only that.
Easy to use does not have anything to do with the underlying codebase.
Is there any way you could make the watch feature not dependant on watchdog? The watchdog installation fails on pip on Mac. I then had to install Homebrew just to be able to install libyaml, which then meant I could install watchdog.
Which is why this should have been written in Node. Seriously, Python/Ruby environments+package managers are the abomination of programmer's time.
I disagree. This is the only time I've ever had any problems with Python package managers.
I actually found the “Highlight this” example at the top a bit confusing. Could you write “Display this” instead? Or give a better example to demonstrate conditionals?
I like it! Great concept, thanks for simplifying something that should be dead easy and simple. A ruby port would be nice.
Awesome! Just what I needed this morning.
Very nice and easy to use.