I'm not sure how hard linking helps for compilable items then.
Do you mean textual, or binary?
It seems there's a pretty good opportunity for optimizing "compilation" of passed through binary items, too — not to compare them byte by byte with
FileUtils.identical, but check if they're hard links. If I change the hard linked file in content, it's guaranteed to already match in output.
Yeah, I'm seeing it approximately every 10 updates. Fast computer, what can I say. :P
There's one
index.html compiled to /tmp. That's not around after the compile ends. Why not move it immediately?
Identical between
content and output, that is.
Even the copy fallback seems wasteful if I understand the flow correctly. Given a compiled file (like Markdown -> HTML)
temp_path referes to a file that's deleted after the method finishes. That file shouldn't be copied and then deleted, it should only be moved.
(Though if hardlinking fails,
mv will likely be equivalent to a cp + rm anyway)
Though for your particular problem, perhaps a 100ms delay somewhere would be enough
I am not sure how to introduce that, however.
(Otherwise, you end up with something that is so configurable that the config file becomes overwhelming)
I've used LiveReload generally for a long time and I remember it requiring quite a bit of tweaking to find the sweet spot for each project — sometimes compiling JavaScripts or CSS to the output directory took a long time and having the browser constantly reload during that time was annoying. :P
Ideally Nanoc should signal a reload only once it has actually finished its compile cycle.
But with LiveReload being part of
adsf instead of Nanoc, that may be more difficult practice than in theory.
I got my personal Nanoc powered site up a few weeks ago, too, and am trying to write for it. Took me only about 6 years I think. :P
Nanoc's been around for quite some time, hasn't it. :)
Thanks for still maintaining it!
12.5 years now…
Predates RSpec 1.0, the iPad, Pluto being a planet, Obama becoming president, etc. It’s ancient
My site (https://denis.ws/) is now so simple that I could probably whip up something far simpler than Nanoc to maintain it, haha
Haa, it is. You could've done that with... React. React with isomorphic server side rendering and three megs of client side JavaScript.
I’ve been thinking about what Nanoc-with-components could look like — it’d probably involve revamping the
rendering helper significantly.
I just use JSX in JavaScript because it's lintable via ESLint, but don't use React. I use JSX on the server side with a few dozen lines to render HTML directly with https://github.com/moll/js-j6pack/. Works far better than the nonsense that is React on the server side.
Anyway, sleep time!
Here's an Estonian site built in that fashion should you want a real life example: https://github.com/rahvaalgatus/rahvaalgatus. The JSX is in
views, e.g. https://github.com/rahvaalgatus/rahvaalgatus/blob/master/views/error_page.jsx.
Nightie!