I got scared when it said node.js, then I saw it was only using node.js for the customization part, not the hosting part and I got relieved.
I really think they should emphasize that you can use your own web-server, using node.js to host a static site just doesn't make sense.
The fact that it's static should mean you can host it on any platform that hosts static files. The technology only kicks in when you are writing blogposts and (re)generating your static files before you sync/upload them to your host.
Indeed. As explained on the page I was using Debian's stable release. The new release, Wheezy, contains a package for hakyll. I will retest in the future, once I've upgraded my host(s).
Hard to draw ASCII here, but imagine a symlink from "/js/jquery.js" pointing to "/js/jquery-1.2.3.js".
A good application will write output that has a literal copy of the numbered version, and a symlink point to it.
Bad applications either ignore symlinks entirely, or change them to duplicate copies of files. (Which can be bad if you're considering a large file such as foo-latest-release.tar.gz.)
Have you come across any static site generators that would be user-friendly enough to recommend to users currently stuck with iWeb, DreamWeaver, RapidWeaver and the like? I was recently trying to help somebody migrate away from using iWeb (abandoned by Apple), but found that trying to teach something like Hyde* was not a feasible alternative.
In my opinion a user-friendly static site generator would require some kind of minimal GUI, dialogs to handle inserting images, and a smart set of predefined options to generate menus, listings, etc. Maybe even a one-click option to update an S3-hosted site.
If this doesn't exist, perhaps writing a GUI wrapper for an existing generator would be a worthwhile project.
* The Python program, not the CHICKEN Scheme static site generator of the same name.
"Write rich web applications using the latest technologies without having to host your own node.js servers [...] No matter what plugins you use, the output will always be a static website you can host anywhere."
I don't think that's a very common definition of "rich web application".
After looking it up I see it is commonly used to describe something that adds extra features to a browser, like flash or silverlight.
Previously I took it to mean "rich in interactivity". That's what I meant when I originally wrote that, a static site does not mean you can't have interactive content. IMHO the best way to write webapps is to have a static client that consumes an API provided by a standalone backend.
I once have the table of posts on a Wordpress site get corrupted. The whole contents of the site has vanished. I managed to restore the table, but that had me thinking about using a such CMS.
I have done some quite significant static site generation without ever having to write a static site generator from scratch - although I did have to make changes to the core of Hakyll to make it use ByteString so I could efficiently process the amount of data I needed (I contributed the changes back and they are now an official part of Hakyll).
Contributing to an existing architecture is definitely the way to go if what is already there is flexible enough to do what you need.
Really like this little framework, was just checking it out a week ago. To the author or anyone else interested, I'm making a little tool that does something very similar (http://roots.cx) and am aggressively adding functionality in order to make almost anything feasible to build as a static site.
Anyone else find it funny that a language originally designed to add dynamic content to the client side is being used to generate static content on the server side?
Makes sense to me though ... It's a natural fit for a front end dev who knows HTML/CSS/JS and also a good way to learn proper templating.
It seems like just about everyone's written a static site generator. Mine is Kerouac (https://github.com/jaredhanson/kerouac), another Node.js-based generator.
I specifically wanted to apply the middleware concept to generating pages, which turned out to be a decent fit. It ends up being a very similar API to Express, so its instantly familiar to Node.js developers. Check it out.
53 comments
[ 6.5 ms ] story [ 119 ms ] threadhttps://github.com/skx/static-site-generators
Early testing looks good, but like so many existing tools it mishandles symbolic links.
A user submitted a bug-report to draw attention to Middleman & Yeoman, but then closed it before I got round to looking at them.
https://github.com/skx/static-site-generators/issues/2
I'll try to find some time soon to add them, and work on the repository some more.
No explicit bias intended :)
http://bitworking.org/news/2013/05/piccolo_go
If you contact the hakyll maintainer, jasper, for help, I'm sure he'd be more than happy to help you get it installed and usae.
If you contact the hakyll maintainer, jasper, for help, I'm sure he'd be more than happy to help you get it installed and usae.
A good application will write output that has a literal copy of the numbered version, and a symlink point to it.
Bad applications either ignore symlinks entirely, or change them to duplicate copies of files. (Which can be bad if you're considering a large file such as foo-latest-release.tar.gz.)
In my opinion a user-friendly static site generator would require some kind of minimal GUI, dialogs to handle inserting images, and a smart set of predefined options to generate menus, listings, etc. Maybe even a one-click option to update an S3-hosted site.
If this doesn't exist, perhaps writing a GUI wrapper for an existing generator would be a worthwhile project.
* The Python program, not the CHICKEN Scheme static site generator of the same name.
Perhaps even a CMS-like thing that could be done online entirely?
http://zoggy.github.io/stog/getting_started.html http://zoggy.github.io/stog/slides/2013_04_23_inria.html#%28...
I don't think that's a very common definition of "rich web application".
Previously I took it to mean "rich in interactivity". That's what I meant when I originally wrote that, a static site does not mean you can't have interactive content. IMHO the best way to write webapps is to have a static client that consumes an API provided by a standalone backend.
Though hacker news isn't going to see either anytime soon because both are terrible. Still... it's a good learning experience.
And now that you mention it, I have been looking for an excuse to learn Clojure...
[1] http://nanoc.stoneship.org/
A proof of some kind of competency with the web stack.
Contributing to an existing architecture is definitely the way to go if what is already there is flexible enough to do what you need.
Would love to talk about this stuff any time!
Makes sense to me though ... It's a natural fit for a front end dev who knows HTML/CSS/JS and also a good way to learn proper templating.
I specifically wanted to apply the middleware concept to generating pages, which turned out to be a decent fit. It ends up being a very similar API to Express, so its instantly familiar to Node.js developers. Check it out.