3 ms·

The hashing approach is fine, but I don't get why they do this at runtime instead of at site push time. There are so many other things you want to do before mak

The hashing approach is fine, but I don't get why they do this at runtime instead of at site push time. There are so many other things you want to do before making the content live like run regression tests and validators, get a commit message that explains the change, etc. It seems like you will always have a script in there somewhere. Why not have it do the hash tag replacement at the same time and then the content is static? I may just be a curmudgeon. I go to extremes to turn any runtime code into periodically-generated static code. I once started a mini project that was email-based blogging software. To post a comment, each page and existing comment had a mailto: link with an embedded ID string. Replies would hit procmail, which would pull out the ID and embed the comment in the HTML of the original page at the right place. No Javascript or CGI present, only procmail and static HTML. I wonder if Posterous does some of this?

IsaacSchlueter 17y ago
Yes. You're doing it right. Run-time works fine if you're loading all your JS and CSS from the same machine as your markup. But that's not an approach that scales quite as well.
- onedognight 17y ago
  I would assume the files would be in both places, but you just happen to point to the cdn for speed, so at least the frontend could still use the same scheme.
onedognight 17y ago
> I don't get why they do this at runtime instead of at site push time. Convenience. I'm sure the extra stat(2) has a measurable cost, but your js files are almost guaranteed to be in cache and linux should be able to stat 1M files a second in that case. perl -MBenchmark -e 'timethese(3000000, { cached_stat => sub { stat("/etc/passwd") } })'
__david__ 17y ago
> The hashing approach is fine, but I don't get why they do this at runtime instead of at site push time. Mostly for development turn around. It's annoying to "make" between every save and reload. It also makes site updating convenient. We "darcs push" to our test site, make sure nothing is broken and then we "darcs push" to the main site and that's it. It works fine for the site at its current scale (stats are fast!) and there is a clear path to making it create the files statically should it become a bottleneck.

IsaacSchlueter 17y ago

Yes. You're doing it right. Run-time works fine if you're loading all your JS and CSS from the same machine as your markup. But that's not an approach that scales quite as well.

onedognight 17y ago
I would assume the files would be in both places, but you just happen to point to the cdn for speed, so at least the frontend could still use the same scheme.

onedognight 17y ago

> I don't get why they do this at runtime instead of at site push time. Convenience. I'm sure the extra stat(2) has a measurable cost, but your js files are almost guaranteed to be in cache and linux should be able to stat 1M files a second in that case. perl -MBenchmark -e 'timethese(3000000, { cached_stat => sub { stat("/etc/passwd") } })'

__david__ 17y ago

> The hashing approach is fine, but I don't get why they do this at runtime instead of at site push time. Mostly for development turn around. It's annoying to "make" between every save and reload. It also makes site updating convenient. We "darcs push" to our test site, make sure nothing is broken and then we "darcs push" to the main site and that's it. It works fine for the site at its current scale (stats are fast!) and there is a clear path to making it create the files statically should it become a bottleneck.