I've been going through and messing around with Punch, and I have to say that I enjoy using it. Your initial "first run" walk-through is wonderful.
I'm curious though, are you creating Punch to be more of a generator that resides on a local development computer and just pushing static output to the server, or is Punch's design goal to sit on the front end as a server/publishing system (with publishing static files an option)?
Thanks for trying out Punch.
Actually, goal of Punch is to act as both a static generator and a server. If you look into most web projects, they mainly consist of static pages (that doesn't require to be updated on each request) and also few pieces of dynamic content (most of the time that can be embedded into the static pages). Punch as a framework want to ease the development of this kind of projects. So you serve most of the request as directly using static pages and hit the server only when you need to fetch some dynamic content.
I'm working on more concrete examples to make this concept clear. Do let me know if you got any further questions or concerns.
Reading what you've written, It sounds like you might have support for dynamically regenerating the next static page?
The way I use punch right now is to call punch p when I need my company website to change - which is quite infrequent, maybe once per week!
@jtrain That's how Punch works when you run it locally with punch s, which allows you to preview the changes in the browser. Running the command punch p will generate all pages of the site and publish it to the specified location.
Technically it's possible to run Punch also on a remote server by using punch s. Then it would regenerate the page for each request. It would be useful for some sites which needs certain pages to be rendered per request. I'm working on an update to make this option more easier and stable.
There are currently important drawbacks when using punch s:
It's really really useful while developing, but I'm not sure using it for production is a realistic option. And I'm not even sure this worth the effort, as we use static generators for performance, and some nginx will always dramatically outperform Node's embedded http server ;)
@naholyr Can you open a separate ticket with an example for the issue of contents from non-default places not refreshing correctly?
In the current state, there's not much of an incentive in choosing to run Punch as server on production. But there will be some future updates, that will make it more sensible.
@laktek I have two cases: blog content handler which returns a 404 on first access (I suppose it's a conception issue), and my own handler which formats date and I strangely don't get the same results when I update a template or content (I didn't exactly check out when it occurs). I'll dig a bit further to provide details and open a ticket, right ;)
Here's an issue of running Punch on the server, tying in something like forever (https://github.com/nodejitsu/forever) running a purely node stack. I guess I could run node-static (https://github.com/cloudhead/node-static) and point it at the public directory.
Something to consider, let's say a group wants to maintain a site and are considering Punch. They want to maintain the site through git, pushing to the server, but also maintain templates (especially since images reside in the templates directory), content, posts with multiple people. Currently, if someone pushes posts using git, they would have to generate the site with the workaround above using forever and node-static.
Or am I missing another option?