Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Static site generators focus on the wrong thing

blog.pankajmore.in

Post reply on HN
Print view View original

91–100 of 100 posts

Re: Static site generators focus on the wrong thing

#91

Post by jimktrains2 »

pdonis wrote: post #57
jimktrains2 wrote: post #20

Earlier quoted context omitted.

I'm working on a new version of Gus[0] that will be able to figure out only what needs to be rebuilt and rebuild it. Another feature for the (not to distant?) future will be generating a TF-IDF index in javascript so that a client-side search functionality could be introduced. I also find Gus to have a pretty low bar to publishing. I write in markdown/textile/reStructuredText, build, and rsync. Granted I haven't used…

> figure out only what needs to be rebuilt and rebuild it. I thought a number of SSGs already did this.

They may. Since starting on Gus, I haven't really tried too many others:\

The OP complained about it and I was just pointing out that it doesn't have to be that all pages are recompiled.

Re: Static site generators focus on the wrong thing

#92

Post by mercer »

jacquesm wrote: post #80
reinhardt wrote: post #77

Earlier quoted context omitted.

> All that matters is that the end product can then be served up blazingly fast. TFA argues exactly against this point. All that matter (or rather, what matters more) is minimizing the friction for the blog author in order to stay motivated, not if it takes a fraction of a second more for a page to load.

That's strongly dependent on how many people visit a particular blog. For smaller blogs, sure the page generation time is not relevant.

Indeed. For many people this issue is premature optimization.

When I tried to decide between a Middleman app with minimal configuration work and easy deploy (Heroku), or Ghost, Wordpress, or something like that, one consideration was page generation time.

I calculated that most optimistically, I'd probably write at most three articles a week (which is very optimistic). That means approximately 150 articles a year. That's pretty quick to generate, so I could even leave the generation process to heroku on first page refresh if I wanted.

Re: Static site generators focus on the wrong thing

#93

Post by mercer »

pdonis wrote: post #87
joshvm wrote: post #78

Earlier quoted context omitted.

Obvious gotcha to that is if you have a link on every blog post to jump to the most recent entry. If you were going dynamic, that info would be inserted on page generation, if you're going static then you need to update everything. Easy solution would be to make a duplicate page like /latest.html which updates as necessary.

There are other gotchas as well; for example, on my blog I have links in my sidebar to pages for categories and tags, but the links have total post counts for the category/tag after them, so every time a new post is added at least one count will change on every page. I don't mind because the SSG I use (my own, https://github.com/pdonis/simpleblog3 ) renders fast enough to suit me; it takes about 5-6 seconds to render…

Since the sidebar stuff or 'recent entry' links are not really important for SEO, couldn't you just load those from one static file using a bit of javascript? That's what I'm thinking of doing...

Re: Static site generators focus on the wrong thing

#94

Post by mercer »

andybak wrote: post #35
paulyg wrote: post #25

Earlier quoted context omitted.

I agree with your assessment. To me the reason we keep ping-pnging between the two extremes is a lack of standardized and common caching mechanism. In a perfect world every web server would be behind an HTTP reverse proxy and we could just use HTTP headers to control caching. But there are a lot of quirks to that so unless you control the whole stack you don't have a proxy out front. And then you get into all other k…

Agreed. Essentially SSGs are caching - or rather they are a way of pushing the caching problem down onto a lower level. It's no different to 'clear the whole cache every time I change any content and store it all in memcached' - you're just substituting 'file-system' for 'memcached'. Of course - SSG do solve another problem - that of needing complex software running on your server - you can run SSGs locally or on a c…

The crucial difference, as others have pointed out, is that if you start with a dynamic site and add caching, there are a lot of likely gotchas like infinite url's that all load a slightly different page (pagination, tag combinations, etc.), as well as potential security issues when a page is not cached yet, or the cache is busted.

On the other hand, if you start with a SSG, your initial state is that every page is cached and works, and you have to think carefully of adding some kind of pagination mechanism.

As the quote goes, "There are only two hard problems in Computer Science: cache invalidation and naming things." The big benefit of a SSG is that you 'solved' the cache problem, and will immediately be aware of issues there.

Re: Static site generators focus on the wrong thing

#95

Post by pdonis »

mercer wrote: post #93
pdonis wrote: post #87

Earlier quoted context omitted.

There are other gotchas as well; for example, on my blog I have links in my sidebar to pages for categories and tags, but the links have total post counts for the category/tag after them, so every time a new post is added at least one count will change on every page. I don't mind because the SSG I use (my own, https://github.com/pdonis/simpleblog3 ) renders fast enough to suit me; it takes about 5-6 seconds to render…

Since the sidebar stuff or 'recent entry' links are not really important for SEO, couldn't you just load those from one static file using a bit of javascript? That's what I'm thinking of doing...

I could, but I want to keep the site entirely Javascript-free. I have experimented a bit with using iframes to load the sidebars from one static file, but I haven't gotten that to work the way I want it to.

Re: Static site generators focus on the wrong thing

#96

Post by mercer »

pdonis wrote: post #95
mercer wrote: post #93

Earlier quoted context omitted.

Since the sidebar stuff or 'recent entry' links are not really important for SEO, couldn't you just load those from one static file using a bit of javascript? That's what I'm thinking of doing...

I could, but I want to keep the site entirely Javascript-free. I have experimented a bit with using iframes to load the sidebars from one static file, but I haven't gotten that to work the way I want it to.

Ah, then a javascript solution is out of the question. What problem did you run into with iframes?

Re: Static site generators focus on the wrong thing

#97

Post by pdonis »

mercer wrote: post #96
pdonis wrote: post #95

Earlier quoted context omitted.

I could, but I want to keep the site entirely Javascript-free. I have experimented a bit with using iframes to load the sidebars from one static file, but I haven't gotten that to work the way I want it to.

Ah, then a javascript solution is out of the question. What problem did you run into with iframes?

Browsers don't seem to treat iframes the way they treat other layout elements; I have to specify the exact size (width and height) of the iframe or it won't get laid out correctly. I don't want that; I want an iframe that flows with the rest of the layout just like other box elements.

Re: Static site generators focus on the wrong thing

#98

Post by dreamfactory2 »

grey-area wrote: post #88
dreamfactory2 wrote: post #70

Earlier quoted context omitted.

That's really just the difference between news and articles. News events (big trials, disasters etc) are highly time-sensitive and if your income depends on display ads and Google, instant publishing is crucial and something that comes up on RFPs for such systems. Workflow where content is created by multiple people isn't as well understood but can be a source of incredible friction and productivity killer in publish…

No, the main argument is for security, then cost (software updates cost time), then perhaps performance, though as you point out there isn't much difference with a properly configured cache. Clearly static doesn't suit all sites but if the site is infrequently changed and not too complex or dynamic it is sometimes the best choice. If you have highly dynamic content with multiple authors static is clearly a terrible c…

Given even the White House uses a db backed CMS, security seems a pretty weak argument to be making. Yes, static HTML is sometimes an excellent choice but it doesn't represent any kind of new solution in the space.

Re: Static site generators focus on the wrong thing

#99

Post by dreamfactory2 »

jacquesm wrote: post #76
dreamfactory2 wrote: post #71

Earlier quoted context omitted.

That's just a question of cache config surely.

Only if you have prior knowledge of what URLs are possible. If you don't then the front-end cache will have to play it safe and will have to pass the request to the backend if it does not know the URL. Any kind of variability in the request that causes a conversation between the front-end and the back-end and the cache can be busted, or is a potential DOS vector. Please show me a caching front-end with a dynamic back…

That's what wildcards are for surely. We cover the same cases in MVC routers.

Re: Static site generators focus on the wrong thing

#100

Post by geekam »

phloxicon wrote: post #72
geekam wrote: post #3

I use Pelican[1] (Python) SSG and they are adding (have added?) a feature to skip articles that have not been touched. That makes compilation really fast. [1] https://github.com/getpelican/pelican

I'm really interested in that feature. Do you know which issue that is on the tracker?

Some work was done here : https://github.com/getpelican/pelican/issues/224#issuecommen...
Post reply on HN